Closed another-salad closed 2 months ago
Is there any real-world client that actually compresses from data?
Not sure if this should be handled by a multipart parser. Content encoding can be handled transparently by an upper layer, e.g. by a WSGI middleware instead.
Its a use case I have come across in a closed source project. However it doesn't appear to be something that is widely used in other real world applications. If its not appropriate to be handled here then that is fine.
While the HTTP spec allows it, I never came across a client that does it. I'd suggest implementing this as separate WSGI middleware and keep this library focused. This is not a hard no, though. I'll let this open for discussion if that's okay.
Ahh wait, you are implementing this for individual parts, not the entire request? I am only realizing that now. That changes the story a bit. It's still a very rare use-case, but now the multipart parser is definitely the right place to handle that. A WSGI middleware layer would not be able to do that. I'll look into it.
Ahh wait, you are implementing this for individual parts, not the entire request? I am only realizing that now. That changes the story a bit. It's still a very rare use-case, but now the multipart parser is definitely the right place to handle that. A WSGI middleware layer would not be able to do that. I'll look into it.
Sorry for not being clearer in the PR description. Thanks for looking and the quick responses!
I never encountered a client or browser that actually uses per-segment compression, and that feature is also deprectaed (see https://datatracker.ietf.org/doc/html/rfc7578#section-4.7 ). After the massive parser rewrite lately there is no chance that this can be merged. So, I guess, after all these years, we should finally close this issue and move on. Thanks for your work anyway.
I never encountered a client or browser that actually uses per-segment compression, and that feature is also deprectaed (see https://datatracker.ietf.org/doc/html/rfc7578#section-4.7 ). After the massive parser rewrite lately there is no chance that this can be merged. So, I guess, after all these years, we should finally close this issue and move on. Thanks for your work anyway.
Fair enough, thanks for your time.
This PR adds support for Gzip encoded field data.
Happy to discuss better ways of implementing something like this (which there likely is).
Apologies if I haven't followed any processes, etc before raising this PR.