- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 9 Apr 2013 10:58:46 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I pulled the values from Roberto's most recent draft here [1]. I believe he put it together from the corpus of sample data that's been collected in the github repo. [1] http://tools.ietf.org/html/draft-rpeon-httpbis-header-compression-03 On Tue, Apr 9, 2013 at 10:37 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > This is great news. > > Out of interest: Where did you derive the values you used to build > your Huffman tables? > > On 9 April 2013 10:24, James M Snell <jasnell@gmail.com> wrote: >> I have updated my experimental Delta+Bohe java implementation to match >> the current draft of the specification and Roberto's current delta >> iteration. I still have to patch this in to the compression-test stuff >> but the code is functional. >> >> https://github.com/jasnell/http2 >> >> Requires maven to build. Dependencies are light. Still needs a ton of >> work and I have not even started working on performance optimizations. >> It's a pretty straight forward port of everything Roberto has done in >> the python impl. >> >> The one bit this does add is multi-type header values. The types >> supported are String, Number, Datetime and Binary. Strings can be >> either UTF-8 or ISO-8859-1. If they are ISO-8859-1, they can be >> Huffman coded using Roberto's static code. I am using an different >> static dictionary of predefined header values tho. >> >> General takeaways .. >> >> 1. The implementation is not that difficult to do and seems to perform >> reasonably well. >> 2. The additional types are very useful and add minimal additional >> complexity to the implementation. >> 3. I'm generally not convinced that we really need the huffman coding. >> Yes, it saves a handful of bytes here and there but it does add >> additional complexity. I can live with it tho. If we keep it and we >> decide to allow for UTF8 header values, then we need to come up with a >> static huffman coding that includes the extended UTF8 character >> support. >> 4. Performance seems reasonable overall. >> >> I'm going to be working on implementing HeaderDiff next. Hopefully >> I'll have the time to have that done by this Friday. >> >> - James >>
Received on Tuesday, 9 April 2013 20:29:45 UTC