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