- From: Roberto Peon <grmocg@gmail.com>
- Date: Tue, 9 Apr 2013 13:52:26 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNc=HzMcCUivZdqt1nA6oZ_U2sM6mPp+-3TKDQ+4Y3TbGg@mail.gmail.com>
yup. -=R On Tue, Apr 9, 2013 at 10:58 AM, James M Snell <jasnell@gmail.com> wrote: > 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:52:53 UTC