Skip to content
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

Adding Gzip content encoding support #40

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

another-salad
Copy link

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.

@defnull
Copy link
Owner

defnull commented Sep 5, 2022

Is there any real-world client that actually compresses from data?

@defnull
Copy link
Owner

defnull commented Sep 5, 2022

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.

@another-salad
Copy link
Author

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.

@defnull
Copy link
Owner

defnull commented Sep 5, 2022

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.

@defnull
Copy link
Owner

defnull commented Sep 5, 2022

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.

@another-salad
Copy link
Author

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!

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

Successfully merging this pull request may close these issues.

2 participants