- From: Roberto Peon <grmocg@gmail.com>
- Date: Wed, 23 Oct 2013 08:43:44 -0700
- To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNfPW=9DwPRZKAU-DPgXydp7-uYMtq=_2TrWavAUM0viAA@mail.gmail.com>
If that fails, then there is no reference left in the reference set.... for that entry (sorry for being ambiguous there :) ) -=R On Wed, Oct 23, 2013 at 8:43 AM, Roberto Peon <grmocg@gmail.com> wrote: > The indexed representation part of the spec is changed in 04. > It mandates that one (attempt to) append the entry from the static table > to the header table after emitting it. > If that fails, then there is no reference left in the reference set. > If it succeeds, a reference to the header table entry is added. > > Essentially, this change implies that the only things that can be in the > reference set are those in the header table. > Things in the static table cannot be in the reference set-. > > -=R > > > On Wed, Oct 23, 2013 at 5:10 AM, Tatsuhiro Tsujikawa < > tatsuhiro.t@gmail.com> wrote: > >> >> >> >> On Wed, Oct 23, 2013 at 7:58 AM, Roberto Peon <grmocg@gmail.com> wrote: >> >>> Dang! >>> >>> I used shift() instead of pop() in the javascript implementation. >>> While that is now fixed, the draft examples will be incorrect, as they >>> were based on this implementation. >>> >>> >> I noticed that the js implementation does not use indexed representation >> encoding for static table at all. For example, ":method: GET" can be >> encoded as 81, but the encoder encodes it as literal. Is it intentional? >> From the 04 spec, it seems to be completely legal and whole point of adding >> header value in static table is for this operation. >> >> Best regards, >> Tatsuhiro Tsujikawa >> >> >>> -=R >>> >>> >>> On Mon, Oct 21, 2013 at 9:18 AM, Roberto Peon <grmocg@gmail.com> wrote: >>> >>>> The spec should be updated and submitted as draft later today. >>>> Tatsuhiro is correct that the version in the draft is currently out of >>>> date. >>>> The version in the javascript will be the version in the draft (soon). >>>> >>>> Cool that there is already interop! That is fast! Awesome! >>>> -=R >>>> >>>> >>>> On Mon, Oct 21, 2013 at 9:15 AM, Tatsuhiro Tsujikawa < >>>> tatsuhiro.t@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Oct 21, 2013 at 11:08 AM, Roberto Peon <grmocg@gmail.com>wrote: >>>>> >>>>>> I'm implemented all of the next (pre) draft version of compression >>>>>> here: >>>>>> https://github.com/grmocg/httpbis-header-compression >>>>>> >>>>>> (Apparently this might work: >>>>>> http://rawgithub.com/grmocg/httpbis-header-compression/master/compressor_test.html >>>>>> ) >>>>>> >>>>>> which should soon be merged here, as it is a modification of Fred's >>>>>> original JS compressor: >>>>>> https://github.com/akalin-chromium/httpbis-header-compression >>>>>> >>>>>> >>>>>> It provides for separate encoding/decoding steps, showing the output >>>>>> (or input, depending) as hex, as well as the state of the table, and >>>>>> opcodes as they're decoded. >>>>>> >>>>>> Hopefully this means that you should be able to verify interop more >>>>>> easily than last time since you can just run this in your browser in a tab. >>>>>> >>>>>> >>>>> I have also implemented the HPACK with huffman in nghttp2. >>>>> https://github.com/tatsuhiro-t/nghttp2/tree/hpack-exp >>>>> >>>>> It seems the XML has older huffman tables, so I got ones in >>>>> javascript compressor output. >>>>> >>>>> I conducted some encode/decode tests between javascript compressor and >>>>> nghttp2, and they are working beautifully. That is a promising start of the >>>>> next interop round. >>>>> nghttp2 has now some command line tools to test compression, which can >>>>> take inputs in JSON. >>>>> >>>>> Best regards, >>>>> >>>>> Tatsuhiro Tsujikawa >>>>> >>>>> >>>>> >>>>> >>>>>> .. and now back to hacking on the spec.. >>>>>> -=R >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >
Received on Wednesday, 23 October 2013 15:44:14 UTC