> 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? The protocol one would a. check if its resource counterpart was active b. or, if the requests status is 304, if it would have been active add "Vary: Accept-Encoding" if one of those is true For b. a bit of heuristic seems necessary: - detect that the resource filter has been added before *) - assume it applies when content-length is not set - check content-length otherwise - perform the other (r->subprocess_env etc.) checks as in resource filter *) It could detect the resource filter in r->output_filters, however ap_send_error_respons() overwrites this with r->proto_output_filters. Seems like a good idea to save them for later inspection? -Stefan
