JosiahWI commented on PR #12618: URL: https://github.com/apache/trafficserver/pull/12618#issuecomment-3461655348
> > I am suspicious of all the tests in this AuTest (including ones you have not touched) that reply with the empty-encoding alternate in response to requests for a deflate encoded resource. I think that is nonconforming to the RFCs and needs to be fixed. I would appreciate if @maskit or someone could double check my work on that. > > Other than that general concern, I have some comments pertaining directly to the changes in this PR. Please take a look. > > I believe those tests are correct because of https://www.rfc-editor.org/rfc/rfc9110.html#section-12.5.3-10.2 which states > > > If the representation has no content coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding header field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity". > > we are not sending either "identity;q=0" or "*;q=0" - so ATS can send back the identity response it has Whoops, I was looking at the obsoleted RFCs, thanks you for the correction! I think it is still non-conforming for a proxy to reply out-of-cache in this scenario, however: https://www.rfc-editor.org/rfc/rfc9111#section-4.1-1. We could argue about wording, but I think it will be more profitable to talk about the overall meaning of the RFCs. First let me go over my understanding of the background, just so I know we're on the same page about the setup. Suppose that ATS receives a request to `ae-0.com/path` with `Accept-Encoding: ` as in the AuTests here, and that no alternate for that resource has been cached. ATS will request the resource from the origin server, get a response with `Vary: Accept-Encoding` and cache it. Now, suppose that ATS receives another request for `ae-0.com/path` with `Accept-Encoding: deflate`. Should ATS reply out of cache? The user agent must be capable of processing a response with no content-encoding, so functionally everything should be fine if we reply out of cache. Here's the issue: _why_ did the user agent send the `Accept-Encoding: deflate` header? The only reason to send that header is to let us know we can compress the content to save bandwidth, which is desirable. [Sect ion 12.5.3](https://www.rfc-editor.org/rfc/rfc9110.html#section-12.5.3-16) of RFC 9110 provides evidence for this understanding, by suggesting that this optimization is so valuable for transferring large content that a server might even want to inform a client that it ought to consider accepting compressed content. ATS, by replying out of cache with uncompressed content, has ignored the possibility that the origin **does have** deflate compression. Up to this point, there is no problem with current ATS behavior, because we see that in fact ATS will _not immediately_ reply out of cache, but will go to the origin server instead to see if it has an alternate with deflate encoding. The real issue I see with the current behavior is that ATS, having received a response (404 Not Found in the case of the AuTest) from the origin for `Accept-Encoding: deflate`, decides to instead serve the 200 OK response. `Accept-Encoding: deflate` does not match `Accept-Encoding: ` by the rules in RFC 9111 (which encompasses the rules ATS uses for normalizing the header). Is it acceptable for a proxy to reply from cache with a response that is different than the origin's response to the request, which it also knows about? The server is not constrained by `Vary`, so it may choose which encoding to send. The proxy is bound to obey the `Vary` header and therefore does not have the flexibility that the origin server has. This has been fixed in the case 1 deflate test in this PR. I am not sure why the similar tests for cases 2, 3, and 4 still pass. -- 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]
