vpelletier commented on issue #7880: URL: https://github.com/apache/trafficserver/issues/7880#issuecomment-849321454
Some more data points and details. In the original setup where we noticed this issue (which @lukenowak then reproduced in a smaller test scenario with less identifying data) there was another weird behaviour to the chunking: for a 8211 bytes cached resource, both `tcpdump` and `curl --raw` on an access local to the maching running ATS show: - a first 0x1000 chunk header, followed by 4096 bytes of data as expected - a second 0x1000 chunk header, followed by only 3597 bytes of data before the connection becomes silent, until ATS eventually closes it of its own initiative once the inactivity timeout is reached So not only is the response's body lacking a final empty chunk, it is even lacking part of a chunk, and a further 3rd 0x13 bytes-long chunk, so 499 + 13 bytes are missing from the final decoded resource. This resource has `content-encoding: gzip`. If I request the same resource with curl but without `--compressed` ATS does a cache-miss, reaches for origin, gets a 502 response which it caches as an alternate. So I believe this content encoding should be harmless as ATS does not seem to do content encoding negociation. Also, as I just described, in our setup the origin is not necessarily down from a network perspective: an alternative origin may be reached instead of the normal one, and it would only serve error pages with a 502 status and a short html body. We expect ATS to handle both cases in the same way for resources which are available from cache (the cached version is served, possibly after a refresh attempt towards origin). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
