- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 16 Oct 2012 22:56:45 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Ken Murchison <murch@andrew.cmu.edu>, ietf-http-wg@w3.org
- Message-ID: <CABP7Rbcng8Zk+GiB7hrNPztb7+k0vHO+6b1GH9xXNtekEy0LCQ@mail.gmail.com>
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 > > >
Received on Wednesday, 17 October 2012 05:57:33 UTC