Subject: Next pre-draft implementation in javascript.

From: Roberto Peon <[email-masked]>
Date: Sun, 20 Oct 2013 19:08:29 -0700

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.

.. and now back to hacking on the spec..
-=R

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Tue, 22 Oct 2013 01:15:53 +0900

> 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

---

From: Roberto Peon <[email-masked]>
Date: Mon, 21 Oct 2013 09:18:57 -0700

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
<[email-masked]>wrote:

>> 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.
>>
>>
> nghttp2 has now some command line tools to test compression, which can
> take inputs in JSON.
>
> Best regards,
>
> Tatsuhiro Tsujikawa
>
>
>
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 22 Oct 2013 15:58:57 -0700

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.

-=R

On Mon, Oct 21, 2013 at 9:18 AM, Roberto Peon <[email-masked]> wrote:

> On Mon, Oct 21, 2013 at 9:15 AM, Tatsuhiro Tsujikawa <
> [email-masked]> wrote:
>
>>
>>
>>

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 23 Oct 2013 21:10:58 +0900

On Wed, Oct 23, 2013 at 7:58 AM, Roberto Peon <[email-masked]> wrote:

> 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

>>>> 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.
>>>>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 23 Oct 2013 08:43:44 -0700

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 <[email-masked]> 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 <
>>>>> On Mon, Oct 21, 2013 at 11:08 AM, Roberto Peon <[email-masked]>wrote:
>>>>>
>>>>>  It seems the XML has older huffman tables, so I got ones in
>>>>> javascript compressor output.
>>>>>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 23 Oct 2013 08:43:07 -0700

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.

-=R

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 24 Oct 2013 01:08:02 +0900

On Thu, Oct 24, 2013 at 12:43 AM, Roberto Peon <[email-masked]> 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

>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 23 Oct 2013 09:09:07 -0700

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
<[email-masked]>wrote:

> 3.1.3 <http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-04#section-3.1.3>.  Reference Set
>
>
>>>> 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 <[email-masked]>wrote:
>>>>>
>>>>>>>> It provides for separate encoding/decoding steps, showing the
>>>>>>>> output (or input, depending) as hex, as well as the state of the table, and

---

From: Andrew Rockwell <[email-masked]>
Date: Wed, 23 Oct 2013 19:51:23 +0000

I didn't follow this answer. My reading of the question was: why are header fields that are present in static table encoded with their literal representations instead of with their indexed representations? Yet the answer seems to only discuss the reference set. Can't static table entries be referred to by their index even if can't be present in the reference set?

Andrew

From: Roberto Peon [mailto:[email-masked]]
Sent: Wednesday, October 23, 2013 8:43 AM
To: Tatsuhiro Tsujikawa
Cc: HTTP Working Group
Subject: Re: Next pre-draft implementation in javascript.

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 <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Oct 23, 2013 at 7:58 AM, Roberto Peon <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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).

On Mon, Oct 21, 2013 at 9:15 AM, Tatsuhiro Tsujikawa <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Oct 21, 2013 at 11:08 AM, Roberto Peon <[email-masked]<mailto:[email-masked]>> 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.

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