> 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? -Stefan *scratches his head*
