The handle_cache_operation_on_forward_server_response function doesn't handle proper range operations for mismatched server and cache responses

[vmamidi]

handle_cache_operation_on_forward_server_response sets RANGE_NOT_TRANSFORM_REQUESTED even if the server returns a response that doesn't match with the cached response. This causes ATS to send incorrect client responses.

For example, while revalidating the cached 200 response, if ATS receives a 404 response, ATS transforms the 404 response to a 206 response and sends it to the client

[SolidWallOfCode]

The question is whether the 404 should invalidate the cached object. Is the behavior you expect is that an error response from the upstream should invalidate the cached object? The PR consensus was this seems reasonable but we wanted clarity on the desired behavior.

[mlibbey]

What are the corner cases to consider? If the origin says that an object no longer exists during revalidation, when would we want to keep serving old content in cache?

[vmamidi]

The question is whether the 404 should invalidate the cached object. Is the behavior you expect is that an error response from the upstream should invalidate the cached object? The PR consensus was this seems reasonable but we wanted clarity on the desired behavior.

The 404 response already invalidates the cache, but ATS serves a 206 response for the request that triggers cache invalidation. Subsequent responses are then served from the cache as 404.