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

Re: HPACK encoder/decoder memory bounding

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Sat, 26 Oct 2013 09:58:18 +0900
Message-ID: <CAPyZ6=+C24VLDj6mDQsgyBfU_P3OgC5tbf4tfwjKUF20XQYRQA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Osama Mazahir <OSAMAM@microsoft.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Fred Akalin <akalin@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, Hervé Ruellan <ruellan.crf@gmail.com>
A bit related question, when does the sender of SETTINGS apply its change?
Before ACK is introduced, it is applied on transmittion. Now is it when ACK
is received?  It seems so because sender-decoder may use different value of
table size without this which lead currupted decoding. This means that
sender has to keep track of all in-flight SETTINGS.

Best regsrds,
Tatsuhiro Tsujikawa

2013/10/26 3:55 "Martin Thomson" <martin.thomson@gmail.com>:
> On 25 October 2013 11:46, Fred Akalin <akalin@google.com> wrote:
> > I went back and checked the draft and the setting description was
clear; I
> > just glossed over the key phrase '...used to decode header blocks.'
> Actually, I just scanned, and thought that perhaps this might help:
>             Settings are not negotiated.  Settings are sent
> independently by both peers.  Different
>             values for the same setting can be advertised by each
> peer.  For example, a client might
>             set a high initial flow control window, whereas a server
> might set a lower value to
>             conserve resources.
> Also:
>                     Allows the sender to inform the remote endpoint of
> the size of the header
>                     compression table used to decode header blocks.
> The space available for
>                     encoding cannot be changed; it is determined by
> the setting sent by the peer
>                     that receives the header blocks.  The initial
> value is 4096 bytes.
> How does that sound?
Received on Saturday, 26 October 2013 00:58:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC