Forum Discussion
HTTP 302 redirect
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_12Historic F5 AccountYou can certainly check to see if the status on the HTTP response is 302:
when HTTP_RESPONSE { if { [HTTP::status] == 302 } { ...
"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.
- umiotoko_95283
Nimbostratus
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. :-)
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com