Re: Prefer Draft Feedback

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 19:15:38 UTC