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

Re: Next pre-draft implementation in javascript.

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Thu, 24 Oct 2013 01:08:02 +0900
Message-ID: <CAPyZ6=LPREFEGzgzMgwe76gUU273E1OFy9hY2=y+pFajgsSjew@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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:08:53 UTC

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