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

Re: delta encoding and state management

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 17 Jan 2013 12:25:38 -0800
Message-ID: <CAP+FsNc4NQQo5QCZqJ1VP0uyxhiX=aZhfsGX9K9Yjck-4_PEkg@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Nico Williams <nico@cryptonector.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Correct. :)

On Thu, Jan 17, 2013 at 11:59 AM, James M Snell <jasnell@gmail.com> wrote:

> On Thu, Jan 17, 2013 at 9:56 AM, James M Snell <jasnell@gmail.com> wrote:
>> On Thu, Jan 17, 2013 at 9:49 AM, Nico Williams <nico@cryptonector.com>wrote:
>>> On Thu, Jan 17, 2013 at 11:21 AM, James M Snell <jasnell@gmail.com>
>>> wrote:
>>> > My main concerns with this approach are (a) even tho the decoder gets
>>> to set
>>> > limits on the amount of state used, keeping that state around is still
>>> > relatively expensive compared to what we have now, and (b) keeping it
>>> in
>>> > sync with the client, server and any number of intermediaries along
>>> the path
>>> > is likely going to prove difficult at best. We need to make sure we
>>> have a
>>> > good understanding of the worst case scenario with this approach (i.e.
>>> > nothing stored in context anywhere along the path).
>>> If the compression is hop-by-hop then there's no synchronization
>>> issues.  But then middleboxes may have to decompress and always
>>> re-compress (even if the headers are left unmodified) in each
>>> direction.
>> That's the exact problem I'm having really. Middleboxes will be required
>> to maintain a complete compression state (for requests and responses) as
>> opposed to just passing things through. Maintaining that state could become
>> quite expensive. If we don't maintain it, tho, the potential sync issues
>> become too messy.
> Correction on this (the bits thankfully just kind of snapped together in
> my brain finally)... a middlebox would have separate decompression and
> compression contexts for each request and response and would translate
> between the two. If it receives a kvsto, it can choose not to store
> anything and pass those along as kvsto or eref, getting by without storing
> any of the actual values, but still having to maintain some amount of state
> for the translation to occur. So that part (finally) clicked in my head
> correctly but we still need to make sure we have a solid sense of just how
> expensive maintaining that context is going to be (best and worst cases).
> - James
>>> In general I'd much rather not have connection-oriented state at all,
>>> not even if it were transparent to HTTP.
>> Agreed, not sure how to avoid it and still get good compression (outside
>> of simply optimizing the encoding of values as much as possible... i.e.
>> bohe)
>> - James
>>> Nico
>>> --
Received on Thursday, 17 January 2013 20:26:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 17 January 2013 20:26:17 GMT