- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 08 Mar 2007 18:10:27 +1300
- 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 UTC