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

On 5/07/2013 4:47 a.m., cowwoc wrote:
> 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?

Any request needs to be fulfilled before the reponse is sent. At least 
sufficiently to provide the guarantees the status code requires. The 
difference with 3xx is that there is a *second* request which has not 
necessarily been fulfilled yet. The followup to 303 may *never* reach 
the server or any system associated with it simply because the GET 
response is cacheable - some ISP over in the back of beyond may have 
cached it and be delivering the response to the client you just sent 303 to.

There are other protocol features for scoping the responsibilities and 
determinism better. But it is the implementations responsibility to use 
those other features to tune the open possibilities of 303 semantics.

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

Well it was  SHOULD, and there were reasons for that (though I'm not 
aware which). The WG practice has been to replace overly restrictive 
SHOULD with a phrase that lacks the normative strictness while still 
conveying some importance for the instruction - "ought to".

>
>>>     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 Friday, 5 July 2013 07:41:49 UTC