Forum Discussion

Lightspeed_VT_5's avatar
Lightspeed_VT_5
Icon for Nimbostratus rankNimbostratus
Nov 16, 2007

HTTP 302 redirect

Our application requires session persistence. Because we have a lot of users sharing IP addresses (i.e. corporate clients), we've enabled OneConnect.

 

 

For reasons unknown, requests for existing pages on the server are returning an HTTP 302 Connection: close instead of HTTP/1.x 200 Connection: keep-alive.

 

 

I've never written an iRule, but is there a straightforward way to intercept these erroneous 302 responses, rewrite the URI and process the page?
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    You can certainly check to see if the status on the HTTP response is 302:

    
    when HTTP_RESPONSE { 
      if { [HTTP::status] == 302 } {
        ...

    The question is, how do you identify the "bad" 302s as opposed to "good" ones, and then how do you convince the webserver to send back the proper page when you retry?

    Perhaps I'm misunderstanding, but if the webserver is sending 302s, I don't think a simple iRule is going to solve your problem.

    Colin
  • "Because we have a lot of users sharing IP addresses (i.e. corporate clients), we've enabled OneConnect."

     

    I don't think OneConnect is what you want. OneConnect is tcp multicasting. It allows for multiple client tcp connections to utilize a single serverside tcp connection.

     

    http://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html

     

    If this is for HTTP traffic you more likely want to be using cookie persistence. So that different users with the same source IP will have unique persistence cookies.

     

    http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-4-0/10.html

     

    None of the above addresses the underlying issue. If your server is responding with a 302, you should look at why the server keeps doing this instead of attempting to put a band aide on the issue.

     

  • I run an application that is extremely sensitive to persistence on a farm of 20+ web servers.

     

    You will want to enable a suitable client-to-F5 persistence, I set the pool for cookie persistence but overwrite it with UIE in an iRule. (My clients are embedded systems and the old ones don't honor cookies, so I use SSL credentials and an in-memory table, but that's another story).

     

    I've found that oneConnect is critical to maintaining the F5 to web server persistence for client traffic, if oneConnect is removed I have seen traffic bounce across web servers.

     

    If I recall correctly there was a less-than-documented feature in 10.x where a oneConnect profile shared across more than one VIP resulted in some confusion when distinct traffic from the same source IP hit different VIPs. To fix this, I have a unique oneConnect profile for each VIP. Each profile also specifies the subnet mask 255.255.255.255 .

     

    Finally, round-robin is (in my experience) not very round. Use Least connections (member) with a priority group (greater than 1).

     

    As for the source of your 302's, wireshark or clonepool dump your traffic. That's a server problem. :-)