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


From: Adrian Cole <adrian.f.cole@gmail.com>
Date: Thu, 3 Jul 2014 14:24:40 -0700
Message-ID: <CAHzwyDtM0+st2RtnnG7v+2Aj7FT+K9b0S=LDM5K7TTOM19dPNw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Proposal 4 (remove continuation; add setting for total header frame(s)
length limit) works for me. I know details are pending, but I'm
on-board with the idea.


On Wed, Jul 2, 2014 at 6:16 PM, Mark Nottingham <mnot@mnot.net> wrote:
> On 3 Jul 2014, at 10:55 am, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
>> My preference is (0).
>> (1) adds more complexity just for 0.02% cases.
>> h2 should support > 16k headers so (2) is not an option.
>> (3) may be a candidate but if we can agree now then it is better.
>> So if 0.02% requests really causes a problem, specifically in coalesce scenario, I'd like to suggest that we can add minimum size of compressed header payload size that must be supported.  I choose compressed size because it can be easily computed by payload length.  The default size is 64k.    Receiver can freely respond with 413 within this limit but it has to burn HPACK to decompress headers (and discard them).  It can terminate connection when it encoders more than this limit.
>> Sender should not send header block more than 64k in total in compressed size.  It is possible to roughly estimate upper bound of compressed size without HPACK (encode all new name literal, possible encodong context updates, reference set toggle off at the end).
> Thank you.
> Any thoughts about the subsequent proposal #4?
> http://www.w3.org/mid/23C82249-8187-47A7-ADF0-25A29804085C@redhat.com
> Cheers,
> --
> Mark Nottingham   http://www.mnot.net/
Received on Thursday, 3 July 2014 21:25:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:19 UTC