Implement multipart with multer

[jaysonsantos]

This is a continuation of #846

@seanmonstar I've managed to implement the change to use multer without resorting to stream::unfold but, for that I had to implement a change on their project to expose the poll next item function.

diff --git a/src/multipart.rs b/src/multipart.rs
index 7b69dbb..a04e141 100644
--- a/src/multipart.rs
+++ b/src/multipart.rs
@@ -219,21 +219,21 @@ impl<'r> Multipart<'r> {
     /// calling this method or [`Multipart::next_field_with_idx()`] again. See
     /// [field-exclusivity](#field-exclusivity) for details.
     pub async fn next_field(&mut self) -> Result<Option<Field<'r>>> {
+        future::poll_fn(|cx| self.poll_next_field(cx)).await
+    }
+
+    // CORRECTNESS: This method must only be called only when it is guaranteed
+    // that `self.state` is an exlusive `Arc`!
+    pub fn poll_next_field(&mut self, cx: &mut Context<'_>) -> Poll<Result<Option<Field<'r>>>> {
         // This is consistent as we have an `&mut` and `Field` is not `Clone`.
         // Here, we are guaranteeing that the returned `Field` will be the
         // _only_ field with access to the multipart parsing state. This ensure
         // that lock failure can never occur. This is effectively a dynamic
         // version of passing an `&mut` of `self` to the `Field`.
         if Arc::strong_count(&self.state) != 1 {
-            return Err(Error::LockFailure);
+            return Poll::Ready(Err(Error::LockFailure));
         }
 
-        future::poll_fn(|cx| self.poll_next_field(cx)).await
-    }
-
-    // CORRECTNESS: This method must only be called only when it is guaranteed
-    // that `self.state` is an exlusive `Arc`!
-    fn poll_next_field(&mut self, cx: &mut Context<'_>) -> Poll<Result<Option<Field<'r>>>> {
         debug_assert_eq!(Arc::strong_count(&self.state), 1);
         debug_assert!(self.state.try_lock().is_some(), "expected exlusive lock");
         let mut lock = match self.state.try_lock() {

So far, cargo test --features=multipart seems to work fine using that patch.
I will open a PR there and check if it makes sense.

[seanmonstar]

Thanks for writing this up so quickly! This is all set to go already?

[seanmonstar]

Multipart fields exist without a name?

[jaysonsantos]

Hey @seanmonstar, on the code there it points to the docs here https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition which says:

Only the value form-data, as well as the optional directive name and filename, can be used in the HTTP context.

[seanmonstar]

The subheading https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#as_a_header_for_a_multipart_body points out:

The first directive is always form-data, and the header must also include a name parameter to identify the relevant field.

[jaysonsantos]

True.
Your concern is that if the library is not following the RFC or tat I should put a default that makes more sense on that?

[jaysonsantos]

Either way, I will open an issue there to try to clarify. I am not sure if it is optional because it is used in both to represent both the header of HTTP and the boundary

[seanmonstar]

Sorry that I didn't explain more. I wasn't sure myself. So, I'm thinking that perhaps even if multer doesn't think so yet, we would treat a lack of a name as an error, and thus if the name does exist, we can just use self.part.name().expect("checked for name previously"). What do you think?

[jaysonsantos]

all good but, the panic is ok there?

[seanmonstar]

Oh, what I was thinking is that constructing a Part would require us to check for a name, and if it doesn't exist, then next_field() would return an Error. We wouldn't want an unchecked panic that a client could trigger, no.

[jaysonsantos]

Hey @seanmonstar I guess so at least on my tests it was all good, any idea of edge cases to be tested there?

[seanmonstar]

Excellent work, thanks for taking this on!