> Am 09.04.2019 um 16:03 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
>
>
>
>> Am 09.04.2019 um 15:41 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
>>
>>>
>>> Am 09.04.2019 um 13:36 schrieb Stefan Eissing
>>> <stefan.eiss...@greenbytes.de>:
>>>
>>>
>>>
>>>> Am 09.04.2019 um 13:27 schrieb Eric Covener <cove...@gmail.com>:
>>>>
>>>> On Tue, Apr 9, 2019 at 6:31 AM Stefan Eissing
>>>> <stefan.eiss...@greenbytes.de> wrote:
>>>>>
>>>>> I just did some tests with https://redbot.org/ (the site tester by Mark
>>>>> Nottingham) against our server and it notifies of 2 things:
>>>>>
>>>>> 1. The "Keep-Alive" header is deprecated. I tried to "Header unset
>>>>> Keep-Alive" but that has no effect. Seems to be added very late.
>>>>> Do we have a way to suppress it?
>>>>
>>>> Doesn't look like it, maybe a good "help wanted" kind of task if
>>>> anyone is lurking.
>>>
>>> We rarely ever eat volunteers!
>>>
>>>>> 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?
>>>>
>>>> bailing here, seems harmless if we add Vary to a 304 even when we
>>>> don't know the original was long enough?
>>>>
>>>> [Tue Apr 09 07:26:12.183430 2019] [deflate:trace1] [pid 37010:tid
>>>> 123145306648576] mod_deflate.c(590): [client 127.0.0.1:64941] Not
>>>> compressing very small response of 0 bytes
>>>
>>> Ah, nice!
>>>
>>> Maybe if AP_STATUS_IS_HEADER_ONLY(r), the length check should not run?
>>
>> Meh!
>>
>>> curl -D xxx -H 'Accept-Encoding: gzip' https://eissing.org
>> HTTP/2 200
>> date: Tue, 09 Apr 2019 13:36:10 GMT
>> server: Apache/2.4.39 (Ubuntu)
>> strict-transport-security: max-age=15768000
>> last-modified: Thu, 10 Aug 2017 11:16:47 GMT
>> etag: "9a6-55664550a25c0-gzip"
>> accept-ranges: bytes
>> cache-control: max-age=3600
>> vary: Accept-Encoding
>> content-encoding: gzip
>> content-length: 1015
>> content-type: text/html
>>
>>> curl -D xxx -H 'Accept-Encoding: gzip' -H 'If-Modified-Since: Thu, 10 Aug
>>> 2017 11:16:47 GMT' https://eissing.org
>> HTTP/2 304
>> date: Tue, 09 Apr 2019 13:36:35 GMT
>> server: Apache/2.4.39 (Ubuntu)
>> etag: "9a6-55664550a25c0"
>> cache-control: max-age=3600
>>
>> Same for HTTP/1.1 requests. And same for https://httpd.apache.org
>>
>> The output filters are not in play at all. Was it always like this?
>
> Update: its the short-hand header list that gets written in case of 304 in
> http_filters.c:1429 pp
>
> Continuing to investigate what is happening here...
Finally, not being the sharpest today, there is - of course -
http_protocol.c:1248 which removes all resource filters for "error" responses.
Hmmpf. Makes sense as it keeps complexity from filters. The price being that we
allow only a very limited set as response headers. Because all else could be
altered by the filters we did not run. Which loses the "Vary" set by resource
filters.
Hmm, something to chew on...
-Stefan
