Re: Prefer Draft Feedback

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 19:07:56 UTC