rob05c commented on issue #7458: URL: https://github.com/apache/trafficserver/issues/7458#issuecomment-1009516940
`normalize_ae` affects what ATS sends the upstream parent or origin. It doesn't affect what ATS sends the client. For example, if a client sends the header `Accept-Encoding: gzip,br,deflate,foo,bar,baz` and `normalize_ae` is 1 (gzip), ATS then sends the upstream parent/origin `Accept-Encoding: gzip`. This in no way affects what ATS sends the client. Whatever the parent responds with, ATS will cache, with the response's `Content-Encoding` as variant. When ATS gets a new client request, it will check the cache for acceptable variants from the _original client request_ (*not* the normalized value). ATS _should_ respect any client quality values (https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.1). But if qualities are absent or equal, ATS may respond with any valid cached value. If I understand correctly, you seem to expect that `normalize_ae` means "prefer this value when sending to the client." It doesn't. It just means "modify the header ATS sends upstream." Nothing more. The part of ATS that determines if a cached object exists doesn't know anything about the `normalize_ae` setting. If all quality values are equal, the cached variant that ATS returns will be completely arbitrary. The `normalize_ae` setting doesn't affect that in any way. We could theoretically add an ATS setting to "prefer encoding." But no setting like that exists today. If you need to alter the quality, the right solution is to either make your client send an Accept-Encoding with quality values preferring brotli (if you control the client), or a Header Rewrite like you did. -- 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]
