Forum Discussion

dj_22414's avatar
dj_22414
Icon for Nimbostratus rankNimbostratus
Aug 11, 2009

Issue wrt HTTP redirect in response

Hi,

 

We have BigIP running as SSL terminator. We have irule for http requests to convert HTTP to HTTPS.

 

 

The issue is, if server behind bigip returns a HTTP response as 302 redirect to say site http://www.abc.com, then BigIP is rewriting the response location header to change 302 to https://www.abc.com.

 

 

We have set HTTP redirect rewrite to NONE, but even then bigip is modifying response header. We want HTTP response to be passed as is, but we are not sure as how to implement it. Any help in this respect would be greatly appreciated.

 

 

Regards,

 

dj

10 Replies

  • If you have redirect rewrite set to none on the HTTP profile, LTM shouldn't rewrite the redirect. Are you sure you're using the default HTTP profile on the virtual server? Or do you have any iRules that would potentially rewrite the response Location header? You could use a tcpdump to confirm the response received from the server versus what LTM sends to the client.

     

     

    Aaron
  • Thanks Aron for response.

     

     

    We are using default http profile on virtual server. I will once again check this config though. The only irule we have is as follows:

     

     

    when HTTP_REQUEST {

     

    if { [TCP::local_port] == 80 }{

     

    HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]

     

    }

     

    }

     

     

    We did verify using tcpdump, as well as apache logs to see what is being sent out of apache (server behind LTM). The apache did send http://..., but LTM converted it to https://..

     

     

    Regards,

     

    Dhananjay.
  • Is it possible that LTM is not rewriting the request, but the HTTP request the client makes is being redirected by that iRule to HTTPS?

     

     

    Aaron
  • No, certainly not.

     

     

    The 302 is generated by server behind LTM and by client. And, this is a redirect to altogether a different site, so LTM will not receive the redirect.

     

     

     

    Regards,

     

    Dhananjay.
  • Hi Aaron,

     

     

    We figured out the problem, and your questioning did help us sort out the issue. Thank you!

     

     

    The active profile was HTTPS one, and it has Rewrite Redirect set to ALL.

     

     

    We did notice a weird thing though. When we set the Rewrite Redirect to Matching, the problem I mentioned earlier got solved, but got into another issue.

     

     

    The backend server is on HTTP, and when that server redirects "GET /x/y?action=abc" to "http://abc.com/x/y?action=xyz", f5 is not rewriting the the redirect, even when the setting is "Matching".

     

     

    I suppose matching means, match on URL part right? So, f5 should have redirected HTTP to HTTPS .. not sure why it is not doing so.

     

     

    Regards,

     

    Dhananjay.

     

     

    Regards,

     

    Dhananjay.

     

     

     

     

    Regards,

     

    Dhananjay.
  • From SOL 6912:

     

     

    * Choose All to rewrite any HTTP 301, 302, 303, 305, or 307 redirects to HTTPS

     

    * Choose Matching to rewrite redirects when the path and query URI components of the request and the redirect are identical (except for the trailing slash)

     

    * Choose Node to rewrite redirects when the redirect URI contains a node IP address instead of a host name, and you want the system to change it to the virtual server address

     

     

    Since your URI components aren't identical it looks like this is the expected behavior with Matching set.

     

     

    -Matt
  • Hi Matt,

     

     

    Thanks for response.

     

     

    I dont get the logic behind matching setting.

     

     

    The incoming URL was -> https://abc.com/x/y?action=abc. This was redirected by server behind f5 to http://abc.com/x/y?action=xyz. My guess is, matching should work here.

     

     

    Also, could you please point me to some examples/doc on this, as I could not find this in manual.

     

     

    Regards,

     

    Dhananjay.
  • I got following info from sol 6912:

     

     

    Under Settings, set Redirect Rewrite to All, Matching, or Nodes, depending upon your configuration

     

     

    For example:

     

     

    * Choose All to rewrite any HTTP 301, 302, 303, 305, or 307 redirects to HTTPS

     

    * Choose Matching to rewrite redirects when the path and query URI components of the request and the redirect are identical (except for the trailing slash)

     

    * Choose Node to rewrite redirects when the redirect URI contains a node IP address instead of a host name, and you want the system to change it to the virtual server address

     

     

     

    This means, the only option I have is to set it to ALL, but it wont work for me.

     

     

    Other way would be, to set it to NONE, and have irule to rewrite http to https in case domain is hosting domain, else leave it as is.

     

     

     

    Regards,

     

    Dhananjay.
  • Hi Dhananjay,

    You can use an iRule to be more selective on which redirects to rewrite:

     
      when HTTP_RESPONSE { 
      
         Check if server response is a redirect 
        if { [HTTP::header is_redirect] and [string tolower [HTTP::header Location]] contains "abc.com"} { 
      
            Log original and updated values 
           log local0. "Original Location header value: [HTTP::header value Location],\ 
              updated: [string map -nocase "http:// https://" [HTTP::header value Location]]" 
      
            Do the update, replacing myold.hostname.com with mynew.hostname.com 
           HTTP::header replace Location [string map -nocase "http:// https://" [HTTP::header value Location]] 
        } 
     } 
     

    Aaron
  • Fantastic Aaron.

     

    Your irule rules.

     

    I wrote my version of irule, but yours is far better. Using online resource, I could not come up with anything to replace Location header strings inline. I had to rely on breaking url in port/host/url, and then combine again.

     

     

     

    Regards,

     

    Dhananjay.