Re: Rechartering HTTPbis

In message <1327586688.2052.386.camel@ds9>, Patrick McManus writes:

>The binary length delimiters used in SPDY (for header names, values, and
>chunk lengths) are great because they are unambiguous as well as MUCH
>cheaper to parse.

Indeed, which points at another possible attack-angle on HTTP/2.0:

Make HTTP/2.0 the speed-optimized but feature-limited version, and
leave HTTP/1.1 for the feature-optimized version.

>The interesting parts to me are transaction (re-)prioritization, push
>semantics (and caching related issues), flow control, good rules around
>ip pooling especially involving credentials, caching, bandwidth
>utilization and congestion responsiveness (especially against real time
>flows), and an upgrade/alternate-protocol mechanism from plaintext http.

And those "interesting parts" is what will make the HTTP/2.0 spec a
500 page monster, unless we stop now and smell the roses.

The thing we are looking for here, are not tons and tons of weird-ass
options, but simple, general mechanisms which are easy to describe,
easy to use and easy to make work right.

For instance, starting to put "congestion responsiveness", whatever
it is, on top of TCP sounds just plain bogus to me.

It shoulds like an attempt to work around a problem which should
be solved where it lives (TCP & deep black buffers ?) rather than
inefficiently band-aided around at a random higher different level.
(See also: OSI protocols)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Thursday, 26 January 2012 14:19:38 UTC