Forum Discussion

GavinW_29074's avatar
Icon for Nimbostratus rankNimbostratus
Apr 16, 2012

Random HTTPS Redirects?!?!

Hi there,

I'm starting to configured some services on the F5 which support HTTP. Prior to this, all our services have been over HTTPS.

However I'm having some issues with random HTTPS redirects creeping in, which causes the connection to be rejected.

An example VIP config is:

 (/Common)(tmos) list /ltm virtual
ltm virtual {
    app-service /Common/
    ip-protocol tcp
    profiles {
        Caching_RPG { }
        HTTP_Rewrite { }
        oneconnect { }
        stream { }
        tcp {
            context clientside
        tcp-lan-optimized {
            context serverside
        wan-optimized-compression { }
    rules {
    snat automap

A request to this VIP returns:

curl -ik

HTTP/1.1 301 Moved Permanently


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

Connection: close

Vary: Accept-Encoding

If I connect directly to the back-end application server I don't get redirected to HTTPS...

So the only place I can think this is being introduced is in the ProxyPass iRule, as that's the main rule that responds to the client...

Any ideas????



8 Replies

  • 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






    Accept: */*





    HTTP/1.1 301 Moved Permanently



    X-Powered-By: Servlet/2.5






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



    Transfer-Encoding: chunked



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








    More to follow...



  • nathe's avatar
    Icon for Cirrocumulus rankCirrocumulus



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





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





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










    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










  • nathe's avatar
    Icon for Cirrocumulus rankCirrocumulus



    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:





    Alongside a tech tip about redirects:







  • 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.





  • 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.


     @@ -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 "[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.