Forum Discussion

SteveEason's avatar
SteveEason
Icon for Cirrus rankCirrus
Sep 18, 2019

HTTP to HTTPS redirect is stripping out URL referral info

We are using an iApp to build out our site using the default HTTP port 80 to HTTPS port 443 options. Our developers have started using referral logic on one of the sites and if a client of ours uses the HTTP:\\ URL, to correctly redirects to HTTPS however, it drops the referral information. So for example, the client has the following URL HTTP://www.mainwebsite.com/?pc=ABCD. When the click the link, they get rerouted to HTTPS://www.mainwebsite.com. So it drops the extra information. If the client goes straight to HTTPS://www.mainwebsite.com/?pc=ABCD, it works just fine.

 

What would be the best way to maintain this information during the redirection?

devops
LTM
  • crodriguez's avatar
    crodriguez
    Ret. Employee
    Sep 18, 2019

    You need to make sure you are including HTTP::uri in the redirect string you generate in the iApp. (I am assuming the redirect happens via an iRule the iApp generates and associates with the port 80 virtual server.)

    The example below is from the f5.http iApp which is supplied by default on a BIG-IP system:

    set redirect_rule [string map [list _PORT $redirect_to_port] {
   when HTTP_REQUEST {
      HTTP::redirect https://[getfield [HTTP::host] : 1]:_PORT[HTTP::uri]
   }
}]
  • SteveEason's avatar
    SteveEason
    Icon for Cirrus rankCirrus
    Sep 18, 2019

    This is what is currently in the iRule.

     

      when HTTP_REQUEST {

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

      }

     

    And we still end up losing the info.

  • crodriguez's avatar
    crodriguez
    Ret. Employee
    Sep 18, 2019

    Hmmmm. Strange, indeed. Without looking at the entire iApp (and more), I have nothing really concrete to offer except to eliminate the obvious by making sure you are passing through this iRule code and, more importantly, that the URI is intact when you do. For example, add the following before the HTTP::redirect command:

    log local0. "HTTP URI is currently [HTTP::uri]"

    If the log message is not produced, it would seem something else is doing the redirect (and without the URI). If the log message is produced and the URI is empty, something upstream (before the HTTP_REQUEST event is triggered) may be overwriting the URI. If the URI is normal, then you can look for a downstream culprit..