F5 SSL offload .. redirects traffic back in http format

Hi, Initial investigation seems issue with backed server but Can you please paste the F5 configuration.

I don't have that info unfortunately its configured by a 3rd party. I am responsible for the application. if the F5 has offloaded the traffic and redirected to my server - would it not then "onload" the response back to the client ?

reading a little .. would a http > https redirect (irule ?) be the answer here ?

The answer would seem to be a matter of what I like to call "the proxy effect". In short, your application is quite probably not designed to understand that a proxy can sit in front of it. In most cases that means that the application is spitting out absolute URLs in HTTP redirects and in document object references (images, script, etc.). You're getting to the main page fine, but then any information sent back to the client from the server has an absolute URL reference to (instead of There are a number of ways to address this, each dealing with different aspects of the problem. Let's start with the redirects. If it's a simple of matter of changing http:// to and the rest of the URL is correct, then you can simply enable the Redirect Rewrite in the HTTP profile. This will catch any http:// 30x redirects from the server and rewrite them to The following iRule will do basically the same thing:

when HTTP_RESPONSE {
    if { ( [HTTP::header exists Location] ) and ( [HTTP::header Location] contains "http://" ) } {
        HTTP::header replace [string map -nocase {"http://" "https://"} [HTTP::header Location]]
    }
}

If the URL returned by the server is actually different as well, then you'd need to modify the iRule above to replace on URL for the other. You haven't mentioned anything about HTML content rendering, so I'll leave it at HTTP header management for now. Give this a shot and let us know.

Thanks for your input Kevin - correct my application has no knowledge of the F5 and receives the requests via http and sends them back as such, hopefully your initial analysis is correct and enabling the redirect rewrite will provide the solution as it stands the URLs are correct apart from http/https and adding the (s) to http in the URls connects successfully.

Regards.

Hi Kevin .. looks like we do have some rendering issues also (ie broken icon links and the like) - what were you going to add regarding this scenario ?

amass87,

There are a few different things you have to take into account:

1. SSL is a separate protocol, therefore HTTPS is simply HTTP (OSI layer 7) wrapped in SSL (OSI layer 6). This is, in most cases, completely separate from the logic of the application itself. In many cases you can simply add a client SSL profile to the F5 proxy, and nothing to the back to effectively offload the client side SSL at the F5. It would be cleartext (unencrypted) HTTP on the back side.

    

2. Sometimes an application will try to be "smart" about its surroundings. If the application server is listening on HTTP (maybe because there's a proxy in front offloading the SSL), the application will generate URLs that are http://. This of course is incorrect, and so you need iRules like the one above to rewrite the application's URLs so that the client continues to communicate on HTTPS.

    

So you need to do things here:

1. Establish what the URLs the application is sending, and when. So when you say "http:// in the header", you could either be talking about a 30x redirect, in which the redirect URL is in a Location header. Or you could be talking about HTML payload that contains references to objects (images, scripts, stylesheets, other pages, etc.) that are in this case http:// instead of https://. You need to understand which URLs are incorrect. That is usually accomplished with a client side capture tool like Fiddler or HTTPWatch.

    

2. You need to understand which side of the proxy is encrypted and which is not. If the server side is listening on HTTP only, then you don't add an SSL profile to the server side of the proxy.