> On Apr 10, 2019, at 3:10 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > > >> Am 09.04.2019 um 18:48 schrieb Roy T. Fielding <field...@gbiv.com>: >> >>> >>> 2. Validation responses lose the "Vary" header from the unconditional >>> response. This happens on resources where mod_deflate is active. >>> The 200 response without any "if-modified-since" etc. carries "Vary: >>> Accept-Encoding" as it should. >>> The 304 response with "if-modified-since" has no "Vary" header. >>> The code in mod_deflate looks as if it tries to add it in any case, where >>> is it lost? >> >> That's one of many bugs related to design problems with mod_deflate. >> Basically, >> it chooses to insert itself into the response handling after the other >> checks are done, >> which means a 304 doesn't even know yet whether the response would use gzip. >> The solution (which I never found time to implement) is to replace dynamic >> gzip with >> a transfer encoding generator, and/or to rewrite the mod_deflate CE encoder >> to act more >> like mod_cache. > > Thinking out loud here: > > Acting more like mod_cache would then split the deflate output filter into a > resource and a protocol type one, I assume?
Yeah, probably. What I meant was that deflate would act like a proxy to the resource backend, provide variants transparently regardless of the client's request, and maintain a cache of (at least) the metadata for available variants. That would allow the metadata to be consistent over time, and possibly allow the dynamically compressed variants to also be cached for later use. It's also reasonable (though perhaps less cache efficient) to add "Vary: Accept-Encoding" on any response that has a chance of being dynamically compressed even if we decide that *this* response will not be. ....Roy
