Redirect Needed.. please help

If this is a straight redirect, then the correct HTTP status code is 301. 4xx codes are meant for client errors. Here's a listing of the HTTP status codes

 

 

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

 

Click here

 

 

The rewrite redirect should do the job for you if your server is correctly returning 3xx status codes.

 

 

if all else fails, you could always write an iRule that listens on the HTTP_RESPONSE event. You can check the HTTP::status value and issue your own redirect with either the HTTP::redirect command or the HTTP::respond command (the former will take just a url, while the later will allow you to specify any HTTP status code.

 

 

-Joe

is there a way to check if the server is correctly returning 3xx code? Im new with this big ip so please bare with me as im learning .

 

 

thank you

Well, there is the HTTP::status command, (wiki reference: Click here) if you're looking to see what status the requests are being sent as.

 

 

To log this information you'd do something like this:

 

 

when HTTP_RESPONSE {
  log local0. "Status code is: [HTTP::status]"
}

 

This would tell you the status codes your systems are sending, if that's what you're looking to find out.

 

 

-Colin

not sure what im trying to find out :-), im to new to this to understand much of it, but basically if we terminate ssl on the iis server the programmers app works, if we terminate at the big ip, their app doesnt work. The details are explained in the first post in this thread. I dont know how to write irules but is someone can write something for me that would work i would appreciate it, thanks

I am working with Otto on this and I have a follow-up.

 

 

The rewrite redirect worked for situations where our application, via JBoss, sends an HTTP redirect, 3xx, to the client. We still have the problem where the scheme in the HTTP request is being changed from HTTPS to HTTP when Big IP is terminating the SSL. If we let our Big IP pass the SSL through to our IIS server, the scheme is unchanged (i.e. it remains HTTPS). Is there a way to stop Big IP from changing the scheme on the request from HTTPS to HTTP when it is terminating SSL?

 

 

Thanks!

 

 

Earnie!

Earnie, can you explain exactly what you mean when you are referring to "changing the scheme"?. If the BIG-IP is terminating an SSL connection and sending clear HTTP to the backend server the process goes like this:

 

 

1. Client establishes a HTTPS connection which the BIG-IP intercepts.

 

2. This is sent over port 443 (unless specifically configured otherwise).

 

3. The BIG-IP decrypts the GET/POST request.

 

 

4. BIG-IP opens a HTTP connection to the backend server on port 80.

 

5. The BIG-IP sends a new GET/POST request to the backend server.

 

6. The unencrypted data is sent to the backend server.

 

 

In no point is the protocol scheme "https or http" sent as part of the HTTP request. That is implied in the connection port and how the client and server negotiatate over that port. So, BIG-IP can't make the server think it's getting SSL when it's not.

 

 

But, If you are asking whether the BIG-IP can re-encrypt the data to your backend server, then the answer is yes. By adding a serverssl profile to your virtual server, the BIG-IP can decrypt the incoming connection and then re-encrypt it to your server. But this would defeat the purpose of utilizing BIG-IP to offload the decryption.

 

 

I'm not quite sure exactly where your issue is. Typically, in SSL offloaded situations like this, a common issue is that the backend server embeds fully qualified urls in the response payload (ie. http://server/path) instead of relative urls (ie. /path). Relative url's fix themselves as the browser will match them to the current host:port. Fully qualified urls are another story. If the client is connecting through a virtual setup for HTTPS but the server is returning a payload that contains a HTTP link then the link won't make it back to the server. In this case, you have a couple of options.

 

 

1. Use a stream profile (v9.2) to convert "http://server" to "https://server" in your responses. Here's a good forum thread on the stream profile:

 

 

http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=5097

 

Click here

 

 

2. Create an iRule to do 1 (1 is more optimial though).

 

 

3. Create a HTTP Virtual that redirects to the HTTPS counterpart. (this is probably your last option as it will require many round trips causing an unfavorable user experience.

 

 

Hope this helps...

 

 

-Joe

Joe,

 

 

Thanks for the advice. I see now where the problem creeps in. When Big IP opens an HTTP connection to the plain text side the scheme in the HTTP request object will of course be HTTP. I looked over your suggestions and I am not sure they will do for us. We can't change all HTTP references to HTTPS as our app has links to both our secure app (HTTPS) and our content site (HTTP) both using the same domain name.

 

 

I did read one forum posting about setting HTTP headers and this might be what we have to do.

 

 

Thanks!

 

 

Earnie!

Joe,

 

Is there a irule already out there to do what we need to do? or can you or someone you suggest help us write a irule to do what we need as you suggest?

 

 

thanks

Earnie pointed out that your application injects both http and https links to the same domain. Since I don't know your application, it's hard to recommend a solution to this.

 

 

There are iRules in the forum and code share that will read the response data and convert values from one format to another. If you can give me an exact format to look for for a search string (http://www.foo.com), then writing the rule to change that to something else (https://www.foo.com) would be fairly trivial. But, as Earnie pointed out, you have both formats pointing to the same domains in your application so a simple string compare probably won't work.

 

 

 

-Joe