W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

RE: Interop issue: how can clients force authentication?

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>
Message-ID: <00d801c25eb8$97ee85a0$b701a8c0@xythoslap>

> 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
> it's
> something that needs to be addressed.  if there is something already
> 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

There may be other methods which an unauthenticated user can receive a
success response, but which would work even better if the user were

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.

Received on Tuesday, 17 September 2002 22:12:18 UTC

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