W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: Redirection of a POST as a GET

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 08 Mar 2007 18:10:27 +1300
Message-ID: <45EF9AC3.3070104@qbik.com>
To: Mike Schinkel <mikeschinkel@gmail.com>
CC: ietf-http-wg@w3.org


In many if not most cases, the case where a response to a POST is a 
redirect is as a result of some CGI or server-side process running some 
web-based application.

in these cases, the web application (e.g. webmail, etc) really doesn't 
expect that the redirect they pass back to the client will result in a 
POST - they expect it to be a GET.  In fact, often the target location 
isn't even a script / executable resource, but a pure HTML resource.

Trying to do a POST request specifying a non-executable target resource 
I wouldn't expect to work.  And worse would be in cases where the target 
file would in other cases expect a POST request.  In this case, the POST 
data would be all wrong, being the data from a different resource.

It's an extremely common technique.  I've never seen a web application 
that accepts POST and returns a redirect expect anything other than a 
GET from the client in response.

most user login web pages do this for instance, shopping carts.. in fact 
most web forms that use POST.  The list is endless.

lots of things that would break in other words if the spec were changed 
to mandate a POST as a followup request in this scenario.

Adrien

Mike Schinkel wrote:
> Adrien de Croy wrote:
>   
>> If any UA used the original POST method again, 
>> it would break most existing server/site 
>> implementations.  
>>     
>
> How would it break the implementations?
>
>   
Received on Thursday, 8 March 2007 05:10:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:00 GMT