Forum Discussion

DarkSideOfTheQ_'s avatar
DarkSideOfTheQ_
Icon for Nimbostratus rankNimbostratus
Jan 27, 2009

genric http to https question

I've done a couple of http to https irules and now find mysyelf wondering if I can accomodate this new request. We are using a single hostname for different applications (ex. server1.domain.com/click/123456/789 or server1.domain.com/open/some.jpg) and they would like me to redirect these requests to https. Can I do a generic redirect for 'http://server1.domain.com' to 'https://server1.domain.com' without using a specific https url as I've done with the other rules I've created? (ex of what i've done previously with exact url http://server1.domain.com to https://server1.domain.com/login.do)

 

 

*NOTE: the example above 'server1.domain.com/click/123456/789' the variables after /click/ will change, depending on what one is viewing in the app.

 

 

I hope this makes sense???

 

 

TIA,

 

DarkSide

6 Replies

  • You can redirect to the same host and URI that the client requested:

    http://devcentral.f5.com/wiki/default.aspx/iRules/HTTPToHTTPSRedirect_302.html

     
     when HTTP_REQUEST { 
      
         Check if Host header value has a length 
        if {[string length [HTTP::host]]}{ 
      
            Redirect to the requested host and URI (minus the port if specified) 
           HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri] 
      
        } else { 
      
            Redirect to VIP's IP address 
           HTTP::redirect https://[IP::local_addr][HTTP::uri] 
        } 
     } 
     

    Aaron
  • This matches all incoming HTTP traffic regardless of URL and redirects it to HTTPS. The redirect keeps the URL intact for the user and just redirects the port.

     

     

    when HTTP_REQUEST {

     

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

     

    }

     

  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Hey Jennifer, thanks for posting!

     

     

    One small but important correction:

     

    That code actually only changes the protocol scheme.

     

    If a non-standard (<>80) port is used, the value in the Host header will contain the port, which will in turn be included in the return value for HTTP::host.

     

     

    In that case, simply using [HTTP::host] will result in a redirect response to the same non-standard port over HTTPS (which in most cases will fail). Which just means that if you're redirecting traffic rec'd on another port, you will need to use the [getfield [HTTP::host] ":" 1] trick that's in the 301/302 codeshare redirect samples:

     

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/HTTPToHTTPSRedirect_301.html

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/HTTPToHTTPSRedirect_302.html

     

     

    /d
  • Yea, I saw this sample, but wasn't sure if it was too generic. We have a number of hostnames pointing to the same VIP (which is a resin cluster), but I only need to catch a specific one that may have a varying uri string.

     

     

    ex.

     

    server1.domain.com

     

    server2.domain.com

     

    server3.domian.com

     

    etc...

     

     

    I only need to catch 'server1.domain.com' and redirect it to https independent of the uri string following it.

     

     

  • Ah-Ha...I was indeed headed down the right path. I had taken the example I found in the sample pages(the same one hoolio posted) and was trying to put together what you posted. I've had to shelve my new Powershell book (wanted to start learning that this year) in place of learning this TCL stuff. Slow going...I equate it to learning to speak a new language, but I know I'll get there eventually.

     

     

    Thanks!!!

     

    -DarkSide
  • It's also useful to consider HTTP 1.0 requests which may not contain a host header. If the client didn't include a host header in the request, and you redirected to https://[getfield [HTTP::host] ":" 1]][HTTP::uri]", the client would get a redirect to https:///whatever/uri/they/requested.html, instead of a valid FQDN.

     

     

    Aaron