W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: draft-snell-http-prefer

From: James M Snell <jasnell@gmail.com>
Date: Tue, 16 Oct 2012 23:31:50 -0700
Message-ID: <CABP7Rbc=2B4_zkfc4Oa7BbVVyUG9YCNhR4VwXETcLPRx3AuFgg@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, Ken Murchison <murch@andrew.cmu.edu>, ietf-http-wg@w3.org
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
Received on Wednesday, 17 October 2012 06:32:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC