Cache persistence on domain name

Please describe what you mean by "breaks". I don't see anything in the above rule that should affect SSL. Thanks.

Basically, the setup is an F5 with 3 interfaces, one to the internal network, one to a segment with proxy/caches and the third to a segment with firewalls and then out to the Internet.

 

The browser is pointing at a VIP on the F5 that has the rule applied to it. Requests hit the VIP, get load balanced to the proxy/caches and then back through the F5 and out to the firewalls and the Internet. Regular HTTP works just fine.

 

However, when I attempt to get to an HTTPS site, it fails. From the traces, I see the client make the request, it gets sent to the proxy/cache, out to the Internet. The server replies HTTP/1.0 200 Connection established, which I see getting to the proxy/cache and then the proxy/cache sends it back to the client, but the client never recieves the packet. I've put sniffers on the client and on the internal F5 interface, it just never comes out.

Are you terminating the SSL before going to the cache?

Nope.

 

Just sending it to the proxy/cache and from the proxy/cache, just out to the firewalls.

I would then also assume your clients are configured to use the vip as a proxy?

 

 

If so, you have to understand that https connections are proxied in a very different manner than http. The client first sends a CONNECT method to the proxy which causes it to establish a connection to the host. Upon making that connection, the proxy replies with a 200 OK and then passes all subsequent data directly between the client and target host allowing the encryption to succeed.

 

 

In order to handle this in the bigip, we have had to add a HTTP::disable command that turns off http processing after the 200 OK response has occurred. This command will be available in 9.0.5.

 

 

Once you have this command, then you will need to modify your rule to look for the CONNECT method and issue the HTTP::disable command to allow the encrypted connection to flow freely between the client and destination host.

 

 

You can read the following post for more background information on proxying an https connection, however you likely won't be able to use the rule in that post because it doesn't work with the http profile:

 

http://devcentral.f5.com/default.aspx?tabid=28&forumid=5&postid=1274&view=topic

 

 

Hope this helps.

Correct, our client's browsers are pointed at the VIP for their proxy.

 

Any idea when 9.0.5 will be available?

9.0.5 should be available, literally, any day now (possibly even today or tomorrow)...

 

 

Also, I'd like to point out that we are currently working on incorporating automatic support for the CONNECT method in the next major release (9.2). This means that the http parser will automatically disable itself after the connect method receives a 200 OK response from the proxy. So once this support is in, it will no longer be necessary to even write a special rule to handle it.

 

 

OK I see 9.0.5 is out, but I can not find in the release notes the HTTP::disable 'feature'.

My Rule is currently:

 
 when HTTP_REQUEST { 
    if { [HTTP::host] != "xxxxx" } { 
       pool Caches 
       set key [crc32 [domain [HTTP::host] 2]] 
        Make sure persistence record is added for this domain 
       persist hash $key 
    } else { 
       pool Caches 
    } 
 } 
 

Where would I stick tghe HTTP::disable in????

Ok, I don't have time to specifically test this, but I would assume sticking it at the end should be fine:

 
 when HTTP_REQUEST { 
    if { [HTTP::host] != "xxxxx" } { 
       pool Caches 
       set key [crc32 [domain [HTTP::host] 2]] 
        Make sure persistence record is added for this domain 
       persist hash $key 
    } else { 
       pool Caches 
    } 
    HTTP::disable 
 } 
 

You might alternatively only want to disable if the method is CONNECT, like so:

 
 when HTTP_REQUEST { 
    if { [HTTP::host] != "xxxxx" } { 
       pool Caches 
       set key [crc32 [domain [HTTP::host] 2]] 
        Make sure persistence record is added for this domain 
       persist hash $key 
    } else { 
       pool Caches 
    } 
    if { [string toupper [HTTP::method]] eq "CONNECT" } { 
        Proxy connect method should continue as a passthru 
       HTTP::disable 
    } 
 } 
 

 
 when HTTP_REQUEST { 
    if { [HTTP::host] != "xxxxx" } { 
       pool Caches 
       set key [crc32 [domain [HTTP::host] 2]] 
        Make sure persistence record is added for this domain 
       persist hash $key 
    } else { 
       pool Caches 
    } 
    if { [string toupper [HTTP::method]] eq "CONNECT" } { 
        Proxy connect method should continue as a passthru 
       HTTP::disable 
    } 
 } 
 

With this iRule, HTTP::disable only applies to HTTPS traffic, not HTTP traffic. Isn't it ?

If so, no need to issue HTTP::enable (if there is) for HTTP traffic, I guess.