W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

Re: draft-reschke-http-addmember-00

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>
Message-ID: <20050222161520.GA22555@mail.shareable.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:39 GMT