[Ietf-caldav] Re: draft-reschke-http-addmember-00
jamie at shareable.org
Tue Feb 22 12:38:39 PST 2005
Julian Reschke wrote:
> >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.
It's not assumption about the user's knowledge. It's an unavoidable
assumption the client must make, that it's invoked on an appropriate
kind of resource.
If a user does that, and the document came from a CGI script of the
low quality I've seen, there's a good chance the LOCK and PUT
operations will invoke unwanted side effects - or just overwrite the
Of course if it's a better written web component then it won't have
those problems. And something that generates and returns Office files
probably is better written in that respect.
> >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.
How often do you look at Joe Random form results and then select "edit
this page"? If you do that with random forms from the web, I think
you'll be surprised at how many don't respond sensibly to OPTIONS,
LOCK and PUT.
The slackness doesn't cause problems because people don't do that.
(And in the cases where they do, because it's appropriate for a resource,
that resource implements a sensible response).
Similarly, how often do you expect CalDAV clients to be pointed at
If it's done, the behaviour of the server is unpredictable. ADDMEMBER
doesn't fix that.
(Although it would shift the likelihood towards a simple failure
rather than an unwanted side effect. Is it worth creating a new
method just to change the likelihood of a behaviour when a CalDAV
client is pointed at the wrong URL?)
More information about the Ietf-caldav