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

On 5/07/2013 2:00 a.m., cowwoc wrote:
> On 04/07/2013 4:22 AM, Mark Nottingham wrote:
>> Hi Gili, 
>> <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#status.3xx> 
>> starts:
>>> The 3xx (Redirection) class of status code indicates that further 
>>> action needs to be taken by the user agent in order to fulfill the 
>>> request.
>> So, we already say that the request isn't fulfilled when you see a 3xx.
> Hi Mark,
>
>     That isn't strictly true. The language of the new specification is 
> a little loosy goosy.
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4 says 
> the client "SHOULD" respond to HTTP 303 by issuing HTTP GET on the 
> returned URL.
> https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#status.303 
> says the client "ought to" respond by doing the same.
>
>     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.

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.


>
>> The server, by issuing a 303, is making an assertion that there's 
>> something useful at the other end; if there isn't, it's not telling 
>> the truth, and the client will have to deal with that.
>>
>> Making an explicit binding between receiving the entire request and 
>> the state of a completely separate resource seems like unnecessary 
>> coupling to me; how would doing so help interop?
>
>     I guess I agree with you. I just don't like see any sort of 
> ambiguity in specifications I read.
>
>     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.

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

Amos

Received on Thursday, 4 July 2013 15:28:26 UTC