httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: keep-alive and vary in 304 responses
Date Wed, 10 Apr 2019 10:10:08 GMT

> Am 09.04.2019 um 18:48 schrieb Roy T. Fielding <>:
>> 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
> 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

View raw message