Re: draft-snell-http-prefer

James M Snell wrote:
> 
> 
> On Tue, Oct 16, 2012 at 10:46 PM, Roy T. Fielding <fielding@gbiv.com 
> <mailto: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. 


Actually, the question/concern that started this thread (not my own, but 
channeled from CalConnect) is can a client can figure out why the server 
didn't respond with a representation?  Did the server not understand the 
return-representation preference?  Did it understand it and choose to 
ignore it?  Or did the server not include a representation in the 
response because it didn't change from what the client sent and didn't 
want to waste the bandwidth?

If you don't think that this is a problem, or don't think its worth 
fixing (I might agree here), then please don't hold up the WGLC if 
Preference-Applied is going to be controversial.


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

Received on Wednesday, 17 October 2012 12:15:36 UTC