W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Getting to Consensus: CONTINUATION-related issues

From: Nicholas Hurley <hurley@todesschaf.org>
Date: Fri, 18 Jul 2014 11:01:03 -0700
Message-Id: <1405706463.6499.143191413.55FB2228@webmail.messagingengine.com>
To: Jason Greene <jason.greene@redhat.com>, Martin Thomson <martin.thomson@gmail.com>
Cc: Michael Sweet <msweet@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Jul 18, 2014, at 10:57, Jason Greene wrote:
> 
> On Jul 18, 2014, at 12:17 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> 
> > On 18 July 2014 10:07, Michael Sweet <msweet@apple.com> wrote:
> >> Nothing has been said about a required rollback capability, and I can't find any mention of rollback on the linked wiki page either.
> > 
> > Say you have a block of headers that you need to encode for sending.
> > You discover that you exceed the limit only after performing the
> > encoding up to the point that you exceed the limit.  At that point,
> > you can't send the block.  And all the changes that have been applied
> > to the header table need to be backed out.
> 
> Right so to address this you would need to check if the uncompressed size
> > compressed limit, and if so either do a first pass length compute or a
> temporary copy of the state table. 


Yep, and as I indicated in my email, that is an unacceptable tradeoff on
mobile (the tradeoff is the same as implementing a rollback mechanism).
That's effectively asking me to DOUBLE my state commitment; not a sane
thing to ask.

> It’s extra complexity, but the implementation isn’t difficult (a cake
> walk compared to other aspects of the spec). I can certainly appreciate
> the perspective from implementations that don’t want to touch their code
> though.
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 


-- 
Peace,
  -Nick
Received on Friday, 18 July 2014 18:01:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC