Subject: Associated resource for PUT

From: "Robert Brewer" <[email-masked]>
Date: Tue, 10 Jul 2012 07:55:09 -0700

Section 5.1 of draft-19 part 2 says, "An HTTP request representation,
when present, is always associated with an anonymous (i.e.,
unidentified) resource." [1]  That makes perfect sense for POST, but for
PUT it makes sense IMO to declare that the representation is associated
with the target resource. Or is the intent that the representation "is
*to become* associated", and is therefore considered anonymous before
the request had been handled?

This is important for at least one reason: I believe this section in the
HTTP spec could be useful to establish a base URI for request entities
according to section 5.1 of the URI spec [2] (which itself might be
underspecified in this regard; it doesn't say much about operations
other than retrieval).

I believe it's not *wrong* for a server to assume the base URI of a
representation PUT to it is that of the target resource. But is that
behavior left to the application? Or should it be standardized? And
should section 5.1 of httpbis say anything about that either way?

Robert Brewer
[email-masked]

[1]
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-5.
1
[2] http://tools.ietf.org/html/rfc3986#section-5.1.3

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Jul 2012 17:00:19 +0200

> the request had been handled?

Yes, that's (IMHO) the intent. The decision is up to the server (after 
all, it could reject the request).

> underspecified in this regard; it doesn't say much about operations

Do you need that functionality until the time the PUT has succeeded?

> ...

Best regards, Julian

---

From: "Robert Brewer" <[email-masked]>
Date: Tue, 10 Jul 2012 10:12:12 -0700

> Do you need that functionality until the time the PUT has succeeded?

The server needs to establish a base URI for any relative URI's in the
request entity. If the entity itself does not include a 'base' attribute
(and many media types do not allow for one at all), it seems natural for
PUT to default to the Request-URI, rather than leave it up to the
application to specify (and then document) for each URI.

Robert Brewer
[email-masked]

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 11 Jul 2012 11:15:30 +1200

On 11.07.2012 05:12, Robert Brewer wrote:
>> > unidentified) resource." [1]  That makes perfect sense for POST, 
>> but
>> for
>> > This is important for at least one reason: I believe this section 
>> in
>> the

The same would appear to be true for POST entity relative URLs as well.
Is there some problem I'm overlooking?

AYJ

---

From: "Robert Brewer" <[email-masked]>
Date: Tue, 10 Jul 2012 16:54:21 -0700

> Is there some problem I'm overlooking?

Yes, the server also needs to establish a base URI for POST entities. It's just not as clear-cut what that base should be for POST; for example, lots of resources have been designed as a collection to which one POSTs an item which then exists at a different URL chosen by the server. So the option of using the Request-URI isn't as obvious as it is for PUT, and it seems more natural to assume the server must decide and describe some application-specific default.

The base URI of a GET response is so obviously the Request-URI, it's a bit surprising that for some reason that hasn't been as obvious for the base URI of a PUT request, given their semantic symmetry. Is there any use case (or even any facility) to have the base URI of a PUT request be some other URI? Can you return 201 Created with a Location of some other URI for PUT? If not, then it's a bit misleading to say "An HTTP request representation is always associated with an anonymous resource."

Robert Brewer
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jul 2012 09:16:21 +0200

> The base URI of a GET response is so obviously the Request-URI, it's a bit surprising that for some reason that hasn't been as obvious for the base URI of a PUT request, given their semantic symmet…

Again, the difference is that the text describes the properties of the 
message. Until the PUT has succeeded we can't say what the associated 
resource is.

Best regards, Julian