Closed hhromic closed 4 years ago
I assumed anyone wanting to use both lpar/gzipped and nytimes/gziphandler would be using them on different handler paths, rather than layered!
Still, it's a bug that it sets identity in Content-Encoding
, and a patch for that would be more than welcome.
I'll work on it then!
Yes we are using them both in a tree of handlers to achieve the best of both worlds for all routes in the application: pre-compressed static content being served by ldap/gzipped
and on-the-fly dynamic compression being done globally by nytimes/gziphandler
.
rootHandler (gziphandler)
|__ fileHandler (gzipped)
|__ apiHandler (JSON responses)
\__ anotherApiHandler (JSON responses)
This gives us plenty of flexibility because gziphandler will compress any text-based response no matter from which handler it comes from. With gzipped we can have a set of static assets pre-compressed and uncompressed on disk (great for debugging) and all is served compressed in the end.
Hi, at the moment
lpar/gzipped
is setting theContent-Encoding
header in the response according to the detected filetype found:https://github.com/lpar/gzipped/blob/1a8abffd89c54062a03d50ac0093851dd55bcab6/fileserver.go#L109-L118
This is okay for
gzip
andbr
encodings but not foridentity
.RFC 2616 (HTTP) states that
ìdentity
should not be used inContent-Encoding
but only in theAccept-Encoding
header [1] for negotiation:The concrete problem with this is that when combining
lpar/gzipped
together withnytimes/gziphandler
. The latter will not compress any response whoseContent-Encoding
header is already set by an inner middleware, i.e. bylpar/gzipped
.This is logical if
lpar/gzipped
already is returning pre-compressed content. However due tolpar/gzipped
settingContent-Encoding: identity
for unknown compressed content effectively preventsnytimes/gziphandler
to further process the response, i.e. potentially compressing it on-the-fly.This means that it is not possible to combine both to serve pre-compressed content and on-the-fly compressed content at the same time as suggested in the README file.
The solution is simply to not set any
Content-Encoding
if the found file is not handled bylpar/gzipped
already, so it can be delegated to the next middleware. If you agree with this I can put together a PR.[1] https://tools.ietf.org/html/rfc2616#section-3.5