Skip to content
This repository has been archived by the owner on Feb 14, 2023. It is now read-only.

Request-for-Comments (RFC) Discussions #96

Open
abonander opened this issue Dec 17, 2017 · 8 comments
Open

Request-for-Comments (RFC) Discussions #96

abonander opened this issue Dec 17, 2017 · 8 comments

Comments

@abonander
Copy link
Owner

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 abonander changed the title Request-for-Comments Discussions Request-for-Comments (RFC) Discussions Dec 17, 2017
@jrozner
Copy link

jrozner commented Mar 15, 2018

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?

@abonander
Copy link
Owner Author

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

@jrozner
Copy link

jrozner commented Mar 15, 2018

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.

@abonander
Copy link
Owner Author

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.

@jrozner
Copy link

jrozner commented Mar 16, 2018

Some API, on the client side, where I'm able to pass in a Vec or Iterator 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 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.

@abonander
Copy link
Owner Author

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

@jrozner
Copy link

jrozner commented Mar 16, 2018

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.

@abonander
Copy link
Owner Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants