> 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...
