uncacheable
1 TopicWeb Acceleration profile and changing HTTP/1.1 to 1.0
Hi, I am not HTTP expert but this behavior is quite a surprise to me - but maybe it's perfectly OK? Setup (tested on v11.2.0HF7): VS with Web Acceleration profile attached (based on optimized-caching), no OneConnect, no HTTP Compression Profile Request from client: GET /images/wwfr.png HTTP/1.1 Host: cache.test.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pl,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Request from BIG-IP to backend server GET /images/wwfr.png HTTP/1.0 Host: cache.test.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pl,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive If I will disable Web Acceleration profile then request from BIG-IP to server will be HTTP/1.1. So why such change? Another issue - I have iRule attached to VS to disable caching response on the client side: when HTTP_RESPONSE { HTTP::header insert Cache-control no-store } What surprised me is that BIG-IP is taking this header into account when deciding if server response is cacheable. That is quite strange as header is inserted on client side so should not influence server side decision - or I am wrong here? Piotr499Views0likes1Comment