- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 18 Jul 2014 12:57:57 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Michael Sweet <msweet@apple.com>, Nicholas Hurley <hurley@todesschaf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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. 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
Received on Friday, 18 July 2014 17:58:30 UTC