Random HTTPS Redirects?!?!

Just to add to this, I've started doing some packet captures at various points to be 100% sure that it's not an application/app server issue...

 

 

Running a tcpdump on the back-end application server, I can trace the TCP connection for my GET request, and confirm that the response returned DOESN'T have HTTPS in it.

 

 

So it looks like the F5 is doing the HTTP>HTTPS redirect...

 

 

Excerpt from the TCP dump is:

 

GET /Gateway-web HTTP/1.1

 

 

User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

 

 

Host: postgateway.go-aheadstaging.card.co.uk

 

 

Accept: */*

 

 

 

 

HTTP/1.1 301 Moved Permanently

 

 

X-Powered-By: Servlet/2.5

 

 

Location: http://postgateway.go-aheadstaging.card.co.uk/Gateway-web/

 

 

Content-Type: text/html; charset=iso-8859-1

 

 

Transfer-Encoding: chunked

 

 

Date: Mon, 16 Apr 2012 11:25:29 GMT

 

 

 

 

0

 

 

More to follow...

 

 

Gav

Gav

 

 

Could it be the HTTP_Rewrite profile you've got set on the VIP, rather than the proxypass irule?

 

 

Rgds

 

Nathan

Posted By nathan on 04/16/2012 04:33 AM

 

Gav

 

 

Could it be the HTTP_Rewrite profile you've got set on the VIP, rather than the proxypass irule?

 

 

Rgds

 

Nathan

 

Nathan

 

 

Didn't realise you could do it on the HTTP profile.. Can't see anything obvious..

 

 

Relevant config:

 

gavinw@act-bun-f502(Active)(/Common)(tmos) list /ltm profile http HTTP_Rewrite

 

ltm profile http HTTP_Rewrite {

 

app-service none

 

defaults-from http

 

redirect-rewrite all

 

}

 

gavinw@act-bun-f502(Active)(/Common)(tmos) list /ltm profile http http

 

ltm profile http http {

 

adaptive-parsing enabled

 

app-service none

 

basic-auth-realm none

 

lws-width 80

 

max-header-size 32768

 

oneconnect-transformations enabled

 

pipelining enabled

 

request-chunking preserve

 

response-chunking selective

 

}

 

 

 

Cheers

 

Gavin

 

Gav

 

 

From the rewrite profile it's set at All (the default is none) so it will rewrite as https all "HTTP 301, 302, 303, 305, or 307 redirects" and from your initial post there's a redirect from /Gateway-Web to Gateway-Web/ - i think this askf5 doc will explain:

 

 

http://support.f5.com/kb/en-us/solutions/public/6000/900/sol6912.html

 

 

Alongside a tech tip about redirects:

 

 

https://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/220/Rewriting-Redirects.aspx

 

 

Rgds

 

N

Ahh, ok... Wasn't aware that that was how the redirect-rewrite functionality worked...

 

 

Seems like slightly strange functionality if I'm honest...

 

 

Will review in a bit more detail and see what my options are.

 

 

Cheers

 

Gav

Ok, think I've got a work-around to this issue...

As I'm using ProxyPass, I thought it's the logical place to make the correction, rather than relying on redirect-rewrite in the HTTP Profile.

Below is a patch that I've generated against the v10.5 ProxyPass rule.

Logic was that the additional correction of the Redirect location value is only required when the rule is not rewriting the Response Payload, as the Location is rewritten already as part of that process.

Was also only interested in Redirect responses as application links are fine.

Comments welcome.

Gav

 @@ -474,6 +476,20 @@
             log local0. "$log_prefix: Rewriting response content enabled, but disabled on this response."
          }
 
+  Check for Redirect responses
+ if { [HTTP::is_redirect] } {
+if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Response is redirect. Checking Location Header."}
+
+ Get the protocal from the Location header value. 
+set redirect_proto [string range [HTTP::header "Location"] 0 [expr [string first : [HTTP::header "Location"]] +2]]
+if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Redirect Proto is: $redirect_proto." }
+if { not ($redirect_proto == $protocol) } {
+if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Redirect Proto doesn't match request protocol. Correcting." }
+HTTP::header replace Location [string map -nocase "$redirect_proto $protocol" [HTTP::header Location]]
+}
+
+ }
+
           Need to explicity disable the stream filter if it's not needed for this response
           Hide the command from the iRule parser so it won't generate a validation error
             when not using a stream profile 

Is it possible that your back end server contains some hard coded https:// ?

 

 

To debug I'd put in a listener for the 443 and terminate at the F5 and the following iRule:

 

when HTTP_REQUEST {

 

set H [HTTP::host]

 

set U [HTTP::uri]

 

 

log local0.info "[IP::client_addr] $U"

 

}

 

 

I had to so this lately to watch who & what was being called on an old VIP I was decom.

 

 

This isnt a solution to your problem but it may help with some debug, to track what was asked for over https://

Could be useful in some scenarios I think :)

 

 

As above, think the issue has been tracked down to the redirect-rewrite value in use. By adding the above block to the ProxyPass iRule we're using, the issue has been resolved.

 

 

Cheers again for assistance.

 

 

Gav