Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

HTTP to HTTPS policy injecting "/Location: https:///" into URL and breaking application

We have an application I'm load balancing with my LTMs that I was initially told would just need basic load balancing and http to https redirection. Now I find out they are running it out of Citrix so they can use single signon for multiple apps and when they go to a different app it then makes a request to this one and then fails. If I disable the http-https it works in http or https. When enabled it fails trying to go to the URL: https://myapp.domain.com/Location:%20https:///ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server and I think the https rewrite is somehow inserting the "Location:%20https:///" which I don't want. I think the path should be: https://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server and would work. If anyone has any suggestions on how to prevent this or delete "Location:%20https:///" I'd greatly appreciate the help! The right answer would be for the application owner to alter the request they are making but in this environment it is not going to happen and I need to resolve with the LTM.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

That might just work. Going back to the original HTTP-HTTPS redirect code, when the URI looked like this:

/Location:%20https:///ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server:%20BigIPConnection:%20closeContent-Length:%200

You could do something like this in your HTTPS VIP:

when HTTP_REQUEST {
    if { [HTTP::uri] starts_with "/Location:" } {
        HTTP::uri [findstr [HTTP::uri] "///" 2]
    }
}

This will extract all of the URI string after the "///", but leave one "/" behind.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Are you using the default, or a generic HTTP-to-HTTPS redirect iRule? If so, do you by chance have that iRule applied to HTTPS VIP? "Location" is generally the header name used in an HTTP 30x redirect. Can you elaborate on your configuration?

0
Comments on this Answer
Comment made 22-Jan-2014 by Rob 133
Hi Kevin, I have a policy defined that does the HTTP-HTTPS. I don't remember if I built it or if it got created as part of a code upgrade. Is is defined as: Target: http-reply Event: request Action: redirect Parameters: location https://[getfield [HTTP::host] ":" 1][HTTP::uri] Thanks, Rob
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Right, so assuming this is applied to the HTTP VIP, and is working there, do you also have it applied to the HTTPS VIP?

0
Comments on this Answer
Comment made 22-Jan-2014 by Rob 133
No, it is only applied to the HTTP VIP. My HTTP VIP doesn't even have a pool defined, it just redirects to HTTPS. I created 2 test VIPs that mirror these but do have a default pool assigned on HTTP and HTTPS. They both work as long as I don't apply the HTTP-HTTPS policy.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

If you don't, let's level set with something we know should work. Instead of the policy applied to the HTTP VIP, apply the built-in _sys_https_redirect iRule and see what that does. It provides the same functionality, but in iRule form. This is just on the HTTP VIP, with no pool applied.

0
Comments on this Answer
Comment made 22-Jan-2014 by Rob 133
Kevin- Thanks for all the help so far. Applied the default iRule instead of using the policy and it is still inserting the "Location:%20https:///" and failing.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Interesting. In the absence of any other influences, the iRule (and most probably the policy) would not be inserting anything into the redirect URI that wasn't in the original URI. So that leads me to believe there are other influences at play. Do you have any other iRules applied to the HTTP and/or HTTPS VIPs? Can you run a client side traffic analyzer like Fiddler or HTTPWatch to see where the "Location" string is introduced into the URI? Can you also capture on the server side, traffic coming directly from the web server, to see if the Location string is coming from there?

0
Comments on this Answer
Comment made 22-Jan-2014 by Rob 133
There's no other iRule, policies, etc. applied to these. The other app is encrypted and not load balanced and I wasn't able to discern much even with https decrypt enabled. I did just notice when unencrypted it was: GET /ibex1h.ibx?e=nf&axfind=&acctnum=9248789&medrec=T01275160&pid=&ssn= HTTP/1.1 and it looks like it using the relative path to the file. The HTTP-HTTPS appears to be putting https: in front of it.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Well, let's back up and talk about how this should work.

  1. With the HTTP-HTTPS iRule applied to the HTTP VIP, a user might navigate to:

    http://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server
    

    which hits the HTTP VIP, which issues an immediate redirect to:

    https://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server
    
  2. That redirect sends the user to the HTTPS VIP, where the application request is served.

The really weird thing is the "Location:%20https://" string in the URI, which is what you would normally find in the header of a redirect. Example:

HTTP/1.0 302 Found
Location: https://something...
...

So I'd suspect something is either intercepting/mangling the HTTP-HTTPS redirect, or this is coming from the application. So let me ask this. From a sequence perspective, when does the client try to make this goofy request, given the following flow:

  • Request to http://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server/

  • Redirect to https://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server

  • Request to https://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server

0
Comments on this Answer
Comment made 23-Jan-2014 by Rob 133
The client starts on https://myapp.domain.com and then they open a client lookup utility in another application that is hosted offsite that of course I can get no reasonable support from. That application is encrypted and I'm having difficulty determining what exactly is happening, but we did manage to catch "GET http://myapp.domain.com/ibex1h.ibx?e=nf&axfind=&acctnum=9248789&medrec=T01275160&pid=&ssn= HTTP/1.1" in the raw fiddler headers. This works as long as we don't rewrite it to https which of course is the default. I decided to try a different http-https iRule: when HTTP_REQUEST { if { [TCP::local_port] == 80 }{ HTTP::respond 301 Location "https://[getfield [HTTP::host] : 1][HTTP::uri]" } and the result did change but not for the better: https://myapp.domain.com/PermanentlyLocation:%20https:///ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server: BigIPConnection: closeContent-Length: 0 Now it has part of the 301 reply in it also? }
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Very interesting. This iRule would suggest that it's being used on multiple VIPs, because otherwise all requests on a port 80 only VIP would satisfy the "[TCP::local_port] == 80" requirement.

