multipart icon indicating copy to clipboard operation
multipart copied to clipboard

Request-for-Comments (RFC) Discussions

Open abonander opened this issue 8 years ago • 8 comments

I have left a number of Request-for-Comments (RFC) questions on various APIs and other places in the code as there are some cases where I'm not sure what the desirable behavior is.

This issue is a place to collect responses and discussions for these questions.

Please quote the RFC-statement (and/or link to its source line) and provide your feedback here.

abonander avatar Dec 17 '17 19:12 abonander

I'm looking at multipart libraries for implementing some middleware that will intercept, process requests, and write them back out before forwarding the potentially modified raw body onto the application. The multipart parser and serializer implementation here looks pretty good but the API is incredibly painful to work with because it's setup to expect full request structs that provide a bunch of methods. Would you be open to exposing some lower level functions to handle just the parsing/serialization and operating on a stream/vector/list of parts?

jrozner avatar Mar 15 '18 22:03 jrozner

Is Multipart::with_body() not sufficient? That just takes the boundary and a Read impl.

abonander avatar Mar 15 '18 23:03 abonander

It looks like Multipart::with_body will handling parsing out the individual parts but from the client side it doesn't look like I can easily just pass the parts back into the client side and re-serialize them. I also necessarily am buffering the full body and looking to avoid having to deal with saving out the files to disk during read and then reading them back out during serialization. I've already paid the memory cost and don't really have the ability to avoid that.

jrozner avatar Mar 15 '18 23:03 jrozner

The default client side API lets you generate request bodies in a streaming fashion, though I don't have it set up for working with a raw Write impl I could make that change pretty easily, if that's all you need from the client side.

abonander avatar Mar 16 '18 00:03 abonander

Some API, on the client side, where I'm able to pass in a Vec<MultipartField> or Iterator<MultipartField> with a boundary and it serializes it out to either a [u8], Write, or some other type of buffer would be awesome.

Ideally being able to get an Iterator<MultipartField> from Multipart in server would be awesome but I understand that's an issue with the streaming implementation. In my case, since I already have the full buffer copied, it would be cool if there was just a zero copy parser exposed that returns an iterator of them that I can use as Cow so I can only modify parts that I need to modify and just map over the Iterator to get the new set of parts I need to write out.

jrozner avatar Mar 16 '18 00:03 jrozner

On a side-note, have you looked at the mock module at all?

abonander avatar Mar 16 '18 00:03 abonander

I just took a peek and it could help some with doing the deserialization of the body, but it looks like it doesn't offer me anything that I don't already get with Multipart::with_body and the Client mocking doesn't take in the parsed parts. The real piece that would make things easier at this point is being able to operate on all parts and serialize them back out to a buffer of some sort easier.

Also, I'm not sure if this it the correct place to be discussing this and if you'd like I'm happy to move it elsewhere. It just seemed somewhat fitting since it was looking for feedback.

jrozner avatar Mar 16 '18 17:03 jrozner

Yeah a new issue would be preferable. You would use mock::ClientRequest with client::Client, I dunno if that was very clear. That would allow you to serialize the body out to a Vec<u8> and get the boundary as well.

abonander avatar Mar 16 '18 18:03 abonander