RE: Next pre-draft implementation in javascript.

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:grmocg@gmail.com]
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 <tatsuhiro.t@gmail.com<mailto:tatsuhiro.t@gmail.com>> wrote:


On Wed, Oct 23, 2013 at 7:58 AM, Roberto Peon <grmocg@gmail.com<mailto: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<mailto: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<mailto:tatsuhiro.t@gmail.com>> wrote:


On Mon, Oct 21, 2013 at 11:08 AM, Roberto Peon <grmocg@gmail.com<mailto: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