search

nytimes / gziphandler

Go middleware to gzip HTTP responses
https://godoc.org/github.com/NYTimes/gziphandler
Apache License 2.0
868 stars 129 forks source link

Avoid double compressing contnet #29

Closed bakins closed 7 years ago

bakins commented 7 years ago

Check if the response is already compressed and do not compress it. When used in a proxy - like traefik - backend servers may be compressing the content. User may not have control over that backend, etc.

This is a bit more intrusive than I'd like, but passes tests. We have to examine the ResponseWriter's headers in write as they may not yet be set elsewhere. Let me know if you think there's a better way.

jprobinson commented 7 years ago

Howdy @bakins, I'm trying to get a sense of the issue to understand the needs for this change so please forgive me if I'm making any incorrect assumptions.

From a quick glance, it seems that the issue is folks are using Traefik to proxy multiple sources, some of which are not GZIP'd and some which are, but they are attempting to reuse the same configuration (compression, specifically) across all of them.

My first reaction to this is to follow the principle of least surprise and leave the gzip handler doing what it does now: GZIP requests that flow through it.

Would there be any way for folks using Traefik to specify which backends specifically should get the GZIP middleware? That to me sounds like a bit more of an elegant solution.

bakins commented 7 years ago

Currently, my use case is traefik and it doesn't allow per backend configuration, unfortunately. I can see the desire to keep this project simple as well. I can possibly explore this in detail inside traefik. at another gig, we wound up writing our own gzip handler logic similar because non of the third party ones fit our needs, so that may wind up being what I propose for proxying. Thanks for taking a look and for your feedback!

tkizm1 commented 7 years ago

Need to fixed either in this or traefik. Link