Re: #541: CONTINUATION

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.

Peace,
  -Nick
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.
>
>