- From: Robert Brewer <fumanchu@aminus.org>
- Date: Tue, 10 Jul 2012 16:54:21 -0700
- To: "Amos Jeffries" <squid3@treenet.co.nz>, <ietf-http-wg@w3.org>
Amos Jeffries wrote: > On 11.07.2012 05:12, Robert Brewer wrote: > > Julian Reschke wrote: > >> On 2012-07-10 16:55, Robert Brewer wrote: > >> > 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? > >> > >> Yes, that's (IMHO) the intent. The decision is up to the server > >> (after > >> all, it could reject the request). > >> > >> > 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). > >> > >> 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. > > > > The same would appear to be true for POST entity relative URLs as well. > 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 fumanchu@aminus.org
Received on Tuesday, 10 July 2012 23:54:47 UTC