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

Re: Updated Delta+BOHE Impl in Java

From: James M Snell <jasnell@gmail.com>
Date: Tue, 9 Apr 2013 10:58:46 -0700
Message-ID: <CABP7Rbcomc=zntQ1FQZ-kqDsrBNoBKXJiCe1++AEY02d8oxToA@mail.gmail.com>
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

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