Thanks for the quick response and for offering to take a look at it. Much appreciated! It's definitely helpful to know that this isn't currently supported, but if an option could someday be added to make gzip behave this way, that would be fantastic. I'm unfortunately not very familiar with the Traffic Server code base, but if I can help out in any way, give me a shout.
Thanks again! Nick On Tue, Jul 29, 2014, at 03:21 PM, Otto van der Schaaf wrote: Regrettably, the gzip plugin currently doesn't support doing what you want. But I think it would be really nice to (add an option to) make it work like that. I'll have a look, but allow me a week or two to get back to you about this. Otto 2014-07-29 20:17 GMT+02:00 Nick Muerdter <[1][email protected]>: Hi, For cacheable, gzippable requests, I'm trying to ensure that our origin servers only get hit once, regardless of whether clients request gzip or not. In other words, if the first client to hit an uncached resource accepts gzip, I want all subsequent gzipped or non-gzipped responses to be delivered from the cache, rather than hitting the origin server again. TrafficServer's gzip plugin does seem to support this behavior in some situations, but not universally. So I'm not sure if this is a bug in the gzip plugin, or if I've misconfigured things, or this simply isn't supported by the gzip plugin and Traffic Server. Any thoughts or ideas would be welcome. The main issue I'm running into is when the origin server supports gzipping responses itself (so it returns "Vary: Accept-Encoding" headers). In that case, TrafficServer wants to cache the gzipped and non-gzipped versions of the response separately, incurring two separate origin requests. If I set "remove-accept-encoding true" this almost solves things, except when the first request requests gzipping (the client sets "Accept-Encoding: gzip") and the server response contains "Vary: Accept-Encoding". In that case, a subsequent uncompressed request (omitting any "Accept-Encoding" header) still results in another hit to the origin server. And while "remove-accept-encoding true" comes closer to solving the issue, I'd ideally like to achieve this behavior with "remove-accept-encoding false", since in some cases, I'd prefer to have the gzipping handled by the origin server and the backend communication happen with gzipped responses. Here's an excerpt from some automated integration tests I've written to test all the various gzip request/response combinations I could come up with. This might more clearly define which situations are currently working and which one's aren't, but let me know if any of this still isn't clear: [2]https://gist.github.com/GUI/4ab8eacb6bd21f39d590 This was tested on Traffic Server 5.0.1. I could also abstract this part of our test suite into some isolated test scripts if anyone want to try and reproduce it. And for whatever it's worth, Varnish appears to behave the way I want, so it seems like it might be in the realm of possibilities, but Varnish also seems to deal with gzip quite differently (I think it always stores the gzipped version and un-gzips on the fly for uncompressed clients). I've tried various tweaks to the gzip and vary settings in Traffic Server, but I can't seem to get rid of these duplicate requests in some cases when different clients support gzip or not. Thanks! Nick References 1. mailto:[email protected] 2. https://gist.github.com/GUI/4ab8eacb6bd21f39d590
