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

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

On Oct 29, 2005, at 5:45 AM, Geoffrey M Clemm wrote:

>
> 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
>
> Julian wrote on 10/29/2005 04:20:45 AM:
> >
> > Geoffrey M Clemm wrote:
> > >
> > > To avoid sending the PUT body twice, why can't a client just
> > > 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>).
> >
> > > 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?
> >
> > Seems so, because LOCK seems to be yet another existing way to  
> get what
> > those clients want.
> >
> > Best regards, Julian
> >