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 is taken into account and the appropriate content encoding is served to the browser. This changes when we add F5 LTM with standard web acceleration profile enabled to the mix. Now, even though the browser send “Accept-Encoding: gzip, deflate” the F5 returns a cached version of Brotli encoded content. It seems the HTTP cache does not honor the “vary: Accept-Encoding” header returned by the origin web servers. This causes old browsers like IE11 to receive scripts and css that it cannot render and leaving the application useless for the customer.
According documentation and this AskF5 article https://support.f5.com/csp/article/K5157 the HTTP cache should honor “vary: Accept-Encoding”, but we are not getting the expected behavior.
We definitely do not want to give up Brotli compression as it is superior to Gzip in compression size and decompression time
Any tips on how to troubleshoot this issue?
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?
flalarSure 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?
Could you please tell me which version is this? We had a couple of bugs in 12.x/13.x about this that were corrected later. Did you take a packet capture? If so, could you please share it? I'm just trying to work out whether you've verified your statement, i.e. that BIG-IP sends a brotli compressed version to a client that doesn't support it.
- flalar
Thank you for your attention
We dont have a packet capture, but in the IE dev tools we can see IE11 sends "Accept-Encoding: gzip, deflate" in the request header and gets "content-encoding: br" back in the response header. IE11 is not able to render/interpret this content so we're pretty certain this is the case
We can also see the response has the Age header indicating it is served from cache.
When we remove the web acceleration profile everyting is fine and dandy again. That is the IIS origins serve the right encoding according to the Accept-Encoding header and alo adds the Vary: Accept-Encoding header to the response.
We are on BIG-IP 13.1.3 Build 0.0.6 Final
In that case, it could potentially be a bug.
I didn't find a match when looking at our internal database so I'd advise you to open a Support case with F5.
They're very helpful and if it is a new bug they can fix it for you.
All the best,
Rodrigo
GT92Nimbostratus
Hi Flalar, did you ever get an answer on this? We are seeing issues with F5 not caching any compressed content, but does cache non-compressed version. Was on 13.1.3 but just upgraded to 14.1, same issue.
- flalar
We were advised by our service provider not to use the web acceleration feature in F5 as they had experienced other issues with this feature as well. So no news on this from my side
- flalar
Rodrigo_Albuque do you know if this issue was ever fixed in any newer releases?
Hello
It could be a variety of issues. I'd advise you to reach out to F5 support so they can properly check your case individually.
You can do some research on F5's bug tracker: https://my.f5.com/manage/s/bug-trackerI did not find anything and that's why I asked you to contact their support.
If they determine it is a bug, please update this thread to keep us informed.
