Re: Interop issue: how can clients force authentication?

the fact that this may already work with some implementations is a plus.  on
the other hand it would pretty much be a hack.  when i see something like
If: ("a" Not "a"), client authentication is not exactly the first thing that
comes to mind.  a new header would make this idea very explicit and probably
less prone to implementation errors.  however, i'd like to see this feature
implemented in some shape or form, so if there's consensus on the If header,
it'd be fine with me.

-ilya


"Clemm, Geoff" wrote:

> I think this thread is diverging a bit from the key aspects
> of the proposal to use the If header instead of inventing a
> new header.
>
> In particular, suppose a client used the new header.  This request
> will fail against every existing DAV server.  Suppose instead the client
> used the If header, using the:
>   If ("a" Not "a")
> form.  This request will do what is desired against every existing
> DAV server that:
> - supports the If header (correctly) and that
> - does any authentication checks before the If checks.
>
> For all new DAV servers, they can equally well either implement a new
> header, or could implement the If header (which they should do anyway),
> and make sure they do any authentication checks before the If check
> (which they should do anyway).
>
> I believe it is clear that it provides increased interoperability
> to use the If header approach, since this provides at least some
> interoperability with existing servers, while the new header (or new
> anything) approach does not.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Wednesday, September 18, 2002 12:29 PM
> To: 'Stefan Eissing'
> Cc: Webdav WG
> Subject: RE: Interop issue: how can clients force authentication?
>
> > First, I bet that 100% of all non-broken, existing servers do
> > authentication checks before looking at the request resource and
> > its properities like locks. It's the sensible thing to do, as a
> > user might not even have read permission on the resource. So
> > one probably should prevent him/her from finding out about the lock
> > status of the resource.
>
> No, and why should they?  There's nothing in RFC2518 that requires
> servers to support locks only for authenticated users.  If a resource is
> publicly writable, there may be nothing to prevent unauthenticated users
> from taking out locks and using lock tokens.  Recall that the If header
> can also be used with ETags, which are not at all associated with how a
> user is authenticated.
>
> Also, recall that in order to "do authentication checks", the server
> must respond to the client with a 401 with the WWW-Authenticate header,
> then the client must make another request.
>
> Of course if the client sent its authentication information on the first
> request, the server is likely to check it.  However, the client can't
> even send its authentication information if it doesn't yet know whether
> the server supports digest or basic, or what realm, nonce, etc.  That's
> why Ilya wants to be able to ask the server to reply with a
> WWW-Authenticate header.
>
> Lisa

Received on Thursday, 19 September 2002 17:25:41 UTC