Re: http/2 & hpack protocol review

I'm the author of the original commentary on the consequences of HTTP 2 for
embedded devices (or, in general, anything that isn't a web server or
browser), which was written to explore how a move to HTTP 2 would potentially
affect non-web-browser users.  To respond to some specific points:

>If HTTP/2 is inappropriate for a case where HTTP/1.1, that's a problem we
>need to solve. This WG is chartered to define a new protocol version that can
>*replace* HTTP/1.1.

Combining the reply to this and other comments people have made about "let
them eat HTTP 1.1" or "HTTP 2 isn't meant for this":

HTTP 0.9 was designed to communicate web pages between web servers and web
browsers.  It ended up being used as a universal substrate for the Internet.

HTTP 1.0 was designed to communicate web pages between web servers and web
browsers.  It ended up being used as a universal substrate for the Internet.

HTTP 1.1 was designed to communicate web pages between web servers and web
browsers.  It ended up being used as a universal substrate for the Internet.

You can probably see where this is going...

So, no matter what the people designing HTTP 2.0 may want, it's going to end
up as the universal substrate for the Internet.  The only question is, will it
be a clearly-defined, well-specified substrate, or a bunch of not-very-
compatible vendor-specific hacks on the current 2.0 spec to try and trim it
down to something that functions as a universal substrate?

>Perhaps an update to BCP 56 (aka http://www.ietf.org/rfc/rfc3205.txt ) "On
>the use of HTTP as a Substrate" and explicit warnings about the
>inappropriateness of HTTP/2 for these other applications belongs in the HTTP2
>introduction.

Yeah, because that approach has worked so well to date...

>the pain I had with HPACK suggests it's a potential pain-point for a lot of
>others as well.

As the author of the original HPACK (see e.g.
https://www.freshports.org/archivers/hpack.non-usa.only/), maybe it could be
renamed so it doesn't give my original HPACK a bad name :-).

Peter.

Received on Tuesday, 6 May 2014 10:38:02 UTC