Re: Prefer Draft Feedback

Ah, I see where Mark Nottingham referred to these rules:

> 3.  If the response has a Content-Location header field, and that URI
> is the same as the effective request URI, the response payload is
> a representation of the target resource.

> 4.  If the response has a Content-Location header field, and that URI
> is not the same as the effective request URI, then the response
> asserts that its payload is a representation of the resource
> identified by the Content-Location URI.  However, such an
> assertion cannot be trusted unless it can be verified by other
> means (not defined by HTTP).

I am thinking of the case where I do a POST to one resource. In case (3),
then it's clear the server is basically doing "return-representation". In
case (4), however, it's returning a representation that is also available
at the Content-Location. A client cannot distinguish whether this is
"return-representation" or "return-status" in this case. For example, a
POST might return either one with a Content-Location that was different
from the effective request URI.

Clearly a client sending Prefer must be prepared to examine a response
as-is, as a compliant server may simply ignore Prefer (or may not even
implement it at all). So I can see the argument that Preference-Applied
isn't necessary. However, it clearly offers a leg up to a client, if only
to advertise that the server (or an intermediary) supports Prefer.
However, it actually distinguishes things in the above case. Perhaps
Preference-Applied should be a MAY?

Jon

........
Jon Moore
Comcast Interactive Media






On 12/6/11 2:15 PM, "James Snell" <jasnell@gmail.com> wrote:

>Previous versions of the draft included a Preference-Applied response
>header that would list out the ones applied, it was removed based on
>some other push back I had received. I could easily add that back in,
>however, if that provides the necessary signaling mechanism.
>
>On Tue, Dec 6, 2011 at 11:07 AM, Moore, Jonathan (CIM)
><Jonathan_Moore@comcast.com> wrote:
>> Even if a client sends "Prefer: return-representation" and gets a
>>response
>> with a Content-Location in return, there's no guarantee this isn't a
>> status response. Perhaps the server doesn't implement Prefer, and
>>returned
>> a status response with a Content-Location that could be polled for
>>ongoing
>> status updates--this is a commonly-described mechanism for long-running
>> jobs, and fits with the RFC2616 definition of Content-Location.
>>
>> In other words, I think the SHOULD NOT convention here doesn't actually
>> buy you anything. Perhaps a server that understands Prefer should have a
>> response header indicating which preferences were honored? Such as:
>>
>> HTTP/1.1 202 Accepted
>> Date: Tue, 06 Dec 2011 19:04:51 GMT
>> Preferences-Honored: return-status, return-accepted
>> ...
>>
>> Jon
>> ........
>> Jon Moore
>> Comcast Interactive Media
>>
>>
>>
>>
>>
>>
>> On 12/6/11 1:48 PM, "James Snell" <jasnell@gmail.com> wrote:
>>
>>>Yeah, this is an item that's still somewhat up in the air. The main
>>>challenge is that when sending "Prefer: return-status" or "Prefer:
>>>return-representation" (yes, Julian, if you're reading, I went ahead
>>>and renamed it.. you were right it did make more sense that way)...
>>>it's generally impossible to reliably determine which type of response
>>>you're getting back. There's absolutely nothing in the response I can
>>>key off of to determine whether the entity is a representation of the
>>>resource or a representation of the request status. The idea here was
>>>to use the presence of the Content-Location header as that key. If
>>>Content-Location is in the response, then I would assume that it's a
>>>representation of the resource, otherwise, I have to assume it's a
>>>status. This is definitely far from perfect, obviously, but it aligns
>>>with the behavior of apis based on the Atom protocol and a few others
>>>I have seen. However, ideally, there would be some explicit signaling
>>>mechanism that I could use without having to abuse Content-Location in
>>>this way.
>>>
>>>On Tue, Dec 6, 2011 at 8:38 AM, Moore, Jonathan (CIM)
>>><Jonathan_Moore@comcast.com> wrote:
>>>> On 12/5/11 7:32 PM, "James Snell" <jasnell@gmail.com> wrote:
>>>>> http://tools.ietf.org/html/draft-snell-http-prefer-05
>>>> Hi James,
>>>>
>>>> I had a question about the following recommendation:
>>>>
>>>>> When honoring the "return-status" preference, the server SHOULD NOT
>>>>> include a Content-Location header field in the response.
>>>>
>>>>
>>>> What if the status has its own URI, to be used for polling the status
>>>>of a
>>>> long-running job, for example? Wouldn't it be appropriate to provide
>>>>this
>>>> URI in a Content-Location header on the response?
>>>>
>>>> Jon
>>>>
>>>> ........
>>>> Jon Moore
>>>> Comcast Interactive Media
>>>>
>>>>
>>

Received on Tuesday, 6 December 2011 20:57:21 UTC