Re: Prefer Draft Feedback

Ok, a new draft has been published.

After discussing caching issues with Mark in detail, I've made a
number of important changes to the draft... specifically, it is
important to point out that Prefer was always intended to be a
behavior-negotiation mechanism, not content-negotiation. While the
application of a behavioral preference could potentially impact the
construction of a response, implementations should avoid utilizing
preferences in a way that causes a variance in the caching of a
response. For that reason, I added a new short section detailing cache
considerations and removed the detail preference. Basically, if you're
using Prefer for content-negotiation, you're likely doing it wrong.

Also, per the conversation around return-status, return-representation
and Preference-Applied, I have removed the return-status and pulled
Preference-Applied back out. The logic is straightforward... if the
response cannot be unambiguously determined to be a representation
response based on a comparison of the effective request URI,
content-location and, in some cases, the Location header (e.g. for 201
Created responses), then the client must inspect the content to
determine the nature of the response regardless of which return-*
preference was used. Return-status, then, provides no additional value
and the need for Preference-Applied disappears. If, at some point in
the future the need for Preference-Applied arises, it can be looked at

- James

On Wed, Dec 7, 2011 at 3:24 PM, Mark Nottingham <> wrote:
> On 07/12/2011, at 10:46 PM, Moore, Jonathan (CIM) wrote:
>> On Wednesday, December 07, 2011 1:36 AM, Mark Nottingham wrote:
>>>> - brought Preference-Applied back
>>> This needs to be discussed. I'm very uneasy about turning this into Yet Another HTTP Negotiation Mechanism.
>> Can you explain your unease? It seems like all the pre-existing server-side negotiation mechanisms (Accept, Accept-Language, etc.) all basically have an "express your desire but check the response anyway" semantic. For example, servers are explicitly not required to send a 406 if they can't honor an Accept header. However, there are (optional) protocol-level means that servers can use to provide more context to clients--Content-Language being a good example. Therefore, in some sense, they are all client "preferences" one way or another. Perhaps we're just defining "the last negotiation mechanism you'll ever need"?
>> Or are you suggesting server-side negotiation was a Bad Idea, and hence we shouldn't be pursuing other means for it?
> More the latter; experience has shown that conneg is of limited value, and can be abused + cause more problems than it's worth. There's a relevant HTTPbis ticket, don't remember offhand which one.
> --
> Mark Nottingham

Received on Thursday, 8 December 2011 17:57:25 UTC