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

Re: SETTINGS_HEADER_TABLE_SIZE and ACK

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 18 Oct 2013 20:48:31 -0700
Message-ID: <CAP+FsNcT+62ePR7WUHtk2ZDfdqq08m1ETV2mBbsbteWTKjp_Ng@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, HTTP Working Group <ietf-http-wg@w3.org>
That would harm the resultant output size, potentially a fair bit, since we
should expect that the dynamic table entries are more likely to be
referenced, they should be lower in the address space.
-=R


On Fri, Oct 18, 2013 at 7:25 PM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com>wrote:

> How about put static table before dynamic table. Then encoder does not
> need to track the size of the entry beyond its boundary. It still needs to
> take care reference set toggle though.
>
> Best regards,
> Tatsuhiro Tsujikawa
>
> 2013/10/19 1:53 "Martin Thomson" <martin.thomson@gmail.com>:
>
> >
> > On 18 October 2013 09:23, Roberto Peon <grmocg@gmail.com> wrote:
> > > How about an implementation considerations section where we talk about
> how
> > > implementations might leverage the spec in various scenarios?
> >
> > I think that it's more than that.  An encoder doesn't have to track
> > the entire table, but they do need to track sizes if they ever intend
> > to use the static table.  As long as they don't intend to reuse the
> > entries, then they don't have to keep the actual values.  An encoder
> > doesn't need to track entry sizes unless they want to use the static
> > table.
> >
> > I think that's the only consequences to this for an encoder.  The cost
> > to the encoder is pitifully small when compared to the work and
> > commitment required by a decoder.  Just make a note of this and move
> > on.
>
>
Received on Saturday, 19 October 2013 03:48:58 UTC

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