-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Add transparent compression handling in the Response struct. #14
Comments
Currently the client doesn't set Transparent compression may be added to the client as opt-in setting in Client and HostClient. Enabling transparent compression in fasthttp client by default is no go, since default compression implementation in Go is slooow ;) |
My idea was to check for the 'Content-Encoding' header in the response, and decompress the body if the header was present. Now, We could add a EnableCompression parameter also, to transparently compress the requests, but this is a story for another pull request. In our use case, we use haproxy to compress the responses sent from the server ( We do set 'Content-Encoding' in the request header explicitly), and then check for the 'Content-Encoding' in the response. |
Nice idea! I'll try implementing it on the next week. |
@szank , I decided adding helper functions for body compression instead of transparent compression. This allows using response body compression only when needed. See Response.BodyGunzip and Response.BodyInflate. |
Added CompressHandler for transparent response compression on server side. |
There is github.com/klauspost/compress a fully gzip compatible drop in replacement for go standard gzip/zip/zlib packages. pgzip Go parallel gzip compression/decompression. This is a fully gzip compatible drop in replacement for "compress/gzip". Faster for big files more than 1MB. cgzip wraps zlib using cgo. |
…rd compress/*, since it provides better performance on average
What about transparent decompression of incoming requests to server? |
Just added Request.BodyGunzip helper. Transparent compression / decompression won't be implemented in fasthttp, since this may be abused by specially crafted malicious requests / responses, which may eat a lot of CPU and memory resources. So fasthttp users must manually compress / decompress request / response bodies when needed. |
I think this issue may be closed now. Feel free creating new issues for unresolved topics mentioned above. |
Thanks! Isn't BodyInflate() missing? |
Hi,
I was wondering if adding transparent compression handling in the code is feasible.
Currently we check if the "Content-Encoding" header have a "gzip" value and decompress the data ourselves.
I might do it myself if I have some free time on my hands, but I was wondering if this change would be even accepted
The text was updated successfully, but these errors were encountered: