elsloo opened a new issue #7230: URL: https://github.com/apache/trafficserver/issues/7230
When an object requested through ATS that has both `Transfer-Encoding: Chunked` and `Content-Length` headers, ATS appears to assume the object is chunked and follows those code paths accordingly. However, we observed a case on an object (<500 bytes, if relevant) that led the HttpSM to the following location: https://github.com/apache/trafficserver/blob/8.1.x/proxy/http/HttpSM.cc#L2923 This leads to a successful `pssc` (200, 206), `pfsc=INTR`, `crc=ERR_READ_ERROR` being logged, but an empty reply to the client. No response headers, no error message in the body; nothing. The only way to find the issue was to put ATS into debug, see the error message, then, armed with this knowledge, hunt for the issue. In our case, the `Transfer-Encoding` should not have been present. While these headers should be used independently, it happened. If this were to occur in the future, our ideal state would be a real HTTP 5xx error response served to the client instead of nothing, and something more meaningful would be logged such that debug is no longer necessary to find the hint that this is the problem. `pfsc=INTR` is misleading, because the transaction completed successfully between ATS and the upstream system. Instead, ATS should have logged `pfsc=FIN` and, if anything, `cfsc` was `INTR` but that still is not really descriptive enough to know why the transaction was interrupted/aborted. The system that served this object to ATS, was, itself, an ATS cache. It was able to successfully cache the object with both headers present, and presumably, the IMS process allowed this condition to remain for a prolonged period of time. A secondary aspect of this issue is that when ATS makes the request itself as a consequence of an ATS client request, it can cache the response and serve it successfully, as far as its logs are concerned. However, the downstream cache, while it is able to fully read the response and the upstream cache logs it as a success, it then aborts the request as described. One could argue that the upstream cache should have generated an error that would have propagated to the downstream cache. ---------------------------------------------------------------- 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: us...@infra.apache.org
