For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

dragonflymr's avatar
dragonflymr
Icon for Cirrostratus rankCirrostratus
May 23, 2017

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

application delivery
cache hit
devops
http protocol change
irule
LTM
uncacheable
web acceleration

1 Reply

  • dragonflymr's avatar
    dragonflymr
    Icon for Cirrostratus rankCirrostratus
    May 24, 2017

    OK, should check AskF5 first. Still this article The BIG-IP WebAccelerator virtual server requests are translated to HTTP/1.0 is not explaining why caching profile needs to change requests to HTTP/1.0?

     

    Why caching content on BIG-IP requires HTTP/1.0 request to server?

     

    According to articles I found server is not obliqued to send HTTP/1.0 reply when receiving HTTP/1.0 request - mine is replying with HTTP/1.1 (Apache2). Only limitation seems to be that server should not use incompatible headers when replying using HTTP/1.1 - but not sure if it's a must or not.

     

    Piotr