- From: Jamie Lokier <jamie@shareable.org>
- Date: Tue, 15 Feb 2005 19:51:06 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Cyrus Daboo <daboo@isamet.com>, HTTP Working Group <ietf-http-wg@w3.org>
Julian Reschke wrote: > Jamie Lokier wrote: > >These clients creating entities under different URIs -- what URI do > >they use in the request? > > > >They must use a URI which identifies what the server should do with > >the request, rather than identifying the URI of the new entity. > > > >(For example, a real implementation might use the URI identifying a > >particular mail folder or calendar in the request, and the request is > >to create a new message "inside" the identified folder or calendar, > >with a server-selected URI). > > > >When the request URI identifies an object which has internal logic and > >processes the request body -- isn't this quite well suited to POST? > > > >And, to get the URI of the created entity -- isn't this quite well > >suited to a 303 response from POST? > > > >(For example, POST to a mail folder or calender URI could reasonably > >create a new message "inside" the identified folder or calendar, if > >the request entity has an appropriate MIME type). > > All of this is correct. However, how is a generic client going to know > that sending a POST request to that container will indeed have the > desired semantics of "storing the entity at a server-defined URI and > returning the URI"? Can you give an example of such a generic client being used? I'm finding it hard to imagine a scenario where a generic client would be asked to do this, where the caller of the generic client wouldn't already know what to expect. > If a protocol would use POST for this, it needs an out-of-band > communication to ensure that the server indeed will process the POST as > desired (for instance, the Atom publishing protocol does this through > advertising serviceURLs). The proposed new method has fixed semantics > and thus doesn't require out-of-band information. It does require out-of-band information if the proposal for using OPTIONS is needed: OPTIONS is the out-of-band information. Otherwise the client is back to making assumptions about the server's behaviour. -- Jamie
Received on Tuesday, 15 February 2005 19:51:11 UTC