Re: Our Schedule

First, I want to let folks know that Chromium's canary channel is ready for
h2-12 interop testing as of last week (pass the "--enable-spdy4" flag, an
internal name for HTTP/2). I'll submit a PR to update the wiki. Please take
it for a spin, and let me know how it goes!

I'm a relative newcomer to HTTP/2 myself, not having heard of it (or HPACK)
prior to late January. I knew of SPDY, but hadn't worked with it. Since
then I've been working on all things SPDY & HTTP/2 within Chromium and (to
a lesser degree) Google's frontend. I've been the primary implementor of
HPACK (including Huffman), but haven't had significant input in it's design.

My opinion is that it's certainly non-trival, but it's still pretty
manageable, and it's no more complex than it needs to be. The spec is well
defined, and in practice interop with multiple parties has gone without any
gotchas surfacing. It's early still, and they may, but they haven't yet and
that's a positive datapoint.


 I have posted what I think is the real state machine
> > (
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/att-0720/http2state.txt
> )
> > and it is a much more complex beastie.
>
> I am worried about the diagram posted by Greg above. The number of
> ways it could be implemented wrongly is large.
>


While this looks scary, I think what's actually happening here is that the
diagram is composing two independent state machines into one. The HTTP/2
stream state machine (which never transitions on CONTINUATION), with a
two-state frame parser state machine (expect continuation / don't expect
continuation). There's no reason these machines need to be composed (and
implementations I've worked with, don't).

I do agree that the close state could be firmed up. There's an third
implied, independent state machine for streams in the closed state which
bears on handling when to RST, when to ignore, when to GOAWAY with a
connection error. Perhaps this can be formalized.


For example in SPDY, where header compression is not that complex and
> based on libraries widely available for any language (deflate), I
> think the issue of header compression is nonetheless the #1 question /
> problem / roadblock for SPDY implementers. HTTP 2.0 should simplify
> this, not making it more complicated.
>


Buried in this is perhaps the kernel of objections against HPACK: the
specification is too new for off-the-shelf libraries to exist. If a
requirement of SPDY were that deflate needed to be implemented from
scratch, the road to adoption would have been much longer. Unfortunately
CRIME happened, and deflate isn't an option. I suspect if good libraries
for HPACK were available, there wouldn't be nearly so much objection.

I'll note that the Chromium's license is very permissive, and Chromium's
implementation is available
here<https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/hpack_encoder.h&sq=package:chromium>.
If there's interest, I'd be happy to work with folks on packaging it as a
library.

cheers,
-johnny