Forum Discussion
flalar
Altocumulus
AltocumulusHTTP cache does not honor vary header
Our origin web servers are set up to serve static content with either Gzip and Brotli compression. This is working fine when requesting pages directly from these servers. The Accept-Encoding header i...
Hi flalar
I didn't quite understand your question. As far as I know F5 software doesn't natively support brotli compression. I know there is a Request for Enhancement (RFE) tracked by ID582791 internally for this.
However, you mentioned that F5 forwards the brotli encoded content to client? Could you please give us a little bit more context? What kind of virtual server/profiles are you using?
flalarAltocumulus
AltocumulusSure let me try.
This is a Standard virtual server with the standard HTTP/2 profile.
Client requests comes in through the F5 and is load balanced between many origins.
Compression is as mentioned performed on the origins, not on the F5, and that works perfectly fine for all browsers. That is, IE11 which sends Accept-Encoding: gzip, deflate as part of the request header gets content compressed with Gzip. Chrome on the other hand send Aaccept-encoding: gzip, deflate, br as part of the request header and gets content compressed with Brotli. Everything is fine and dandy and working as expected.
Now if we add the standard web acceleration profile to the virtual server to offload the origin by caching static assets on the F5 things starts going wrong. IE11 and other browsers that send Accept-Encoding: gzip, deflate, is now getting served Brotli compressed content from the F5 HTTP cache. As they do not support this encoding the pages is unsuable
We’re aware F5 does not support performing the Brotli compression itself. But should it not honor the “Vary: Accept-Encoding” header and cache different variations of the content? Would it not be natural to expect it to cache on different content versions based on values in the content-encoding response header or accept-encoding from the request?