W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 18] no record of consensus for force-authenticate

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 29 Oct 2005 18:03:21 +0200
Message-ID: <43639D49.2050806@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, webdav <w3c-dist-auth@w3.org>

Lisa Dusseault wrote:
> So if you wanted to browse a collection, and see all the 
> non-publicly-readable resources alongside the publicly readable 
> resources, you'd try to LOCK that collection? That's actually a state 
> change if it succeeds, may have significant side effects.
> Expect is a reasonable solution in theory. However, it's harder to 
> implement, which is why a simpler mechanism might see more implementation.
> - Expect requires the server to maintain more state, for longer, while 
> the client gets back with the rest of the request (when a success 
> response happens). It's unique in splitting the request and response up.

I'm not sure I understand this. Using Expect: 100-continue only means 
that the server has a chance to reject the request before the body is 
sent. What am I missing here?

> - Expect could be subject to trivial DOS attacks.

Please explain.

> - As Julian pointed out, Java servlet engines don't allow this kind of 
> flexibility, while a servlet could implement Force-Authenticate (or 
> something similar) without requiring changes in the servlet engine. 
> There are probably similar restrictions in other cases -- maybe IIS' 
> API, Apache's module API, I don't know.

To me that means that the servlet engines should be enhanced, just like 
in the bug description I posted.

Statements about other servers are really just hand-waving, unless you 
have solid information.

> ...

Anyway: this is not a WebDAV problem. Compile a problem statement, and 
try to get people working on a separate specification. Possibly on the 
http WG mailing list.

Best regards, Julian
Received on Saturday, 29 October 2005 16:04:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC