bryancall commented on issue #10772: URL: https://github.com/apache/trafficserver/issues/10772#issuecomment-4828154906
I traced this to the range-transform path in `HttpSM::do_range_setup_if_necessary`. The original problem was that during a revalidation (cache action REPLACE), the range transform was installed regardless of the origin status, so an origin 404 to a revalidation of a cached 200 got rewritten into a 206 for the client. That is fixed by [PR #11308](https://github.com/apache/trafficserver/pull/11308), which only installs the transform on revalidate when the origin response is 200 OK. Any non-200 status (such as a 404) now falls into the "Not transforming after revalidate" branch and is forwarded unchanged. You can see the current behavior here: https://github.com/apache/trafficserver/blob/a2c55e3dbe918b229981074c6c81a92b5534c88f/src/proxy/http/HttpSM.cc#L5147-L5149 This first shipped in 10.0.0. A later refinement to the same revalidation path landed in [PR #13158](https://github.com/apache/trafficserver/pull/13158) (10.2.0), which re-parses the range against the fresh origin Content-Length. Closing as resolved. If the separate cache-invalidation question raised in the thread (whether an origin error should invalidate the cached object) still needs discussion, please open a focused issue for that, since the invalidation behavior is governed by RFC 7234 section 4.4 and handled separately. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
