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:07 -0700
Message-ID: <CAP+FsNdXGeRKKeHXSTT-VtsVRypjhyLeMp2GyhMGNdGT7n3t7Q@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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:43:34 UTC

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