Re: draft-snell-http-prefer

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

> On Oct 13, 2012, at 11:40 AM, Mark Nottingham wrote:
>
> > Actually, I don't think you need Preference-Applied *or* Vary to
> indicate this; both are barking up the wrong tree.
> >
> > Rather, you need something with the specific semantics "the
> representation of the resource is byte-equivalent to the PUT request you
> just made" for *that* case.
> >
> > This could be a new status code, or it could be a header on the
> response. It could even be a "duplicate" link relation (RFC6249), pointing
> to a URI for "the request you just made"; e.g.
>
> There is nothing to guarantee that the PUT payload received by
> the origin server is byte-equivalent to the payload sent by the
> user agent, so it does little good for the origin to say that
> it received what "you" sent and didn't change it.
>
>
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.


> A more interoperable protocol would be for the request message to
> contain some sort of end-to-end hash or signature of the request
> representation, and the server to respond with the same hash
> applied to the new representation.
>
>
Agreed, but again, that's an orthogonal problem to the one addressed by the
Prefer header.

- James


> ....Roy
>
>
>