Re: [google-gears-eng] Re: Deploying new expectation-extensions

I think that's possibly your best option.

For what it's worth, RFC 1945 (HTTP 1.0) specified the existence of 1xx 
response codes, and defined them as provisional, however specified that 
there aren't any valid 1xx responses to any HTTP/1.0 request (seems to 
be predicting a later iteration of the protocol).

so anyway, the concept of a provisional (and therefore to be ignored) 
1xx class of responses was defined in 1.0, so if we're lucky then people 
who implemented 1.0 proxies read that and they should be able to cope 
with them.

Actually it's quite interesting looking through HTTP 1.0 again... it was 
so much simpler!  Only 3 methods for starters, which really betrays the 
way HTTP evolved, and why we have issues negotiating transfer of message 
bodies for uploads... because HTTP was fundamentally designed as a 
retrieval protocol, not an upload protocol.

I think until we adopt proper handling of uploads (i.e. pre-authorised / 
negotiated etc) we'll have problems - esp with large uploads and auth.  
But there I go flogging that poor dead horse again...

Adrien


Charles Fry wrote:
>>  For what it's worth it could have been spelled "Expect: HTTP/1.1". with
>>  the same effect.
>>     
>
> See, what we really want is exactly "Expect: HTTP/1.1" so that we can
> be certain that we can spend a 1xx class response, but as far as I can
> tell there is no way to actually accomplish this, other than just
> spewing out our 1xx response, with utter disregard for any
> non-compliant proxies in the downstream path. But at this point I
> don't see any other viable option.
>
> Charles
>
>   

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

Received on Monday, 7 April 2008 11:44:31 UTC