- From: Michael Sweet <msweet@apple.com>
- Date: Fri, 23 May 2014 15:22:59 -0400
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Matthew Kerwin <matthew@kerwin.net.au>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
+1 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