- From: Nicholas Hurley <hurley@todesschaf.org>
- Date: Fri, 18 Jul 2014 11:01:03 -0700
- 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