W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 18] no record of consensus for force-authenticate

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sat, 29 Oct 2005 11:07:54 -0400
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Lisa Dusseault <lisa@osafoundation.org>, webdav <w3c-dist-auth@w3.org>, w3c-dist-auth-request@w3.org
Message-ID: <OF2C9B1E83.F380F132-ON852570A9.0052E6BF-852570A9.00532119@us.ibm.com>
I agree with Julian that if there is a general HTTP problem that needs to
be solved, then it should be handled in a separate draft in a general HTTP
working group, not a RFC-2518 revision.  We have plenty of RFC-2518 
that need to be addressed.


Julian wrote on 10/29/2005 04:22:57 AM:

> Lisa Dusseault wrote:
> > No it's not just for LOCK and PUT -- a client doing read-only requests 

> > (like PROPFIND) might see different results depending on whether or 
> > they're authenticated. Some of the resources in a collection might be 
> > publicly readable (so the PROPFIND can succeed if anonymous) but 
> > be hidden to unauthenticated users.
> But you could still use LOCK to enforce authentication, right?
> > More generally, it's not actually a WebDAV problem alone. If a client 
> > does a GET to a dynamically generated page, they could easily see 
> > different results based on whether they're authenticated or not. Since 

> > browsers today often cache authentication information, this means that 

> > the browser could inform the server that they'd like the challenge to 
> > save the user the step of first going to the site, seeing the 
> > page version, then choosing to login. Of course some sites use cookies 

> > for this but cookies are sometimes disabled, expired, etc.
> In which case I would recommend to
> - update Jim's description of the problem accordingly and
> - do this in a separate draft, optimally discussed on the HTTP WG's 
> mailing list.
> Best regards, Julian
Received on Saturday, 29 October 2005 15:08:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC