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 09:09:07 -0700
Message-ID: <CAP+FsNfs-fLR65WS=VrYZ+8yMpq456LtfofKCkyw2_udnZx1Zw@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Correct.

For example if the HEADER_TABLE_SIZE is zero, then one may still refer to
elements from the static set, but there are never elements in the reference
set.
-=R


On Wed, Oct 23, 2013 at 9:08 AM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com>wrote:

>
>
>
> On Thu, Oct 24, 2013 at 12:43 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> If that fails, then there is no reference left in the reference set....
>> for that entry (sorry for being ambiguous there :) )
>> -=R
>>
>>
> I missed that change in section 3.2.1.
> Does "fail" occur only when its size is larger than
> SETTINGS_HEADER_TABLE_SIZE?
>
> I found there are several locations which state that reference set is
> referencing to the static table, which is a bit confusing:
>
> 3.1.3 <http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-04#section-3.1.3>.  Reference Set
>
>
>    A reference set is an unordered set of references to entries either
>    within the header table or the static table.
>
>
> Best regards,
>
> Tatsuhiro Tsujikawa
>
>
>
>
>
>>
>> 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 16:09:35 UTC

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