dragonflymr
May 23, 2017Cirrostratus
Web 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?
Piotr