Re: draft-snell-http-prefer

You know how every once in a while you can read something over and over and
about the fifth or sixth time you read through it you suddenly notice
something that's been there for a while and think, "Dammit! where did that
come from?!" ... Sigh, I had completely overlooked the fact that this level
of detail was added to p2 for content-location. Turns out it's quite
helpful to RTFM after all.

On Tue, Oct 16, 2012 at 11:10 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Oct 16, 2012, at 10:56 PM, James M Snell wrote:
> > Noted and agreed.. but that's not quite what's going on with the Prefer
> header here. The return-representation preference merely indicates to the
> server that the UA would like the server to return a representation of the
> resource within the response vs. a representation of the request status.
> What's missing is some indicator within the response as to which the server
> is actually returning. There is some ambiguity that needs to be resolved.
> All the Preference-Applied header does is provide an explicit indicator
> that the server did, in fact, do as the UA asked and returned the resource
> representation in the response... an indicator that is only necessary if
> it's not obvious by the content type of the payload or by direct
> examination of the payload.
>
> In that case, there is no need for it.  A Content-Location field with
> the same value as the effective request URI means that the preference
> has been applied.  See
>
>
> http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/21/p2-semantics.html#header.content-location
>
> ....Roy
>
>