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

Re: Next pre-draft implementation in javascript.

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 23 Oct 2013 08:43:44 -0700
Message-ID: <CAP+FsNfPW=9DwPRZKAU-DPgXydp7-uYMtq=_2TrWavAUM0viAA@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC