clarify PUT on content negotiated resource

Ted Lemon

Comment (2013-12-19)

The paragraph crossing the page break at the bottom of page 16:

   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.

'''Yes, that is exactly what it means. If an origin server does not want such a thing to occur, then it won't allow PUT on the negotiated URI (only on the specific URIs for each kind of representation).'''

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?

'''The server will tell the client which resources can be PUT and which ones are generated indirectly.'''

Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/547

julian.reschke@gmx.de commented:

Discussed on the mailing list; we prefer to keep the text as is.

julian.reschke@gmx.de changed resolution to wontfix
julian.reschke@gmx.de changed status from new to closed

fielding@gbiv.com changed description from:

Ted Lemon

Comment (2013-12-19)

The paragraph crossing the page break at the bottom of page 16:
   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?

I'm left entirely unclear as to what a 300 response would look like based in the text in 3.4.2 and 6.4.1. Am I missing something?

to:

Ted Lemon

Comment (2013-12-19)

The paragraph crossing the page break at the bottom of page 16:
   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.

'''Yes, that is exactly what it means. If an origin server does not want such a thing to occur, then it won't allow PUT on the negotiated URI (only on the specific URIs for each kind of representation).'''

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?

'''The server will tell the client which resources can be PUT and which ones are generated indirectly.'''

I'm left entirely unclear as to what a 300 response would look like based in the text in 3.4.2 and 6.4.1. Am I missing something?

'''I tried to define a standard response format in April 1995 ([ftp://ftp.ietf.org/ietf-online-proceedings/95apr/area.and.wg.reports/app/http/http-minutes-95apr.txt Danvers IETF HTTP minutes]) and was prevented by the WG because HTTP is supposed to be orthogonal to the media types used as payload. Hence, any format can be used.'''

fielding@gbiv.com commented:

remove bits that are in #548

fielding@gbiv.com changed description from:

Ted Lemon

Comment (2013-12-19)

The paragraph crossing the page break at the bottom of page 16:
   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.

'''Yes, that is exactly what it means. If an origin server does not want such a thing to occur, then it won't allow PUT on the negotiated URI (only on the specific URIs for each kind of representation).'''

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?

'''The server will tell the client which resources can be PUT and which ones are generated indirectly.'''

I'm left entirely unclear as to what a 300 response would look like based in the text in 3.4.2 and 6.4.1. Am I missing something?

'''I tried to define a standard response format in April 1995 ([ftp://ftp.ietf.org/ietf-online-proceedings/95apr/area.and.wg.reports/app/http/http-minutes-95apr.txt Danvers IETF HTTP minutes]) and was prevented by the WG because HTTP is supposed to be orthogonal to the media types used as payload. Hence, any format can be used.'''

to:

Ted Lemon

Comment (2013-12-19)

The paragraph crossing the page break at the bottom of page 16:
   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.

'''Yes, that is exactly what it means. If an origin server does not want such a thing to occur, then it won't allow PUT on the negotiated URI (only on the specific URIs for each kind of representation).'''

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?

'''The server will tell the client which resources can be PUT and which ones are generated indirectly.'''

httpwg / httpbis-issues

clarify PUT on content negotiated resource #547