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


From: Nicholas Hurley <hurley@todesschaf.org>
Date: Thu, 3 Jul 2014 15:22:05 -0700
Message-ID: <CANV5PPVkhx3NNcp0Td=Z+Xi3TL_0iEkabxChNE9z+tSgik78gg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Adrian Cole <adrian.f.cole@gmail.com>, IETF HTTP WG <ietf-http-wg@w3.org>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
I could get behind the idea of mandating a full HEADERS frame before
sending a CONTINUATION. However, I don't want the setting. People are going
to set whatever they want for their max compressed header block size (note:
NOT frame size, I still want continuation if I'm talking to an endpoint
that allows > 16k). They're going to set a limit even without this change
to the spec. If there is any header block that exceeds that limit, the
connection will most likely be failed anyway. No sense in negotiating a
setting when you can just send a GOAWAY in the exceedingly rare
pathological case.

On Jul 3, 2014 2:38 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> On 3 July 2014 14:24, Adrian Cole <adrian.f.cole@gmail.com> wrote:
> > 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.
> To be clear, I believe that proposal 4 is two things:
> 1. A setting that describes the maximum permissible compressed size of
> a header block (default 16K)
> 2. A mandate to fill all frames carrying header block fragments if
> they are followed by a CONTINUATION
> In the normal case, this would mean that an implementation could avoid
> even implementing CONTINUATION.
> That is, if we get this right and say that padding can be used to fill
> the frame, otherwise we're back in the poop.
Received on Thursday, 3 July 2014 22:22:31 UTC

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