Re: keep-alive and vary in 304 responses
> On Apr 9, 2019, at 3:30 AM, Stefan Eissing > 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? Please hold off on that one. We received several requests that it not be deprecated because the information that Apache sends is useful for avoiding request loss when the max is reached. > 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. Roy
Re: keep-alive and vary in 304 responses
> Am 09.04.2019 um 16:03 schrieb Stefan Eissing : > > > >> Am 09.04.2019 um 15:41 schrieb Stefan Eissing : >> >>> >>> Am 09.04.2019 um 13:36 schrieb Stefan Eissing >>> : >>> >>> >>> Am 09.04.2019 um 13:27 schrieb Eric Covener : On Tue, Apr 9, 2019 at 6:31 AM Stefan Eissing 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
Re: keep-alive and vary in 304 responses
> Am 09.04.2019 um 15:41 schrieb Stefan Eissing : > >> >> Am 09.04.2019 um 13:36 schrieb Stefan Eissing : >> >> >> >>> Am 09.04.2019 um 13:27 schrieb Eric Covener : >>> >>> On Tue, Apr 9, 2019 at 6:31 AM Stefan Eissing >>> 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...
Re: keep-alive and vary in 304 responses
> Am 09.04.2019 um 13:36 schrieb Stefan Eissing : > > > >> Am 09.04.2019 um 13:27 schrieb Eric Covener : >> >> On Tue, Apr 9, 2019 at 6:31 AM Stefan Eissing >> 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*
Re: keep-alive and vary in 304 responses
> Am 09.04.2019 um 13:27 schrieb Eric Covener : > > On Tue, Apr 9, 2019 at 6:31 AM Stefan Eissing > 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? > -- > Eric Covener > cove...@gmail.com
Re: keep-alive and vary in 304 responses
On Tue, Apr 9, 2019 at 6:31 AM Stefan Eissing 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. > > 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 -- Eric Covener cove...@gmail.com
keep-alive and vary in 304 responses
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? 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? Help in any of the two issues above is appreciated! -Stefan
