Forum Discussion
iRule for forcing https
Issue:
Trying to bring up a parallel site for ONES main production site that goes live on Tuesday. Using an iRule for forcing https:
when HTTP_REQUEST {
HTTP::redirect https://[HTTP::host][HTTP::uri]
}
The problem is that when a FORM SUBMIT comes in, the fields are all blank.
F5 Support response:
Here is a example from devcentral:
rule redirect_rule {
when HTTP_REQUEST {
HTTP::redirect https://[HTTP::host][HTTP::uri]
}
}
This rule should just issue a redirect for all traffic that goes to the port 80 virtual server should look like the following:
when HTTP_REQUEST {
[HTTP::redirect "https://[HTTP::host][HTTP::uri]"]
}
This rule waits for the request after the client finishes the tcp handshake in order to fill in the host and uri information and then issues the redirect.
In order for the pool to work the virtual server must use the default or customer http profile for the HTTP Profile section in the Virtual Server. This allows the virtual server to parse the http information.
His BIGIP is at version 9.1 so he is not having to dealing with previous versions issues on this, but our example doesn't currently
work for him. The parameters not coming thru. Mind you this is a form post.
Just to be clear on the problem:
We've confirmed that if a form does a POST ** to another web template ** and the F5 redirects it to "https" because the form 'action' explicitly says "http:" The end result is that all the FORM FIELDS are lost. They can't just change the 'http' to https' manually because most those calls come from other systems. How can that PAYLOAD be saved?
They need to be able to redirect http using the F5 to https without losing the form fields. If there is a better way to handle this other than the redirect, then me know. Otherwise, what needs change in this irule to get the rest of the data there:
when HTTP_REQUEST {
[HTTP::redirect "https://[HTTP::host][HTTP::uri]"]
}
Is more needed beyond the HTTP_REQUEST? The examples I see are for how to do things when you want to change the uri, not the protocol. Isn't that why we are having to do the redirect?
- A quick note:
I don't think you can pass POST data via a 302 redirect. The 302 allows for a location to be specified and text indicating that the user will be redirected.
If the application will accept it, you could try to use an iRule to convert the POST data to variables in the URI for a PUT to send back to the client.
Aaron 
David_Hicks_224Nimbostratus
Here's the background (I'll try to be brief). This is at a university with a central IT shop, but with dozens of other colleges and departmetns using our services. One of those services is a somewhat "universal" forms submission utility that was developed a long time ago. It takes in all types of content with variable lengths, etc. So INSIDE the Web content THEY develop, they can use our utility for their POSTs. We also use it internally. For our internal calls to it, we have just added HTTPS to the call and all is well. For the others that are using it, they will need to do they same thing, but we just found out about this problem and there isn't time to get everyone using it to make the change to HTTPS. In a month from now, that will all be corrected, but until then, we need to move forward. So this is the iRule we WERE using:
when HTTP_REQUEST {
HTTP::redirect "https://[HTTP::host][HTTP::uri]"
}
Which has NOW ben modified to:
when HTTP_REQUEST {
if { [HTTP::method] equals "POST" && [string tolower [HTTP::uri]] contains "/utility/processform.cfm" } {
}
else {
HTTP::redirect "https://[HTTP::host][HTTP::uri]"
}
}
For temporary use, it's functional. It's certainly not optimal and we don't plan to keep it any longer than needed. What do you think?- It looks as though the method you're using now is probably your best option for the short term, until you can get the people posting to your application to re-write their links to HTTPS.
It's unfortunate that you're just receiving the random posts. If they were sending a GET for a page first, it'd be easy to convert them to https with a redirect. Since the POST is the first transmission through the BigIP, there's just not much that can be done.
-Colin
