- From: Lisa Dusseault <lisa@xythos.com>
- Date: Tue, 17 Sep 2002 19:10:42 -0700
- To: "'Ilya Kirnos'" <ilya.kirnos@oracle.com>, "'Julian Reschke'" <julian.reschke@gmx.de>
- Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
> this answer is currently not sufficient, for example in the case of a > large PUT. whether it's an interop or a performance problem, i believe > it's > something that needs to be addressed. if there is something already in > the spec > that solves the problem, i would be happy to use it. There are other problems. In a collection, an unauthenticated user may have sufficient privilege to see some (publicly visible) resources, but not others. A PROPFIND to this collection would therefore not reveal all child resources. Also, a PROPFIND might return only some publicly visible properties, not others which might be considered slightly "sensitive" (like quota?) and not revealed to unauthenticated users. A PUT to a new resource may be accepted even from anonymous users, but if the user is unauthenticated, the new resource cannot be initialized in the same way. For example, the owner may not set to the user who created it, or the new resource may go to the collection owner for approval. There may be other methods which an unauthenticated user can receive a success response, but which would work even better if the user were authenticated. Can anybody come up with other clever ways for the client to try to authenticate? E.g. is it possible for a client to send a reasonable Digest authentication header with its first request (probably a PROPFIND, but whatever method happens to be first), and if the information therein (e.g. realm) is bad, the server responds with the WWW-Authenticate header with the correct prompting? That doesn't quite solve Ilya's performance problem, but perhaps the HTTP 1.1. Continue mechanism would solve that specific issue. Lisa
Received on Tuesday, 17 September 2002 22:12:18 UTC