-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Streaming parsing? #1
Comments
Thats a interesting idea. As far as i understood it, the aim is to have a iterator or such, for the parts of a multipart content. While each part will contain a completely read array of headers and another iterator or such for reading the body if requested. This could be implemented for multipart content already in memory, as well as content read from a filehandle. While both might return the same result in the end. Thanks for that idea and the reference to your good looking stream library. I will have a look at this and try to come up with something :) |
Does this issue have anything to do with psr-7? From what i saw from the interfaces, a |
Nothing to do with Psr7
|
@h4cc I have no opinion on the iterator part, but we frequently run into memory issues with multipart responses. It would be very helpful if this library parsed using streams in order to better support large responses. |
It would be really cool if this library supported streaming parsing of a message. One thing I thought of was accepting an fopen resource or Guzzle stream resource as input, and returning an iterator that returns Guzzle stream resources that are just LimitStreams over the original data. Then the usage could become something like this:
In order to get an array of parts, you'd need to provide a sort of helper function with the caveat that it loads the entire message into memory (something like this could be on the iterator):
The text was updated successfully, but these errors were encountered: