Re: 100 Continue and Expects

Henrik Nordstrom wrote:
> lör 2009-07-18 klockan 16:58 +1200 skrev Adrien de Croy:
>
>   
>> a) try your POST with a Content-Length: 0 like IE does (which causes 
>> other problems)
>>     
>
> Not in this context.
>
>   
I guess I'm mixing auth with 100-continue and expects.  The reason for 
this is that a frequent reason why it may be inappropriate to send the 
full body is because of auth.

So in my mind they are strongly linked.  In fact apart from redirects, 
auth is the only case I can think of.

>> b) use chunking for your request bodies and prematurely abort the send 
>> with a 0 chunk.
>>     
>
> c) Closing the connection when it's determined that sending the message
> body is undesireable.
>
>   
Sure, but that's not an option for connection-oriented auth.

>> methods or send the whole message.  If you're trying to use 
>> connection-oriented auth (like many millions of people are every day) 
>> then you're basically hosed
>>     
>
> Which is why you should not use connection-oriented auth with requests
> having Content-Length. I don't see how that's related to 100 Continue or
> Expects. Connection-oriented auth is plain broken in the message
> oriented context of HTTP.
>
>   
easier said than done.  when people want to use NTLM, try getting them 
to use something else.

Obviously digest is the other option.

>   
>> Under "Requirements for HTTP/1.1 origin servers"
>>
>> clause 3 contradicts the MUST requirement in clause 1.  e.g.
>>
>>    o  An origin server MAY omit a 100 (Continue) response if it has
>>       already received some or all of the request body for the
>>       corresponding request.
>>
>> conflicts with
>>
>>    o  Upon receiving a request which includes an Expect request-header
>>       field with the "100-continue" expectation, an origin server MUST
>>       either respond with 100 (Continue) status and continue to read
>>       from the input stream, or respond with a final status code.
>>     
>
> True. But the intentions is quite obvious if one reads both.
>
>   
>> the way I read the first clause is that the server must immediately 
>> reply either with 100 continue or the final status (e.g an auth 
>> challenge etc). 
>>     
>
> Not my reading.
>
>   
>>  That's the whole point of 100 continue.  However the 
>> 3rd clause implies if you've already read something it's ok to wait 
>> around for the final status.
>>     
>
> iff the client has aready sent you some part of the request body, in
> which case the server knows the client has already left it's expectation
> of a 100 Continue response.
>
>   
OK, that makes sense thanks.  But does that mean the client already gave 
up waiting?

>   
>> Under "Requirements for HTTP/1.1 proxies"
>>
>> o Proxies SHOULD maintain a cache recording the HTTP version numbers 
>> received from recently-referenced next-hop servers.
>>
>> this is problematic.  I've seen sites that respond with varying HTTP 
>> versions in the responses (even with same server).
>>     
>
> Which is broken servers.
>
>   
>> Presumably due to versions being set in different scripts.
>>     
>
> and servers not implementing HTTP for those scripts..
>   
OK.  Some server architectures make this difficult for them, I imagine 
it's pretty wide-spread, and depends on the scripts.

A server needs to parse and fix script output to fix this.

>   
>> I know that the issue of Expects has been thrashed on this list 
>> already.  I understand the theory of why such a mechanism is required, 
>> but in the case of 100 continue (the only one specified) it's so 
>> problematic I'd be very surprised if any client ever implements it.
>>
>> Does anyone know of any (IMO suicidal) client that uses Expects? 
>>     
>
> There is quite many using it today. And many of those isn't prepared to
> deal with expectation failures.. (learnt the hard way when implementing
> Expect...)
>   
that puts the proxy in a difficult position.  Is it allowed to send the 
100 continue itself?

Or are there other expectations now than only 100-continue which these 
clients rely on?

I can't really see the point of relying on 100 continue.

> On a side note I have also been thinking about this version cache topic
> lately in another topic. Will post about that later today..
>   
sure, the other obvious application (where you need apriori knowledge of 
the server protocol version support)
that comes to mind is chunked request bodies.

Regards

Adrien

> Regards
> Henrik
>
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Saturday, 18 July 2009 22:13:57 UTC