Re: #547 clarify PUT on content negotiated resource

On 2014-01-10 20:57, 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.

I think we are in agreement that doing a PUT to a content negotiated 
resource can have different outcomes; it really depends on how the 
negotiation works (separately maintained resources, automatic format 
conversion such as XML/JSON, content-codings such as GZIP).

If nobody has a concrete proposal how the spec can be made clearer than 
I would propose to leave things as they are and close the ticket with no 
change.

Best regards, Julian

Received on Monday, 13 January 2014 13:46:59 UTC