Re: Redirection of a POST as a GET

Eric Lawrence wrote:
> << As it's been specified since day 1 (before HTTP/1.0 even) that the original request should be retried with the new Request-URI without changing the request method we can not change the specs in such manner that this would not be a correct thing to do.>>
>
> Do you know of ~any~ user-agent which will perform a POST after receiving a 302 in response to the POST?  I have yet to encounter any such client.
>
>   

there aren't any that I have found either, and IMO it makes no sense to 
retry with another POST, the result of the POST was the redirection.  
The redirection in this case is not used to indicate "try again some 
other location", it is used to indicate a result, which is obtainable at 
the new location.  So this is contrary to the spec, but everyone does 
it.  You'd have to ask website designers if there would be a use for a 
return code that meant "try the exact same request at this new location".

If any UA used the original POST method again, it would break most 
existing server/site implementations.  Software authors are quick to 
throw out the written specification in favour of what actually works.

So, I can see where the idea comes from about deprecating the 301/302 
codes, and using new ones, but that will create more problems than the 
hypothetical (nonexistent) problem it will solve.  In fact, the only 
problem does not lie in interoperability, but in conformance to the 
spec.  Much easier to change the spec in a way that will have no 
operational effect on anyone, than to force all authors to make 
modifications to code for no reason other than to then have it comply to 
the letter of a spec that there already is consensus on (albeit 
non-conformant).

What is a spec after all, but a statement of requirements for 
compliance, with the intent of interoperability - creating a consensus 
of operation.  if the consensus already exists outside the spec, then 
there is already a defacto spec.  Realigning the written spec to the 
defacto one would then seem to be the best path?

Of course if there are significant implementations out there that do 
rely on the written specified behaviour, then it's a different picture, 
but are there any, or is this just a purely hypothetical situation?

Adrien


> Thanks,
>
> Eric
>
>
> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of Henrik Nordstrom
> Sent: Wednesday, March 07, 2007 3:57 PM
> To: Anne van Kesteren
> Cc: ietf-http-wg@w3.org Group
> Subject: Re: Redirection of a POST as a GET
>
> ons 2007-03-07 klockan 23:33 +0100 skrev Anne van Kesteren:
>
>   
>> Following the spec for this is not really feasible. We tried and failed.
>> It would make sense to simply change the specification imo...
>>     
>
> Hmm.. perhaps it would work to rewrite the specs to allow the request to be retried using either the original request method or a GET after a POST resulting in a 301/302 redirect. I.e. not say that there is broken user agents around but to also accept that broken behavior as an alternative action.
>
>   ... Alternatively if the request was a POST request the user agent
>   MAY automatically retry the request as a GET request without requiring
>   user confirmation.
>
>
> As it's been specified since day 1 (before HTTP/1.0 even) that the original request should be retried with the new Request-URI without changing the request method we can not change the specs in such manner that this would not be a correct thing to do. In terms of spec writing the only possible choices is to clearly deprecate the 301/302 responses as "broken beyond repair" in favor of the new 303 & 307 status codes and hope the industry won't trash these as well, or to convince the industry to fix up their act and start following the specs.. and I suspect you won't be happy with either choice..
>
> In terms of spec writing it's quite disappointing that this industry can't accept a clear and well specified "thats the wrong thing to do", and instead continues doing the wrong thing forever countless software generations after the implementation error has been pointed out.. This attitude is quite saddening for the future of the web..
>
> Regards
> Henrik
>
>

Received on Thursday, 8 March 2007 00:35:33 UTC