- From: Jamie Lokier <jamie@shareable.org>
- Date: Tue, 22 Feb 2005 16:15:21 +0000
- To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Cc: CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>, WebDAV <w3c-dist-auth@w3.org>
Geoffrey M Clemm wrote: > > But you should always try to avoid accessing unknown resources, even > > to query their capabilities: There are implementations where > sending > > OPTIONS to them will be interpreted as a POST or stateful GET :) > > I'm not sure what you mean by "avoid accessing unknown resources". > The only way a client "knows" about a resource is by doing some > discovery method on it such as OPTIONS. No: the way a client knows about a resource is that something asks the client to access the resource. For example, a WebDAV client accesses a resource because the user tells the client to. The user is allowing the client to assume that WebDAV methods are ok to try on the resource. A CalDAV or Atom client accesses a resource that it is told to access. In all cases, the client is told to try certain methods on certain URLs, by the user (or other agent). If the user asks a client to try WebDAV methods on a resource that they don't know it's safe to try WebDAV methods on, then they can cause all sorts of havoc. For example, some URLs will treat any method as form submission, even OPTIONS, so users should never ask a client which uses OPTIONS to access those URLs, because that is dangerous. There is simply no way for the client to "discover" whether a given URL supports the behaviour it's been asked to do, without causing potential harmful side effects. This is why the client has to assume the user gave it a URL with known behaviour in the first place. This is why a client whose job is "add a member to a collection" may _assume_ that it's ok to use POST for this, if POST is specified as having the right behaviour _on that resource_. The only technical reason why a new method would be required in HTTP is if the message semantics were different. For example, POST is allowed to return 201 with Location; PUT is not. Proxies and caches may already understand this. From a purely technical view (not counting "intention") that's what makes POST appropriate. The addition of a new method does not add anything technical, it only expresses "intention". Whereas the methods GET, POST, DELETE, TRACE etc. _do_ have technical differences in terms of what HTTP messages are expected. That's why they exist. -- Jamie
Received on Tuesday, 22 February 2005 16:15:35 UTC