One of our origin servers incorrectly returns Transfer-Encoding: chunked on conditional HEAD requests:
$ curl -I -H "Host: noc.wikimedia.org" -H "If-Modified-Since: Wed, 17 Jun 2020 05:13:37 GMT" https://mwmaint.discovery.wmnet 2>&1
HTTP/1.1 304 Not Modified
date: Wed, 17 Jun 2020 08:24:12 GMT
server: Apache
etag: "c7c-5a83b16373584"
cache-control: s-maxage=60, must-revalidate, max-age=0
x-envoy-upstream-service-time: 0
transfer-encoding: chunked
If (1) ATS had previously cached the corresponding object upon receiving a GET request and (2) a HEAD request is later received after "maxage" is expired, then ATS sends a conditional HEAD request to the origin, and upon receiving a 304 like the one mentioned above with Transfer-Encoding: chunked it adds Transfer-Encoding: chunked to the object in cache. All subsequent cache hits served by ATS for the object will return both Content-Length and Transfer-Encoding, which must not be done according to rfc2616 section-4.4. Also, clients get very confused when receiving both.
$ curl -v -H Host: noc.wikimedia.org localhost:3128/
[...]
> GET / HTTP/1.1
> Host: noc.wikimedia.org
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Wed, 17 Jun 2020 11:06:17 GMT
< server: Apache
< last-modified: Tue, 16 Jun 2020 22:30:12 GMT
< etag: "c7c-5a83b16373584"
< accept-ranges: bytes
< content-length: 3196
< vary: Accept-Encoding
< backend-timing: D=269 t=1592391978258588
< cache-control: s-maxage=60, must-revalidate, max-age=0
< content-type: text/html
< x-envoy-upstream-service-time: 0
< Age: 1
< Connection: keep-alive
< X-Cache-Int: cp2027 miss
< X-ATS-Timestamp: 1592391978
<
[regular response body follows, object gets cached by ATS]
$ sleep 62
$ curl -v -I -H Host: noc.wikimedia.org localhost:3128/
[...]
> HEAD / HTTP/1.1
> Host: noc.wikimedia.org
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Wed, 17 Jun 2020 11:22:03 GMT
< server: Apache
< last-modified: Tue, 16 Jun 2020 22:30:12 GMT
< accept-ranges: bytes
< content-length: 3196
< vary: Accept-Encoding
< backend-timing: D=196 t=1592392861556186
< cache-control: s-maxage=60, must-revalidate, max-age=0
< content-type: text/html
< x-envoy-upstream-service-time: 0
< Etag: "c7c-5a83b16373584"
< Transfer-Encoding: chunked
< Age: 0
< Connection: keep-alive
< X-Cache-Int: cp2027 hit
< X-ATS-Timestamp: 1592392923
<
[note that TE:chunked is returned in response to the HEAD request]
$ curl -v -H Host: noc.wikimedia.org localhost:3128/
> GET / HTTP/1.1
> Host: noc.wikimedia.org
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Wed, 17 Jun 2020 11:22:03 GMT
< server: Apache
< last-modified: Tue, 16 Jun 2020 22:30:12 GMT
< accept-ranges: bytes
< content-length: 3196
< vary: Accept-Encoding
< backend-timing: D=196 t=1592392861556186
< cache-control: s-maxage=60, must-revalidate, max-age=0
< content-type: text/html
< x-envoy-upstream-service-time: 0
< Etag: "c7c-5a83b16373584"
< Transfer-Encoding: chunked
< Age: 0
< Connection: keep-alive
< X-Cache-Int: cp2027 hit
< X-ATS-Timestamp: 1592392923
<
{ [3196 bytes data]
* Illegal or missing hexadecimal sequence in chunked-encoding
[both Content-Length and Transfer-Encoding: chunked are returned, curl complains]
One of our origin servers incorrectly returns
Transfer-Encoding: chunkedon conditional HEAD requests:If (1) ATS had previously cached the corresponding object upon receiving a GET request and (2) a HEAD request is later received after "maxage" is expired, then ATS sends a conditional HEAD request to the origin, and upon receiving a 304 like the one mentioned above with
Transfer-Encoding: chunkedit addsTransfer-Encoding: chunkedto the object in cache. All subsequent cache hits served by ATS for the object will return bothContent-LengthandTransfer-Encoding, which must not be done according to rfc2616 section-4.4. Also, clients get very confused when receiving both.