Forum Discussion
L4L7_53191
Nov 09, 2010Nimbostratus
Felix: this is a common issue. Here's the high-level idea of what is going on - your web servers are unaware that there is an upstream device doing SSL proxying. It's common for applications to build self-referencing redirects, which they will build based on their specific application configuration/context. So to the servers, they're normal old HTTP, so they'll redirect that way. Alternatively, as Jason mentions it's possible that there are hard-coded or dynamically generated references to http:// in the actual content being served.
For this issue, there are a few things to try. First, I'd take an HTTPWatch capture so you can see what is going on. If the server is issuing redirects via HTTP, it'll drive the solution one way. If the content has hard-coded references, it'll drive it another (Jason's stream profile, above).
-- If you're redirecting, look at setting up a custom HTTP profile, where you've got 'redirect rewrite' enabled and set to matching. Note that you may need a combination of this *and* a stream profile to change the content.
-- In many cases, you can configure your app server to be aware of an upstream proxy. For example, in Tomcat there's a server.xml setting called "ProxyPort" that will ensure that tomcat-built redirects are sent to the appropriate port.
Good luck, and if you can please post and update.
-Matt