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

Re: HPACK encoder/decoder memory bounding

From: Roberto Peon <grmocg@gmail.com>
Date: Sat, 26 Oct 2013 09:17:34 -0700
Message-ID: <CAP+FsNfrNJ+n-ftL3DBwcKds2zFa506w03H8ePE8vYFBHtik6w@mail.gmail.com>
To: Fred Akalin <akalin@google.com>
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Osama Mazahir <OSAMAM@microsoft.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>, Hervé Ruellan <ruellan.crf@gmail.com>
Correct .

The decoder always gets to request an encoder size change, and as soon as
the request change as taken effect at the encoder, an ACK is inserted into
the outgoing stream.

The decoder may then allocate/deallocate state (depending on the direction
of the change, upwards vs downwards) when it receives the ACK.
-=R


On Fri, Oct 25, 2013 at 11:19 PM, Fred Akalin <akalin@google.com> wrote:

> As I understand it, it applies it when the ACK is received; that was one
> of the reasons to introduce the ACK.
>
>
> On Fri, Oct 25, 2013 at 5:58 PM, Tatsuhiro Tsujikawa <
> tatsuhiro.t@gmail.com> wrote:
>
>> 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:
>> >
>> >    SETTINGS_HEADER_TABLE_SIZE:
>> >                     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 16:18:01 UTC

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