About redirections...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

About redirections...

sebastian nielsen
About this page: http://www.w3.org/QA/Tips/reback
 
 
A problem with the "standard" redirects is that they resubmit any information that are submitted to a page that redirects.
For example:
 
Page showing login form = A
Page where information is posted = B
Page that the user should go to after login = C (suppose this is a third party site)
 
The problem here, is that when a user logons with the form on page A, the data gets then sent as supposed to
page B. But then page B issues a "standard redirection" to page C. The browser will then resubmit the login
information to page C. This is not what a webmaster wants if the C-page is a third party page that only should get a "identifyer" that a user has logged in, not which username and password the user has on site B.
 
Some browser has a setting to turn off redirection for POST requests. But that setting completely disables the redirection HTTP codes for POST request which means that the user will see a error message, or a blank page, depending on which browser is used.
 
If META refreshes is used, the form information isnt redirected.


Skaffa nya Windows Live Messenger! Prova på!
Reply | Threaded
Open this post in threaded view
|

Re: About redirections...

Jon Jensen-3

Sebastian,

You're misunderstanding how browsers and redirects work. Here's what
actually happens:

Browser does a POST to page B.
The server responds with an HTTP redirect informing the browser to go to
page C.
Browser does a GET to page C. None of the information in the previous
POST gets resubmitted.

There are a couple ways you can verify this is taking place. On the
server-side, you can see exactly which requests are being handled by
looking at the logs. In this example, you would see a POST resulting in
a redirect, followed by a brand new GET request. If you are using the
Firefox web browser, the Firebug or LiveHttpHeaders extensions allow you
to see exactly which requests are being sent by the browser, including
what data is being posted.

Regards,

Jon Jensen

sebastian nielsen wrote:

> About this page: http://www.w3.org/QA/Tips/reback
>  
>  
> A problem with the "standard" redirects is that they resubmit any
> information that are submitted to a page that redirects.
> For example:
>  
> Page showing login form = A
> Page where information is posted = B
> Page that the user should go to after login = C (suppose this is a
> third party site)
>  
> The problem here, is that when a user logons with the form on page A,
> the data gets then sent as supposed to
> page B. But then page B issues a "standard redirection" to page C. The
> browser will then resubmit the login
> information to page C. This is not what a webmaster wants if the
> C-page is a third party page that only should get a "identifyer" that
> a user has logged in, not which username and password the user has on
> site B.
>  
> Some browser has a setting to turn off redirection for POST requests.
> But that setting completely disables the redirection HTTP codes for
> POST request which means that the user will see a error message, or a
> blank page, depending on which browser is used.
>  
> If META refreshes is used, the form information isnt redirected.
>
> ------------------------------------------------------------------------
> Skaffa nya Windows Live Messenger! Prova på!
> <http://get.live.com/messenger/overview>



Reply | Threaded
Open this post in threaded view
|

Re: About redirections...

David Dorward-3
In reply to this post by sebastian nielsen

On 26 Jun 2007, at 17:47, sebastian nielsen wrote:
> A problem with the "standard" redirects is that they resubmit any  
> information that are submitted to a page that redirects.

Really? The tip doesn't explicitly mention 303 redirects, but still...

10.3.4 303 See Other

The response to the request can be found under a different URI and  
SHOULD be retrieved using a GET method on that resource. This method  
exists primarily to allow the output of a POST-activated script to  
redirect the user agent to a selected resource. The new URI is not a  
substitute reference for the originally requested resource.

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


... however, as far as I know, pretty much all user agents treat 302  
and 301 redirects as if they were 303 as far as converting to a GET  
request is concerned.

--
David Dorward
http://dorward.me.uk/
http://blog.dorward.me.uk/