Forum Discussion

flalar's avatar
flalar
Icon for Altocumulus rankAltocumulus
Oct 29, 2019

HTTP 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? 

9 Replies

Sort By
  • Rodrigo_Albuque's avatar
    Rodrigo_Albuque
    Icon for MVP rankMVP
    Oct 30, 2019

    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?

    • flalar's avatar
      flalar
      Icon for Altocumulus rankAltocumulus
      Oct 30, 2019

      Sure 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? 

  • Rodrigo_Albuque's avatar
    Rodrigo_Albuque
    Icon for MVP rankMVP
    Oct 30, 2019

    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's avatar
      flalar
      Icon for Altocumulus rankAltocumulus
      Oct 30, 2019

      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

       

      • Rodrigo_Albuque's avatar
        Rodrigo_Albuque
        Icon for MVP rankMVP
        Nov 06, 2019

        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

  • GT92's avatar
    GT92
    Icon for Nimbostratus rankNimbostratus
    Jun 25, 2020

    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's avatar
      flalar
      Icon for Altocumulus rankAltocumulus
      Jun 26, 2020

      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

    • Rodrigo_Albuque's avatar
      Rodrigo_Albuque
      Icon for MVP rankMVP
      Mar 30, 2023

      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-tracker

      I 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.