Re: 100 Continue and Expects

I did a review of what browsers do in some cases like this (e.g POST + 
auth/NTLM) a while back.

Their behaviour varies.  For instance IE (even current) if it thinks it 
will get an auth challenge, will submit initial POSTs with a 
content-length 0 (this breaks a heap of stuff).

FF and Chrome will send the whole POST body as many times as required to 
get through auth.

Server behaviour varies also.  IIS5 for instance will send a 100 
continue on all POST requests regardless of whether they contain 
Expects.  In fact I've never seen a browser send Expects.

I wrote a I-D partly about this a while back, but it was somewhat 
misguided, based on my misunderstanding of the Expects mechanism.

In the end, I think that's the biggest problem with Expects - people 
expect (pardon the pun) more from it than it delivers.  The reason the 
history of this list contains numerous discussions about Expects, is 
because of common misinterpretation.

The wording in the RFC implies that Expects and 100 Continue can be used 
to avoid sending the body of a request.  It omits to mention that if 
indeed you do want to avoid this (e.g. when you get a 3xx or 4xx), you 
either need to disconnect and re-try, or complete the message some other 
way (e.g. use chunking and prematurely complete it with a 0 chunk).

I would really hate to see anyone adopt the 0 chunk approach - it's just 
as bad as sending Content-Length: 0 when the browser thinks the proxy or 
server will send an auth challenge.  Browsers second-guessing proxies / 
servers is not a good option, and when the browser gets it wrong, things 
get ugly.  We had to write a hack into WinGate to cope with the IE 
misbehaviour (WinGate only sends an auth challenge when policy dictates 
auth is required - the browser cannot possibly predict this, and a 0 
length post is valid, but breaks websites).  Sending a 0 length chunk 
tells the proxy the message is complete.  It could then go through many 
stages of processing that is really undesirable.  There's no way to 
signal an abort and maintain a connection.

In the end, the best option IMO is to send the whole thing each time (as 
per FF and Chrome - sorry don't know what Opera does).  It can be 
hideously painful with chained connection-oriented auth over a slow link.

So actually there's no clean solution to this problem.  I proposed a 
while back a kind of HEAD command for POST to establish a path with 
credentials before posting a body.  But in the end, any proper solution 
to this problem will be a significant protocol change to HTTP (since 
HTTP is designed for intermediaries to be able to work with unknown 
methods), which means we'll be living with this problem for a long time yet.

As for NTLM, it's not going away either.  So much as people don't like 
it because it's not HTTP compliant auth - it's the reality we are stuck 
with.

Cheers

Adrien


On 30/03/2010 12:22 p.m., Jamie Lokier wrote:
> Henrik Nordström wrote:
>    
>> sön 2010-03-28 klockan 15:20 +0100 skrev Jamie Lokier:
>>      
>>> With certain types (Microsoft) of authentication
>>>        
>> You forgot to add "which is not true HTTP authentication schemes". That
>> family of auth schemes makes many assumptions which is opposite the
>> intentions of the HTTP specifications so using them as an example when
>> trying to understand the wording of the specification text is not valid.
>>
>> Still interesting when talking about what should be said as they are a
>> reality and something HTTP has to deal with today, but not when trying
>> to understand why RFC2616 is written in a certain manner.
>>      
> Agreed, Microsoft's version is not standard HTTP.
>
> Regardless of why, it's important to recognise that clients have the
> option to send the whole request body if they decide to, despite one
> possible reading of that section of RFC2616 that they must abort.
>
> -- Jamie
>
>

Received on Tuesday, 30 March 2010 00:42:55 UTC