RE: Interop issue: how can clients force authentication?

> 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