W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: HEADERS and flow control

From: Michael Sweet <msweet@apple.com>
Date: Fri, 23 May 2014 15:22:59 -0400
Cc: Matthew Kerwin <matthew@kerwin.net.au>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <48D6396B-00DB-41C9-B441-469BFD8629F1@apple.com>
To: Cory Benfield <cory@lukasa.co.uk>

On May 23, 2014, at 2:53 PM, Cory Benfield <cory@lukasa.co.uk> wrote:

> On 23 May 2014 at 01:32:12, Matthew Kerwin (matthew@kerwin.net.au(mailto:matthew@kerwin.net.au)) wrote:
>> ​It's also the single most complex part of the spec​ to implement. My side-project implementation has hiccupped and stalled every time it's bumped into continuation frames and hpack. I've currently stopped all work on it until I have time to go through and read in much more detail the hpack draft, and some related archived conversations on the list, and Canonical prefix encodings and Huffman coding, etc.  
>> If I could negotiate not using HPACK I could probably have the rest of my implementation up to some sort of interop testing by now.  
> Could not agree more.
> I don't want to harp on this too much because I've mentioned it before, but
> HPACK is really complex and so, so easy to get wrong. The only way to find out
> whether you've got it right is with really rigorous integration testing and
> even that's not really sufficient to catch every edge case.
> Implementing HPACK is so much harder than implementing HTTP/2. A naive HTTP/2
> implementation is simply not that difficult. However, there's no such thing as
> a naive HPACK implementation, only wrong implementations.

Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Friday, 23 May 2014 19:23:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC