ESI should handle these situations correctly. e.g. it won't gzip the response if it is already gzipped. So it works fine in a standalone way.
The problems begin when we starts to chain a few of these standalone transformation plugins together. Each of them will try to do the right thing when they are used in a standalone way and perform gunzip/gzip correctly. So chaining them together means I will be unnecessarily doing multiple gunzip/gzip on the contents. The other way is make them plugins be aware of each other and work together and don't unnecessarily do gunzip/gzip. But then this makes the plugins no longer standalone +1 on Dzmitry's idea. Kit On Mon, Mar 23, 2015 at 5:11 PM, Leif Hedstrom <zw...@apache.org> wrote: > > > On Mar 23, 2015, at 6:08 PM, Dzmitry Markovich > <dmarkov...@linkedin.com.INVALID> wrote: > > > > Hello ATS experts, > > > > Today it is very common that http data that goes to the wire is > compressed. And we think it is a time to standardize this process in ATS > core, since it is very common operation. > > > > Today multiple plugins running on the same tier (that operates with > response body) do not have enough flexibility to handle gzip/gunzip - and > most of the times simply every plugin do gzip/gunzip. This lead to the > situation when we do gzip/gunzip multiple times while we process the http > response. This leads to the bad CPU utilization and performance. > > > > Yes, there is gzip/gunzip logic in atscpp API - so plugins can simply > use those. But today's ATS architecture does not allow us to fully control > the order of hook callbacks for every plugin per request - it means there > is no non-hacky way to prevent multiple gzip/gunzip calls while processing > the request. And there is no way to do that with the assumption that > plugins dnot know about each other. > > > > > > Here is our high level proposal, just to start the conversation going: > > - Have gzip/gunzip logic landed on ATS core, so engineers can ask ATS > (vi config parameter) to take care about gzip/gunzip logic for them > > 1. Only ATS know when the body arrived to first plugin - so ATS at > this point ungzip the body; > > 2. Only ATS knows when body is processed by all plugins and should go > over the wire - so ATS at this point gzip the body if client supported it. > > > Moving gzip to the core seems a generally good idea. Probably in some > extensible way such that we can add future compression encoding (I think > Chrome has support for some better ones?). > > Now, I’m slightly confused, and/or concerned, that our plugins do not > handle this well. I would have imagined that something doing gzip would not > do so if the content comes back with Content-Encoding: gzip. So shouldn’t > e.g. ESI detect if the gzip plugin has already done so? > > Is there a reason why a plugin *can’t* detect this? If not, we should fix > the plugins regardless of this RFE, it seems like a broken behavior if a > plugin can gzip something that’s already CE: gzip. > > Cheers, > > — Leif > >
