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

RE: Redirection of a POST as a GET

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Thu, 8 Mar 2007 03:32:35 -0500
To: "'Adrien de Croy'" <adrien@qbik.com>
Cc: <ietf-http-wg@w3.org>
Message-ID: <00b001c7615c$53370a30$0702a8c0@Guides.local>

Adrien de Croy wrote:
> 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.

What is the source of data for your assertion?  Why is possible for a web
developer wanting to move a resource?  Not all POSTs original from the same
source file on the same server. Consider a search request that allows
someone from one site to POST to another.  Without being able to redirect a
POST that resource is effectively either cemented and never able to move, or
if it has to move it breaks any links that exist to the 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.

I can see the logic that a specific post being redirected to a random page
not designed to receive the post would be a bad thing, but I can't see why
anyone would ever configure a server to redirect to a resource that wasn't
design to receive the post.  

> 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.

Does HTTP support POST redirect?  I thought it did not.  If HTTP doesn't
support POST redirect, it would seem to me to be inappropriate to use the
fact you don't see anyone using it as justification for it not being needed,
right?

> 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.

I still don't see how anything could break unless the person issuing the 301
wants it to break.  Or maybe I'm just completely misunderstanding the issue?

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
Received on Thursday, 8 March 2007 08:32:45 GMT

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