Actual flow of a redirect_to

I'm working on implementing SSL in my application and I have a question about how redirect_to actually works. Here's a scenario:

Suppose I want my login action to be available only over SSL so the username and password will be transmitted encrypted. In my controller, I would have something like

before_filter :require_ssl, :only => {:login}

and

def require_ssl
  redirect_to :protocol => 'https://' unless (request.ssl? or request.local?)
end

[ by the way, this is not necessarily how I'm doing it in my app, but this works very well for this question]

When the browser makes the initial request to the server, is the form data passed along at that time or is the redirect handled in some sort of handshaking process before the form data is passed? If the data is passed to the server in the initial request, then it will be unencrypted if it comes in on http, which really does no good because it is exposed between the client and server.

The question I'm trying to answer for myself is do I want my entire application behind ssl, just to be safe, or do I want to leave open those actions that don't really need it (very few in this case). I noticed that when you go to http://www.paypal.com, you are automatically redirected to https, so even the login form is already behind ssl.

Thanks for any insight and help in understanding this process.

Peace,
Phillip

There is no handshake magic. Rails simply sends a response to the
browser with a 302 header in it.

-Bill

Phillip Koebbe wrote:

Hi Bill,

So the form data gets passed to the server, the server responds with the 302 and the client resubmits the form data to the "new" url? In this case, the unencrypted data will be sent to the server first, then the encrypted data will be sent, correct?

Thanks,
Phillip

You got it.

Phillip Koebbe wrote: