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

From: [email-masked]
Date: Sat, 15 Oct 2005 11:54:42 -0700

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 15 Oct 2005 21:35:22 +0200

Proposed resolution for 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18>:

History:

The "force-authenticate" request header was initially proposed by Ilya 
Kirnos, and we had a discussion about this back three years ago 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/thread.html#291>). 
As far as I can tell, the consensus back then was not to define a new 
header, but to make use of an "If" request header that was known to 
alway evaluate to false instead.

In January 2003, the WG had an interim meeting hosted by Apple, during 
which the problem was discussed again. Unfortunately, there doesn't seem 
to be any public record of what was discussed on the second day (which 
AFAIR was the day we discussed this topic). (Minutes for day one in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0075.html>).

The "Force-Authentication" header was then introduced in draft 03 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-03.txt>), 
but I can't find any record of a consensus reached on the mailing list.

I therefore propose to remove the header from the spec, encouraging 
those who feel that this feature is needed to solve a real-world problem 
to restart the discussion on the mailing list (containing a precise 
problem statement, and an analysis why the current spec isn't sufficient 
in this regard).

In addition to removing section 9.4, further changes would be:

Section 17., para. 11:
OLD:

    A resource can explicitly advertise its support for the revisions to
    RFC2518 made in this document.  In particular, this allows clients to
    use the Force-Authentication header on requests.  Class 1 must be
    supported as well.  Class 2 MAY be supported.

NEW:

    A resource can explicitly advertise its support for the revisions to
    RFC2518 made in this document.  Class 1 must be supported as well.
    Class 2 MAY be supported.

Section 17., para. 13:
OLD:

    o  the Force-Authentication header.

    o  Any behavior that it supports, in the manner specified in this
       document, rather than in the manner specified in RFC2518, for all
       client requests.  A server MAY use an older behavior for specific
       clients that are discovered to have interoperability problems with
       the requirements of this specification, but MUST NOT use an older
       behavior indiscriminately.

NEW:

    o  Any behavior that it supports, in the manner specified in this
       document, rather than in the manner specified in RFC2518, for all
       client requests.  A server MAY use an older behavior for specific
       clients that are discovered to have interoperability problems with
       the requirements of this specification, but MUST NOT use an older
       behavior indiscriminately.

Section 21., para. 8:
OLD:

    Valuable contributions to RFC2518 bis came from some already named.
    New contributors must also be gratefully acknowledged.  Julian
    Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out
    specific text on the list or in meetings.  Ilya Kirnos supplied text
    for Force-Authentication header.  Joe Hildebrand contributed as co-
    chair.

NEW:

    Valuable contributions to RFC2518 bis came from some already named.
    New contributors must also be gratefully acknowledged.  Julian
    Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out
    specific text on the list or in meetings.  Joe Hildebrand contributed
    as co-chair.

Best regards, Julian
--- draft-ietf-webdav-rfc2518bis-07.xml	2005-10-15 19:19:46.000000000 +0100
+++ rfc2518bis-08-bug18.xml	2005-10-15 20:29:23.000000000 +0100
@@ -3112,23 +3112,7 @@
    to the remote server using PUT/PROPPATCH or another mechanism. 
     </t>
   </section>
-  
-  <section title="Force-Authentication Header">
-    <t>
-   Force-Authentication = "Force-Authentication" ":" Method 
-    </t>
-    <t>
-   The Force-Authentication request header is used with the OPTIONS method to 
-   specify that the client wants to be challenged for authentication 
-   credentials to the resource identified by the Request-URI.  If 
-   present on a request to a WebDAV-compliant resource, the server MUST 
-   respond with either 401 (Unauthorized) or 501 (Not Implemented) 
-   status code. The Method value is used for the client to indicate 
-   what method it intends to use first on the resource identified in 
-   the Request-URI.  
-    </t>
-  </section>
-  
+    
   <section title="If Header">
     <figure>
       <artwork>
@@ -4832,15 +4816,13 @@
   <section title="Class 'bis'">
     <t>
    A resource can explicitly advertise its support for the revisions to 
-   RFC2518 made in this document. In particular, this allows clients to 
-   use the Force-Authentication header on requests.  Class 1 must be 
+   RFC2518 made in this document.  Class 1 must be 
    supported as well. Class 2 MAY be supported.   
     </t>
     <t>
    A resource that supports bis MUST support: 
     </t>
     <t><list style="symbols">
-      <t>the Force-Authentication header.  </t>
       <t>Any behavior that it supports, in the manner specified in this 
    document, rather than in the manner specified in RFC2518, for all 
    client requests.  A server MAY use an older behavior for specific 
@@ -5200,8 +5182,7 @@
    Valuable contributions to RFC2518 bis came from some already named. 
    New contributors must also be gratefully acknowledged. Julian 
    Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out 
-   specific text on the list or in meetings. Ilya Kirnos supplied text 
-   for Force-Authentication header.  Joe Hildebrand contributed as 
+   specific text on the list or in meetings.  Joe Hildebrand contributed as 
    co-chair.
   </t>
 </section>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 17 Oct 2005 12:01:50 -0700

Out of curiosity, is this something most servers do or something that most
people have not implemented?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Oct 2005 23:36:28 +0200

> people have not implemented?

I'm not aware of any server implementing this, nor of any client using it.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 17 Oct 2005 16:23:33 -0700

Me neither, but as a client implementor, we'd certainly like to use 
this or a reasonable substitute.  We have configuration information 
about the user's account/password on WebDAV servers, and can't even use 
it until the server thinks to do an authentication challenge.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Oct 2005 09:52:42 +0200

Lisa Dusseault wrote:
> 
> Me neither, but as a client implementor, we'd certainly like to use this 
> or a reasonable substitute.  We have configuration information about the 
> user's account/password on WebDAV servers, and can't even use it until 
> the server thinks to do an authentication challenge.

As it has been in drafts for 2.5 years with nobody implementing it, I'd 
say it doesn't belong into a spec revision that's supposed to advance in 
the standards ladder.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 18 Oct 2005 09:20:41 -0700

Nobody says they implement 'bis' yet, as far as I know.  And clients 
can't support it until the server does.

Lisa

On Oct 18, 2005, at 12:52 AM, Julian Reschke wrote:

>> about the user's account/password on WebDAV servers, and can't even 
>> use it until the server thinks to do an authentication challenge.
>
> As it has been in drafts for 2.5 years with nobody implementing it, 
> I'd say it doesn't belong into a spec revision that's supposed to 
> advance in the standards ladder.
>
> Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Tue, 18 Oct 2005 13:28:43 -0700

I support a solution along the lines of force-authenticate. There are  
many times when a client would like to validate its ability to  
perform actions against a resource before performing an expensive  
network operation against that resource.

Julian--I don't think lack of implementation is a sufficient counter- 
argument. Why do you think that this feature hasn't been implemented  
(why haven't you implemented it, for example?)

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Oct 2005 00:44:47 +0200

Jim Whitehead wrote:
> many times when a client would like to validate its ability to  perform 
> actions against a resource before performing an expensive  network 
> operation against that resource.

I don't argue that. The last time the WG (ie, the mailing list) 
discussed this, the consensus was to use an If header that would be 
known to fail. There is no written record of what we discussed later at 
the face to face meeting, and I frankly can't remember. So this is a 
process issue -- if it's supposed to become part of WebDAV, it has to 
make it through the process of (1) define what the problem is, then (2) 
find a WG consensus of how to resolve this. "Force-Authenticate" may 
very well be the solution.

Then again, if we want to *progress* in the standards ladder, I don't 
think we can put in a MUST-level requirement that hasn't been 
implemented by anybody although it has been in the draft for 2,5 years. 
If we're satisfied in just revising the spec at the same standards 
level, that's a different story (but then we should apply the same 
metrics to other things we're talking about, such as preserving 
namespace prefixes in properties which has at least *one* implementation).

> (why haven't you implemented it, for example?)

We didn't implement it because

(1) no client asked for it and

(2) our server doesn't support non-authenticated access anyway.

On the other hand, Lisa has been working for a vendor that sells both 
servers and clients, so I'd be really interested to hear why it wasn't 
implemented over there? Maybe it's not that essential after all?

This really smells like a nice-to-have, in which case it certainly 
doesn't belong into a "Draft" revision of RFC2518bis.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 19 Oct 2005 12:25:23 -0700

> implemented over there? Maybe it's not that essential after all?

We haven't implemented all of WebDAV yet, let alone RFC2518bis, and 
don't claim to have a finished or fully-compliant implementation in 
either client or server yet.  We're working on it!  I highly suspect we 
will implement in client and server because we do support anonymous 
access and it's nice for clients to be able to decide to go from that 
to authenticated access.

While I'm on the topic: our WebDAV client library in progress is 
intended to be high-level and more application-oriented than the 
standard libraries that come with Python.  It's open source, naturally, 
and contributions are welcome.

http://wiki.osafoundation.org/bin/view/Projects/ZanshinProject

Lisa

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 19 Oct 2005 14:07:13 -0700

> standard libraries that come with Python.  It's open source,  
> naturally, and contributions are welcome.
>

Hey, that's really neat!

- Jim

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 27 Oct 2005 17:34:39 -0700

Julian writes:

> So this is a process issue -- if it's supposed to become part of  
> WebDAV, it has to make it through the process of (1) define what  
> the problem is, then (2) find a WG consensus of how to resolve  
> this. "Force-Authenticate" may very well be the solution.

OK, I feel pretty strongly about this feature, so let me do the due  
diligence here.

PROBLEM STATEMENT

Some WebDAV servers are configured to allow live authoring, where the  
authored changes are immediately visible to the external world. In  
this situation, resources typically have access controls set such  
that GET, HEAD, POST, PROPFIND and OPTIONS can be performed by any  
user without authentication. Write operations such as PUT, LOCK,  
UNLOCK, MKCOL, MOVE, and COPY require authentication and access  
permissions. In some cases, a client would do a series of operations  
that do not require authentication, then perform a PUT of a large  
resource (this can happen with the common Microsoft Web Folders  
client). In this situation, the large resource body needs to be sent  
twice: the initial PUT (which gets a 401 response), and the second  
PUT, with authentication credentials.

Ideally, a client would like to test a resource to see whether it  
should ever send authentication credentials. It is far more  
convenient for a client author to make a single test at the beginning  
of a session, discover that some methods will require authentication  
credentials, and then consistently supply those authentication  
credentials for every method invocation thereafter. Since a client  
does not know which authentication scheme is in use, or what nonce  
values will be used in Digest Auth, it cannot speculatively provide  
authentication values without receiving a challenge (401) from the  
server first. While in general it is the case that authentication  
requirements can vary by method, even on the same resource, this  
configuration is extremely unusual. Hence, a client that proactively  
supplies a set of authentication credentials gathered from testing  
one method that requires authentication (PUT, say), will likely find  
that these same authentication credentials will work for all other  
methods (LOCK, UNLOCK, etc.) on the same resource that also require  
authentication.

SOLUTION REQUIREMENTS

R1: A client must be able to request an authentication challenge  
without causing a state change on the server
R2:  The mechanism for the authentication challenge must be clearly  
identifiable within the specification
R3: The client must be able to indicate which method the challenge  
pertains to (since this can potentially vary by method, though it  
usually doesn't)

SOLUTION PROPOSAL

I like the Force-Authenticate header as defined in the current draft.  
I don't like the If approach (submit an If header with a known bad  
lock token, hence the method will fail) for three reasons:

* I feel uncomfortable depending on an unintended use of the If  
header -- especially for PUT, if a server ever doesn't handle If  
correctly, the forcing of authentication could inadvertently change  
the contents of the resource (assuming you'd force authentication  
with a zero length body with PUT)
* It depends on the execution order of authentication vs. If header  
processing within servers (I note this was rebutted in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ 
0335.html  and I also note that mod_dav does do authentication checks  
before If checks)
* It's a really obscure way of satisfying the requirements (i.e., it  
fails requirement R2)

My strong preference is for a new mechanism here (Force- 
Authenticate), though I could perhaps be swayed to adding a new  
section to the specification that explicitly describes the use of If  
to force authentication, and gives an example of how this works. I  
don't think this mechanism is one that most implementors would think  
of, even if the have a deep understanding of the spec (like, me, for  
example, who never thought of this).

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Oct 2005 15:47:27 +0200

Jim,

thanks for doing the "right thing" here. Comments inline.

Jim Whitehead wrote:
>  ...
> I like the Force-Authenticate header as defined in the current draft.  I 
> don't like the If approach (submit an If header with a known bad  lock 
> token, hence the method will fail) for three reasons:
> 
> * I feel uncomfortable depending on an unintended use of the If  header 
> -- especially for PUT, if a server ever doesn't handle If  correctly, 
> the forcing of authentication could inadvertently change  the contents 
> of the resource (assuming you'd force authentication  with a zero length 
> body with PUT)

I don't feel that we should add new features to the spec just because we 
fear that some servers may not get the existing stuff right. I a server 
doesn't handle the If header correctly upon PUT, this is a bug that 
needs to be fixed anyway.

As a matter of fact, of the servers I recently tested 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0328.html>), 
two were failing here, one of which not doing "If" checks at all, the 
other one treating unknown state tokens incorrectly. The latter is 
moddav, the bug is reported in 
<http://issues.eu.apache.org/bugzilla/show_bug.cgi?id=37288>, and Joe 
Orton has already attached a proposed patch.

The other servers (SAP Netweaver, Xythos, MS IIS) work as expected.

> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ 0335.html  
> and I also note that mod_dav does do authentication checks  before If 
> checks)

Yep. Is anybody aware of servers working differently.

> * It's a really obscure way of satisfying the requirements (i.e., it  

That can be fixed by putting that as note into an appendix.

> My strong preference is for a new mechanism here (Force- Authenticate), 
> though I could perhaps be swayed to adding a new  section to the 
> specification that explicitly describes the use of If  to force 
> authentication, and gives an example of how this works. I  don't think 
> this mechanism is one that most implementors would think  of, even if 
> the have a deep understanding of the spec (like, me, for  example, who 
> never thought of this).

I have no problem adding non-normative text explaining this.

On the other hand I'd really like to hear from those client 
implementors. After the three years ago, did anybody actually try the 
solution proposed back then? If not, why not?

Best regards, Julian

---

From: Jim Luther <[email-masked]>
Date: Fri, 28 Oct 2005 11:18:25 -0700

On Oct 28, 2005, at 6:47 AM, Julian Reschke wrote:

>> R2:  The mechanism for the authentication challenge must be  
>> clearly  identifiable within the specification
>> R3: The client must be able to indicate which method the  
>> challenge  pertains to (since this can potentially vary by method,  
>> though it  usually doesn't)
>> SOLUTION PROPOSAL
>> I like the Force-Authenticate header as defined in the current  
>> draft.  I don't like the If approach (submit an If header with a  
>> known bad  lock token, hence the method will fail) for three reasons:
>> correctly, the forcing of authentication could inadvertently  
>> change  the contents of the resource (assuming you'd force  
>> authentication  with a zero length body with PUT)
>
> I don't feel that we should add new features to the spec just  
> because we fear that some servers may not get the existing stuff  
> right. I a server doesn't handle the If header correctly upon PUT,  
> this is a bug that needs to be fixed anyway.
>
> As a matter of fact, of the servers I recently tested (<http:// 
> lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0328.html>),  
> two were failing here, one of which not doing "If" checks at all,  
> the other one treating unknown state tokens incorrectly. The latter  
> is moddav, the bug is reported in <http://issues.eu.apache.org/ 
> bugzilla/show_bug.cgi?id=37288>, and Joe Orton has already attached  
> a proposed patch.
>
>> * It depends on the execution order of authentication vs. If  
>> header  processing within servers (I note this was rebutted in:
>> 0335.html  and I also note that mod_dav does do authentication  
>> checks  before If checks)
>
>> * It's a really obscure way of satisfying the requirements (i.e.,  
>> it  fails requirement R2)
>
>> section to the specification that explicitly describes the use of  
>> If  to force authentication, and gives an example of how this  
>> works. I  don't think this mechanism is one that most implementors  
>> would think  of, even if the have a deep understanding of the spec  
>> (like, me, for  example, who never thought of this).
>
> implementors. After the three years ago, did anybody actually try  
> the solution proposed back then? If not, why not?
>
> Best regards, Julian

> implementors. After the three years ago, did anybody actually try  
> the solution proposed back then?

No, we didn't try it. The Mac OS X WebDAV file system handles  
challenges as it gets them and uses the protection space/domain rules  
in rfc2617 to determine when the credentials should be sent with a  
transaction.

> If not, why not?

Unlike some other clients, Mac OS X WebDAV file system always takes a  
LOCK on a resource when the file (resource) is opened with write  
access (and if LOCKs are not supported by the server, its a read-only  
mount for us). In addition, when the Mac OS X WebDAV file system is  
told to create a file that doesn't exist, it issues a PUT with a  
content-length of 0 to create an empty resource on the server (thus  
reserving the name space). Since both of those operations generate a  
challenge, we don't have the problem this bug is trying to solve.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Oct 2005 21:00:19 +0200

Jim,

thanks for the explanation (the situation for our client is similar).

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 28 Oct 2005 14:43:45 -0700

> I have no problem adding non-normative text explaining this.

I'm thinking that the right choice here is to create an appendix  
describing the problem, and the recommended solution(s). While I  
agree that we shouldn't be wily-nilly giving implementation advice,  
this is a common enough problem, whose solution is sufficiently non- 
obvious, that adding appendix text makes sense.

I also think we should add a force-authenticate feature, but I think  
it makes sense to put this in a separate "DAV-fixes" draft. This  
draft can accumulate items like Force-Authenticate, and the reliable  
etags for the body and dead properties, etc. I'll take an action item  
to start creating this draft. I'll make it a private draft, so Cullen  
doesn't have to justify the creation of a new WG item :-)

- Jim

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 28 Oct 2005 23:06:46 -0400

To avoid sending the PUT body twice, why can't a client just
use the standard HTTP "Expect 100-Continue" header?

And if a client is proactively checking for authentication preceding
a series of PUT calls, then having it just perform an initial LOCK/UNLOCK
to get the credential challenge doesn't seem like an unreasonable overhead
(2 initial requests).

So is this just a technique for servers that want to provide this
capability but don't want to support LOCK? 

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Oct 2005 21:12:18 -0700

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 not 
they're authenticated.  Some of the resources in a collection might be 
publicly readable (so the PROPFIND can succeed if anonymous) but others 
be hidden to unauthenticated users.

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 anonymous 
page version, then choosing to login.  Of course some sites use cookies 
for this but cookies are sometimes disabled, expired, etc.

Lisa

On Oct 28, 2005, at 8:06 PM, Geoffrey M Clemm wrote:

> draft.  
> checks  
> it  
> If

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 09:35:24 +0200

Jim Whitehead wrote:
> describing the problem, and the recommended solution(s). While I  agree 
> that we shouldn't be wily-nilly giving implementation advice,  this is a 
> common enough problem, whose solution is sufficiently non- obvious, that 
> adding appendix text makes sense.
> 
> I also think we should add a force-authenticate feature, but I think  it 
> makes sense to put this in a separate "DAV-fixes" draft. This  draft can 
> accumulate items like Force-Authenticate, and the reliable  etags for 
> the body and dead properties, etc. I'll take an action item  to start 
> creating this draft. I'll make it a private draft, so Cullen  doesn't 
> have to justify the creation of a new WG item :-)

Sounds good.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 10:20:45 +0200

> use the standard HTTP "Expect 100-Continue" header?

It could, but it's a known problem that few servers implement that 
correctly, meaning that the expected header check is indeed skipped (for 
instance, a server using the servlet API normally doesn't have any 
chance doing this check, see 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4812000>).

> capability but don't want to support LOCK?  

Seems so, because LOCK seems to be yet another existing way to get what 
those clients want.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 10:22:57 +0200

> be hidden to unauthenticated users.

But you could still use LOCK to enforce authentication, right?

> 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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 29 Oct 2005 08:45:42 -0400

I agree that LOCK is the real answer here for WebDAV clients.

But for the "force-authenticate" advocates (which Julian is not):
If we are contrasting "Expect 100-Continue" vs. "force-authenticate", 
I think it would make more sense to advise servers to implement Expect
correctly rather than to introduce a new force-authenticate header.
In particular, why would one believe that a server that doesn't implement
Expect properly would implement force-authenticate properly (or at all).

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 29 Oct 2005 11:07:54 -0400

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 
problems
that need to be addressed.

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 29 Oct 2005 08:38:02 -0700

So if you wanted to browse a collection, and see all the 
non-publicly-readable resources alongside the publicly readable 
resources, you'd try to LOCK that collection?  That's actually a state 
change if it succeeds, may have significant side effects.

Expect is a reasonable solution in theory.  However, it's harder to 
implement, which is why a simpler mechanism might see more 
implementation.
   - Expect requires the server to maintain more state, for longer, 
while the client gets back with the rest of the request (when a success 
response happens).  It's unique in splitting the request and response 
up.
  - Expect could be subject to trivial DOS attacks.
   - As Julian pointed out, Java servlet engines don't allow this kind 
of flexibility, while a servlet could implement Force-Authenticate (or 
something similar) without requiring changes in the servlet engine.  
There are probably similar restrictions in other cases -- maybe IIS' 
API, Apache's module API, I don't know.

Are there any other solutions?  To throw out some possibilities no 
matter how cheesy:

1.  A LOGIN method (while it would make purists scream) could be 
defined such that it always caused an authentication challenge.  (It 
wouldn't keep the user logged in for every subsequent request -- only 
requests which continued to have the right auth header from then on.)

2. If the client knows it wants to authenticate, perhaps it could send 
an Authorization header on its very first request.  Because the client 
doesn't want to actually reveal any username or password until it has 
learned the 'realm' value, the header value has to be bogus.

        PROPFIND / HTTP/1.1
        Authorization: Basic BOGUSSTRING:BASE64ENCODED

With Basic, the server either reject Basic auth entirely, or try to 
decompose the string. The username portion would be looked up in the 
user database.  There's always a chance that a valid user name would 
exist for whatever bogus string was chosen.

Using Digest, there's an opportunity to use a bogus realm:

       Authorization: Digest realm="CHALLENGE"

So another variation is to send an Auth header that's neither Basic or 
Digest:

       Authorization: CHALLENGEME

Existing servers would probably return 400 Bad Request or Not 
Implemented to the above 2, so such a plan would have to be widely 
disseminated so servers could change.

All of these Auth header hacks are in some sense inferior to the 
clean-ness of defining Force-Authenticate, but that's just an aesthetic 
opinion.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 18:03:21 +0200

Lisa Dusseault wrote:
> implement, which is why a simpler mechanism might see more implementation.
> - Expect requires the server to maintain more state, for longer, while 
> the client gets back with the rest of the request (when a success 
> response happens). It's unique in splitting the request and response up.

I'm not sure I understand this. Using Expect: 100-continue only means 
that the server has a chance to reject the request before the body is 
sent. What am I missing here?

> - Expect could be subject to trivial DOS attacks.

Please explain.

> - As Julian pointed out, Java servlet engines don't allow this kind of 
> flexibility, while a servlet could implement Force-Authenticate (or 

To me that means that the servlet engines should be enhanced, just like 
in the bug description I posted.

Statements about other servers are really just hand-waving, unless you 
have solid information.

Anyway: this is not a WebDAV problem. Compile a problem statement, and 
try to get people working on a separate specification. Possibly on the 
http WG mailing list.

Best regards, Julian

---

From: Jim Luther <[email-masked]>
Date: Mon, 31 Oct 2005 08:52:56 -0800

On Oct 29, 2005, at 1:22 AM, Julian Reschke wrote:

>> 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 anonymous page  
>> version, then choosing to login. Of course some sites use cookies  

I agree with those who have said this is not a WebDAV specific issue.  
It should be discussed as a separate HTTP issue.

- Jim

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 31 Oct 2005 10:05:37 -0800

There are two issues with Expect 100-continue:

* It is only permitted for methods with request bodies -- it would be  
far better for a client to have a single mechanism that worked for  
all methods.
* The server's behavior after sending a final status code (i.e., a  
4xx) is not great -- either read the entire request body and send to / 
dev/null, or drop the TCP connection. It would be far better if the  
client never sent the request body in the first place.
* From reading the HTTP specification, it's really unclear to me how  
Expect 100-continue works with proxy authentication. It almost seems  
as if this mechanism allows you to bypass proxy authentication.

However, I still think the right action here is:

* Create a new appendix in 2518bis
* In this appendix, document the problem
* Describe the known approaches for addressing the problem (If  
approach, 100-continue approach) and their issues
* Create a separate draft focusing just on the Force-Authenticate  
approach, and discuss on HTTP-WG list.

Julian seems to think this is an OK approach. Geoff seems to think  
this is OK. Jim Luther agrees with the separate draft part.

Dang if that doesn't seem like something approaching rough consensus  
to me.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2005 19:14:47 +0100

Jim Whitehead wrote:
> far better for a client to have a single mechanism that worked for all 
> methods.

Well, it only has an *effect* for messages with request bodies.

> * The server's behavior after sending a final status code (i.e., a 4xx) 
> is not great -- either read the entire request body and send to 
> /dev/null, or drop the TCP connection. It would be far better if the 

My understanding was that the client will never send the body it doesn't 
get the 100 Continue.

> Expect 100-continue works with proxy authentication. It almost seems as 
> if this mechanism allows you to bypass proxy authentication.
> 
> * Describe the known approaches for addressing the problem (If approach, 
> 100-continue approach) and their issues
> Julian seems to think this is an OK approach. Geoff seems to think this 
> is OK. Jim Luther agrees with the separate draft part.
> 
> Dang if that doesn't seem like something approaching rough consensus to me.

Sounds good.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Oct 2005 10:56:40 -0800

Unless more than one person objects in the next week, I'm going to invoke
one of my rare Chair privileges and claim that looks like consensus to me
too.

On 10/31/05 10:05 AM, "Jim Whitehead" <[email-masked]> wrote:

> * Create a separate draft focusing just on the Force-Authenticate approach,
> and discuss on HTTP-WG list.
> 
> Julian seems to think this is an OK approach. Geoff seems to think this is OK.
> Jim Luther agrees with the separate draft part.
>

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 31 Oct 2005 13:07:21 -0800

To clarify, would the Authorization header hacks I mentioned last week 
count as one of the known approaches?

Lisa

On Oct 31, 2005, at 10:56 AM, Cullen Jennings wrote:

>
>  Unless more than one person objects in the next week, I'm going to 
> invoke one of my rare Chair privileges and claim that looks like 
> consensus to me too.
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2005 23:09:47 +0100

> count as one of the known approaches?

Are you talking about the stuff in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0416.html>?

If this works and is compliant with the base specs (2616/2617), why not? 
Otherwise, why bother?

Best regards, Julian