Just as a test, add some log statements into your HTTP-HTTPS iRule like this:

when HTTP_REQUEST {
    log local0. [HTTP::host]
    log local0. [getfield [HTTP::host] : 1]
    log local0. [HTTP::uri]
    HTTP::respond 302 Location "https://[getfield [HTTP::host] : 1][HTTP::uri]"
}
0
Comments on this Answer
Comment made 23-Jan-2014 by Rob 133
I also added just the logging statements to another iRule (MYAPP-LOGGING) and applied to the https VIP: Jan 23 12:20:19 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: myapp.domain.com Jan 23 12:20:19 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: myapp.domain.com Jan 23 12:20:19 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: /index.mpex Jan 23 12:20:19 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: myapp.domain.com Jan 23 12:20:19 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: myapp.domain.com Jan 23 12:20:19 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: /scripts/ibexccow.cab Jan 23 12:20:20 F5LTM1 info tmm1[14839]: Rule /Common/MYAPP_REWRITE80 <HTTP_REQUEST>: Jan 23 12:20:20 F5LTM1 info tmm1[14839]: Rule /Common/MYAPP_REWRITE80 <HTTP_REQUEST>: Jan 23 12:20:20 F5LTM1 info tmm1[14839]: Rule /Common/MYAPP_REWRITE80 <HTTP_REQUEST>: /ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn= Jan 23 12:20:20 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: myapp.domain.com Jan 23 12:20:20 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: myapp.domain.com Jan 23 12:20:20 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: /Location:%20https:///ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server:%20BigIPConnection:%20closeContent-Length:%200 There appears to be no host information when the /ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn= request is made via HTTP.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Is there any chance that the client used to make this call isn't a standard browser? Even with an HTTP/1.0 request, most browsers would insert a Host header (though not expressly required). Maybe something like this might help:

when HTTP_REQUEST {
    set host [HTTP::host]
    if { $host eq "" } {
        set host "myapp.domain.com"
    }
    HTTP::respond 302 Location "https://$host[HTTP::uri]"
}

It'll hard code the Host value if it doesn't exist in the request.

0
Comments on this Answer
Comment made 23-Jan-2014 by Rob 133
Kevin- Thanks again for all of your suggestions so far! I did try that iRule and it did insert the host, but in the browser the host was now listed twice: https://myapp.domain.com/Location:%20https://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server: BigIPConnection: closeContent-Length: 0 The log shows the initial request with no host and then it shows after the iRule inserted it: Jan 23 14:28:08 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: Jan 23 14:28:08 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: Jan 23 14:28:08 F5LTM1 info tmm[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: /ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn= Jan 23 14:28:08 F5LTM1 info tmm1[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: myapp.domain.com Jan 23 14:28:08 F5LTM1 info tmm1[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: myapp.domain.com Jan 23 14:28:08 F5LTM1 info tmm1[14839]: Rule /Common/MYAPP-LOGGING <HTTP_REQUEST>: /Location:%20https://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=Server:%20BigIPConnection:%20closeContent-Length:%200
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Okay, one more idea. Try to capture the HTTP redirect response on the wire from the HTTP VIP.

tcpdump -lnni 0.0 -Xs0 port 80

You may need to add some additional filters to clean up the capture, but the -Xs0 option will show you the clear text HTTP payload in the HTTP response from the HTTP VIP. What you're specifically looking for is the HTTP/1.x 302 Found message and following Location header. What you find here will determine WHO is actually sending this funky URL.

0
Comments on this Answer
Comment made 24-Jan-2014 by Rob 133
All of these applications are called from within a Citrix session and the trace shows the Citrix server requesting: GET /ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn= HTTP/1.0\r\n The the F5 responds with a status of 302: Location: https://myapp.domain.com/ibex1h.ibx?acctnum=9248789&medrec=T01275160&cibex=&pid=&ssn=\r\n Then the traffic shifts to https. It appears the F5 is doing what it is supposed to. Our Citrix tech is supposed to open a case with the vendor and see if they can check their side. If that goes nowhere which is quite possible I'm now thinking maybe I can build an iRule that looks for the malformed request and rewrite it and apply it on the https VS where it comes in.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi Kevin,

Wanted to say thanks again for your help and guidance. I fought with this and ended up decrypting some captures to get an idea of what was going on. My final solution that seems to work is:

 when HTTP_REQUEST {
    if { [HTTP::uri] starts_with "/Location:" } {
         set fixuri [findstr [HTTP::uri] "/Location" 13 ]
         HTTP::redirect https://[HTTP::host]/$fixuri
    }
}

Thanks, Rob

0