Re: [Fwd: I-D ACTION:draft-decroy-http-progress-00.txt]

tor 2007-02-15 klockan 05:07 +1300 skrev Adrien de Croy:

> The problem you raise is easily fixed though, if we require the client 
> to advertise support for flow control
> with a tag in say the Connect header (or maybe another tag).

Expect: 1xx-defer

Why Expect? Because the client need to be told if any step along the
path does not support the needed extension forcing it to fall back to
current behavior.

Problem: Ignored by HTTP/1.0 proxies and servers, but it can probably be
dealt with as the extension must be supported by each hop to be used and
you already concluded each proxy hop must implement the 100 Continue
timer if the next hop is not known to support the extension.

> yes, I think the expects header has some resistance to implementation.  
> Due mainly to
> 
> 1. difficulty in clients maintaining knowledge about whether servers 
> support 100 continue or not

The problem is knowing if the server supports Expect, not if 100
Continue is supported.

> 2. possibility that any request sent with a expects header will be 
> rejected purely because of that header.

Which isn't a bad thing.

> 3. lack of support from HTTP/1.0 servers

Pretty much the same as '1'.

> If all the web clients I've investigated this for actually used an 
> Expects header, this would be a moot point
> but I've never seen one sent... ever.
> 
> Maybe the IE and Firefox teams are just a bit paranoid :)

Or maybe they haven't seen a point in using one as most servers assumes
any HTTP/1.1 client understands 100 Continue anyway..

The only case where conforming implementations will reject an "Expect:
100-continue" is proxies when the next hop is known to be HTTP/1.0. All
HTTP/1.1 conforming implementations MUST support 100 Continue.

Regards
Henrik