Forum Discussion

mike_aws_119486's avatar
mike_aws_119486
Icon for Nimbostratus rankNimbostratus
May 02, 2014

F5 APM and "Keep Accept Encoding"

Hi there,

 

Have an app that works fine directly through LTM on the LAN but not via APM Portal Access (11.4.1)

 

After lots of tracing/HTTPWatch and TCPDUMPs the vendor states that the F5 platform is stripping the Accept-Encoding header and that we need to disable compression or enable "Keep Accept Encoding".

 

On the LTM VIP for the App (direct) compression is not enabled, on the LTM VIP for the APM Portal Acccess it is.

 

Disabling compression on the LTM VIP associated with the APM Portal doesn't solve the issue. Creating a custom HTTPcompression with "Keep Accept Encoding" enabled and applying this to the LTM VIP associated with the APM Portal doesn't solve the issue.

 

Can anyone think there a reason why when APM is configured that the F5 platform is stripping the Accept-Encoding header even though compression is disabled at the LTM VIP level?

 

Also ideally I don't want to disable compression on the entire APM Portal as it might impact the other apps accessed.

 

Have raised a case but interested in any thoughts!

 

3 Replies

  • Mike, any update from support? Have you looked at using a layered VIP for the portal access?

     

  • You might have it configured somewhere else in the system. I think it might be a question of prioritization.

     

    From "Manual Chapter: Accelerating HTTP Traffic Using HTTP Compression and Web Acceleration" http://support.f5.com/kb/en-us/products/wa/manuals/product/wa_implementations_11_0_0/3.html

     

    in the table titled "Compression is prioritized in accordance with provisioned modules and iRules®."

     

    Local Traffic Manager compression settings, defined by HTTP Compression profile settings, receive third priority, superseded by any iRule settings or WebAccelerator system compression settings.

     

  • I'm currently encountering a problem where applying a WEBSSO profile is causing the content of the Accept-Encoding header to be stripped which causes the backend to return an HTTP 406. This is caused by enabling SSO logging at the Debug level.