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


From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Sat, 19 Oct 2013 18:08:12 +0900
Message-ID: <CAPyZ6=Lh0_DdQznTR=2uvtz1APk1P0OcMPZBL=f4dO8qT1Zyxw@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Oct 19, 2013 at 12:48 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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

I did experimented it and surprisingly, it does not harm and instead it
slightly improves the compression for the 4 data set in http_samples repo.

If we are going to add more headers to static tables, it might be safe to
keep dynamic table to the front.

The required steps for an encoder to use partial memory after usual
eviction steps will look like this:

HEADER_TABLE_SIZE : <size which remote decoder chosen>
LOCAL_HEADER_TABLE_SIZE : <size which local encoder chosen,
                           less than or equal to HEADER_TABLE_SIZE>

local_table_len : <the number of header entries in header table, whose
                   capacity is strictly less than or equal to
                   LOCAL_HEADER_TABLE_SIZE limit>

local_table_bufsize : <the buffer size in LOCAL_HEADER_TABLE_SIZE
                       which is calculated independent of whole table
                       buffer size.>

# Free up resources encoder does not want to pay and manage reference set
# state as necessary.
for i in range(local_table_len - 1, -1, -1):
    if local_table_bufsize + header_space(new_header)
              <= LOCAL_HEADER_TABLE_SIZE:
    entry = table_get_entry(i)
    if reference_set_contains(entry):
        if entry.implied:
            # emit impiled header explicitly
            entry.implied = False
        # Toggle off from the reference set in the remote
    local_table_bufsize -= 32 + entry.name_len + entry.value_len
    local_table_len -= 1
    free_name_value(entry) # Do your memory management if they are
                           # from somewhere

if local_table_bufsize < header_space(new_header):
    entry = create_entry_without_allocate_name_value(new_header)
    emit_index_repr(0) # Toggle off from reference set in the remote
    entry = create_entry(new_header)
    local_table_bufsize += 32 + entry.name_len + entry.value_len
    local_table_len += 1

The tricky part is that encoder requires another care about reference set
synchronization. Without proper treatment, they are leaked to the successive
header set.

Best regards,
Tatsuhiro Tsujikawa

> 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 09:08:59 UTC

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