Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00

[Julian Reschke <[e-mail]>]

Jamie Lokier wrote:
> 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.

You're making assumptions about the knowledge a user has that IMHO are 
simply questionable. For instance, a user my use IE to follow a 
hyperlink to an Office document, and Office will (under some 
circumstances) LOCK the document, and later PUT and UNLOCK it. At least 
95% of the users will not be aware of what was going on technically.

> 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.

If that causes havoc, that's because the server is broken (be it 
misconfigured or just buggy).

> 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.

See above.

> 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.

Jamie, lots of clients are doing this today. I'm not aware of any 
"havoc" causing this.

> 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_.

So what do I do if a have a resource that accepts HTML form posts, SOAP 
requests and ADDMEMBER-like semantics on the same URL?

> The only technical reason why a new method would be required in HTTP
> is if the message semantics were different.  For example, POST is

Of course. That's why they are defined to be different from POST.

> ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]