Re: NEW ISSUE: Clarify whether request must be processed before responding with redirection codes

On 04/07/2013 10:42 AM, Julian Reschke wrote:
> I can understand why people are uneasy about too much wiggle room.
>
> My understanding (coming from WebDAV) for a PUT and a 301/302/307 
> response always was: "the server understood what you want to do, but 
> asks you to apply the request to the redirect target instead". That 
> is, the actual PUT operation was not executed.
>
> Right? Wrong?
>
> For 303 the situation obviously is more complicated though.
>
> Best regards, Julian
Hi Julian,

     That's been my understanding as well.

     Honestly, I think the explanation provided by the RESTful Web 
Services book was the best: http://stackoverflow.com/a/13636991/14731

     It explains HTTP 307 as follows:

For GET requests, where the only thing being requested is that the 
server send a representation, this status code is identical to 303 ("See 
Other"). A typical case where 307 is a good response to a GET is when 
the server wants to send a client to a mirror site. But for*POST, PUT, 
and DELETE requests*, where the server is expected to take some action 
in response to the request, this status code is significantly different 
from 303.

A 303 in response to a*POST, PUT, or DELETE*means that the operation has 
succeeded but that the response entity-body is not being sent along with 
this request. If the client wants the response entity-body, it needs to 
make a GET request to another URI. A 307 in response to a POST, PUT, or 
DELETE means that the server has not even tried to perform the 
operation. The client needs to resubmit the entire request to the URI in 
the|Location|header.

     This explanation removes all ambiguity from both HTTP 303 and HTTP 
307 for all methods. I wish the specification was equally clear.

Gili