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

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

From: Justin Chapweske <justin@chapweske.com>
Date: Tue, 22 Feb 2005 14:56:47 -0600
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Jamie Lokier <jamie@shareable.org>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDAV <w3c-dist-auth@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1109105807.10284.229.camel@bog>

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

Amen.  Allowing poor implementations to dictate the evolution of HTTP
can only lead to further inconsistencies and ambiguities which lead to
more bugs and security holes.

I'm still rather grumpy about how many dozens of hours my developers
wasted getting iTunes to work through our proxy due to the liberties
that Icecast has taken with HTTP.  I was appalled when I learned they
return "ICY 200 OK" for a valid HTTP request.

I think the PATCH proposal is good as it fills in a huge hole, but I am
much less excited about ADDMEMBER because now we have a whole new verb
that we have to understand the security ramifications and caching
semantics for.

Justin Chapweske <justin@chapweske.com>
Received on Tuesday, 22 February 2005 21:00:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:26 UTC