Re: A new HTTP response code say 209

On Mon, 10 Feb 2014, Ashok Malhotra wrote:

> John Arwe, who is one of the editors on the LDP spec, has proposed a solution
> to the paging return code issue which the WG has endorsed.  Please take a 
> look and comment:
>
> We use 303; if the client doesn't do anything special, they get the second 
> round trip, using base HTTP (2616 and/or bis).  If they add Prefer 
> return=representation, then the client has specifically authorized new 
> behavior, and (if honored) it can know that the response representation is a 
> representation of the resource whose URI is given by the Location header. 
> The Preference-Applied response header would be Required in this case, 
> because 303 already allows a response entity body (description in next 
> "bullet").

From 2616bis:
<<
    Except for responses to a HEAD request, the representation of a 303
    response ought to contain a short hypertext note with a hyperlink to
    the same URI reference provided in the Location header field.
>>

Binding the interpretation of a response to a "Prefer" _request_ header is 
dangerous, even more if you don't mandate a Vary: Prefer so that caches 
won't serve irrelevant information.

> Which gets me back to "why =representation instead of =minimal is 
> important"... because a 'minimal' response to a 303 is no entity body (if you 
> ignore the Should in 303) or an entity body that 2616 and bis describe this 
> way: the entity of the response SHOULD contain a short hypertext note with a 
> hyperlink to the new URI(s).  So a minimal response is not a representation; 
> the excerpt above on modifications provides other similar examples.  We know 
> we want a representation back, saying that seems like the better choice even 
> though we've all been thinking of its LDP usage in terms of how to reduce the 
> size of the representation.

Having a 2XX status code is by far better, but you need to be sure that 
what you design is OK with clients interpreting the 2XX as a 200, ie: that 
you won't reply back with different answers regarding of the client, and 
that it means more "that's the best we can give you, it's partial, but 
look other here to get the whole thing using paging".

> All the best, Ashok
>
> On 1/9/2014 11:08 AM, Julian Reschke wrote:
>> On 2014-01-09 17:04, Henry S. Thompson wrote:
>>> Julian Reschke writes:
>>> 
>>>> On 2014-01-09 12:57, Henry S. Thompson wrote:
>>>>> Right -- to short-circuit this, in the TAG f2f this morning, I offered
>>>>> the following paraphrase for the 2xx proposal:
>>>>>
>>>>>     A 2xx response code signals all and only the short-circuiting of a
>>>>>     303 response, with the content of what a GET to the Location header
>>>>>     of the 303 would have had, and a Content-location header giving what
>>>>>     would have been the Location of the 303.
>>>>> 
>>>>> So no new 'semantics', in the sense that whatever you believe 303
>>>>> means wrt what the relation between what you originally asked for, and
>>>>> what you _eventually_ get, holds for 2xx between what you originally
>>>>> asks for and what you get _immediately_.
>>>>> ...
>>>> 
>>>> I don't believe a new 2xx works for this case.
>>>> 
>>>> Existing clients will interpret an unknown 2xx as 200 (at least that's
>>>> what they should do), so they would interpret the response as being
>>>> for the request-URI, not something else.
>>> 
>>> Why, if there's a Content-location header?  They are supposed to
>>> understand this wrt conneg, right?
>> 
>> Content-Location just indicates that there is a more specific URI, but it 
>> doesn't change the fact that you got a representation of the resource 
>> identified by the request-URI.
>> 
>> (see 
>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#header.content-location>)
>> 
>> Best regards, Julian
>> 
>> 
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 13 February 2014 10:35:48 UTC