100 Continue and Expects

Hi All, I'm just reading through p1-messaging.

there are a few problems with S 7.2.3

First para regarding the purpose of the status is misleading.  It 
implies one can avoid sending a message body.  It doesn't go into the 
grisly details of how one would actually avoid sending the message body 
and the associated problems, which is one of

a) try your POST with a Content-Length: 0 like IE does (which causes 
other problems)
b) use chunking for your request bodies and prematurely abort the send 
with a 0 chunk.

Both of these methods have problems.

If you've made the awful mistate of sending a Content-Length with your 
POST, you're doomed to disconnect and try again with one of the other 
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, or have to use option a or just bite the 
bullet and send the whole message body each time (which most browsers 
other than IE do).  I've already complained about the 0 length POST, 
which breaks conditional auth (where auth may not always be challenged 
for by a proxy / site).  We've already had to code a nasty hack into 
WinGate to cope with this (if method=POST and Content-Length = 0 and 
haven't authed, then send auth challenge regardless of policy).  And 
about the use of chunked requests (which discovers many broken 
proxies/servers).  I think the best solution from an engineering 
standpoint is an extension of HEAD to allow it to test other methods 
rather than just GET, or another method which does the same thing (e.g. 
a TEST method).  This is a major version change to the protocol though. 

Anyway, in terms of a proposal for the section, I'd like to see some 
mention of the options / problems, because they are far from 
obvious/intuitive.


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.


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).  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.  Propose striking clause 3, or adding "in 
which case it must immediately send the final status", or limit the 
applicability of this clause to the case where there was no Expects: 
100-continue sent.

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).  Presumably due to 
versions being set in different scripts.  It's impossible to cache 
version vs site in these cases.  Sure, can cache the rest, but the 
overhead of keeping a cache for this purpose seems overly heavy.

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? 

Regards

Adrien

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

Received on Saturday, 18 July 2009 04:55:07 UTC