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

On 04/07/2013 11:27 AM, Amos Jeffries wrote:
> First of all, "ought to" isn't as well defined as "should". Secondly, 
> both imply to me that issuing a subsequent HTTP GET is an optional 
> operation. If it's an optional operation, then I am interpreting it as 
> meaning that the original request may or may not be fulfilled because 
> from the client's point of view, its job is finished (I am not 
> required to issue an HTTP GET to hold up my end of the contract).
>
> Define "fulfilled".
>
> The specification uses it to mean the server has completely received, 
> operated on and finished with the request. What has not happened is 
> delivery of any response payload. It is for origin server use when the 
> payload is not particularly important and clients may optionally 
> ignore it, some can benefit greatly from not receiving it. Clients 
> which believe otherwise will followup with the GET mentioned - but 
> *that* part is optional.

     So now you're telling me that a server must fulfill the request 
before HTTP 303? Or did I misunderstand you?

>
> The other redirection codes are unsafe to use with some methods as the 
> existing middleware implementations use them freely and there is no 
> indication that the origin server has even received the request, let 
> alone processed it fully.
>
> https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#introduction 
>
> paragraph 3 "an HTTP request can be considered in isolation rather 
> than being associated with a specific type of client or a 
> predetermined sequence of application steps"
>
> Thusly by replacing "SHOULD" with "ought to" the protocol is now 
> placing no binding requirements on clients following any multi-stage 
> request/reply sequence.

     Isn't "MAY" more appropriate in this situation? "In order to 
satisfy the original request, a user agent MAY perform a retrieval 
request using the Location URI [...] and present the eventual result as 
an answer to the original request"

>>     I'd like the specification to explicitly state: "The request is 
>> only guaranteed to have been processed after the client issues HTTP 
>> GET on a returned URL
>
> Define "processed". It *has* been processed as far as the server 
> POST/PUT/DELETE/WHATEVER processing is willing or able to go. That is 
> a guarantee. With a lot more certainty than any of the other redirect 
> codes offer.

     In my opinion, that part is vague. My understanding of the current 
specification is that the operation is guaranteed to get processed 
before I issue HTTP GET on the final URL. I am asking for (but don't 
see) a guarantee that the POST/PUT/DELETE/WHATEVER operation must be 
fulfilled before returning HTTP 303. If you are implying that the 
specification meant to guarantee this, I would ask you to be more 
explicit about it.

>> and is no longer redirected using HTTP 3xx". Obviously, you'd have to 
>> clean up the language but you get my point. That way there is no 
>> longer any ambiguity as to the client's responsibility (HTTP 303 will 
>> imply "MUST" instead of "SHOULD" if the client wishes to complete the 
>> original request) and you get to keep the flexibility you wanted on 
>> the server end.
>
> There is no ambiguity about the clients _responsibility_. It is 100% 
> responsible for deciding to (or not) fetch the indicated payload.
> What is ambiguous is whether any given client will make said choice. 
> It is up to the implementer to decide that.

     You're right, I misspoke. There is no ambiguity about the client's 
responsibility. There is ambiguity about the *server's* responsibility 
as to whether the operation must take place before returning HTTP 303 or 
whether it defers the operation until the client invokes HTTP GET on the 
Location URI.

Gili

Received on Thursday, 4 July 2013 16:48:13 UTC