- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 29 Oct 2005 18:03:21 +0200
- 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