Subject: #547 clarify PUT on content negotiated resource

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Jan 2014 19:12:10 +0100

<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. This text makes sense for different content encodings like JSON and XML, where the server might be able to generate one from the other, but it's giving me a headache thinking about it in terms of natural language. Am I missing the point here? If so, could this be clarified, or did I just not drink enough coffee this morning?

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.

Ted replied to that with:

 > Hm, so then why not say so more explicitly?

Not sure about that. Maybe there are use cases I'm not aware of.

What do other think? Should we rephrase this?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Jan 2014 10:40:33 -0800

> Not sure about that. Maybe there are use cases I'm not aware of.

Sometimes negotiation is just formats, in which case it's not a bad
idea exactly.  It is, after all, just representations we're talking
about.  For instance, I've seen numerous cases where PUT of XML is
perfectly able to cause the JSON representation to update correctly.
For natural language, I'm sure that automatic translation is possible
to a certain extent too, if perhaps inadvisable...

I'm not sure what to say here.  If it's clear that the URI for a
negotiated resource is effectively a label for multiple things that
are logically the one thing, and the other URIs that might appear in
Content-Location are identifiers for the individual facets of that
uber-thing, then that should be enough to allow people to reach their
own conclusions.

Maybe:

  A PUT to a negotiated resource is expected to set the state of the
resource for all alternative representations.  This is easily possible
if the translation between representations is purely mechanical,
though less mechanical translations, such as natural language
translation might cause this sort of operation to be difficult and
therefore inadvisable.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 10 Jan 2014 20:57:21 +0100

* Julian Reschke wrote:
>> 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.

>that the authoring client then can use the specific URI to update just 

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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 11 Jan 2014 16:53:29 +1300

> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jan 2014 14:46:29 +0100

> 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