> Am 10.04.2019 um 12:48 schrieb Plüm, Rüdiger, Vodafone Group
> <ruediger.pl...@vodafone.com>:
>
>
>
>
> C2 General
>
>> -----Ursprüngliche Nachricht-----
>> Von: Stefan Eissing <stefan.eiss...@greenbytes.de>
>> Gesendet: Mittwoch, 10. April 2019 12:10
>> An: dev@httpd.apache.org
>> Betreff: Re: keep-alive and vary in 304 responses
>>
>>
>>> 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?
>
> IMHO the "secret" of mod_cache is that its filter is also inserted via the
> insert_error_filter hook and not just via the insert_filter hook (like
> mod_expires and mod_header do).
Thanks for the pointer. The first lines of this actually show:
/* ignore everything except for 5xx errors */
if (r->status < HTTP_INTERNAL_SERVER_ERROR) {
return;
}
So, this is not applied on 304s. And 304 is the only non-200 status that
content-encoding filters are really interested in, I think.
> With mod_deflate this will be more complex as mod_deflate does not add itself.
> It is either added by the core via SetOuputFilter or via mod_filter and they
> all only consider insert_filter and not insert_error_filter. We probably need
> a possibility to tell filters to be added in insert_error_filter.
Could not a deflate *protocol* filter always insert itself and check if
its resource counterpart is present in r->output_filters? This would leave
the application of resource filters unchanged.
Only in error responses, e.g. 304, would the protocol deflate filter not
find its buddy. If the r->output_filter got preserved at the request, it could.
>
> Regards
>
> Rüdiger
