Re: #547 clarify PUT on content negotiated resource

On 11/01/2014 8:57 a.m., Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/547>
>>
>> During IESG revied, Ted Lemon came up with this question:
>>
>>> The paragraph crossing the page break at the bottom of page 16 (ed: <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#rfc.section.3.1.4.2.p.8>):
>>>
>>>    For example, if a client makes a PUT request on a negotiated resource
>>>    and the origin server accepts that PUT (without redirection), then
>>>    the new state of that resource is expected to be consistent with the
>>>    one representation supplied in that PUT; the Content-Location cannot
>>>    be used as a form of reverse content selection identifier to update
>>>    only one of the negotiated representations.  If the user agent had
>>>    wanted the latter semantics, it would have applied the PUT directly
>>>    to the Content-Location URI.
>>>
>>> It's good that there's an example here, but this creates more questions
>>> than it answers: if I do a PUT to a particular URI, for which there are
>>> currently multiple representations of the document in different languages,
>>> based on a GET that had a specific language representation, is the 
>>> semantics being specified here that the other language representations 
>>> go away? That's kind of what it sounds like.
> 
>> To which I replied:
>>
>> Mainly it means that it's a bad idea to do it, unless the other language 
>> versions are automatically updated somehow. The main point is that if 
>> you want a single variant of a content-negotiated resource to be 
>> authorable, you better serve it with a specific Content-Location, so 
>> that the authoring client then can use the specific URI to update just 
>> that variant.
> 
> It seems plausible to me that a PUT to a negotiated resource might turn
> it into a non-negotiated resource. Using PUT to change how the resource
> is negotiated (say, link a new variant to it so it can be considered in
> future negotiations) does not seem that far off either. I do not really
> see the difficulty in understanding the text above.
> 

Yes. Consider the case of a proxy caching PUT bodies. The PUT would need
to send Vary, ETag, Key and any other headers necessary to replicate the
GET equivalent response. Otherwise the variant nature of the URI is
wiped away.

Amos

Received on Saturday, 11 January 2014 03:54:04 UTC