Re: Options for CONTINUATION-related issues

On Wed, Jul 16, 2014 at 10:54 PM, Mark Nottingham <mnot@mnot.net> wrote:

> From there:
>
> """
>         • Remove the CONTINUATION frames.
>         • Remove priority fields from the HEADERS frame, as these can be
> sent in a separate PRIORITY frame without concerns of fragmentation.
>         • Deduct the HEADER frame sizes from the flow control window
> sizes, but do not block header frames due to flow control.
>         • If it is desired to declare a maximum header size (for 551),
> then add a SETTINGS_MAX_HEADER_SIZE expressed in uncompressed bytes
>         • Remove the header block fragment from the PUSH_PROMISE frame.
> Instead send the headers in a HEADERS+ frame sequence following the
> PUSH_PROMISE frame.
> """
>
> That touches many parts of the spec, introducing the opportunity for
> potentially many new interoperability problems.
>
> But let's cut to the chase. Would any of our current implementers consider
> trying this out?


I'm not at all interested in trying this out. As I see it, it solves no
issues, and in fact introduces new ones (the ability to unintentionally
starve oneself of flow control when something has caused you to send a lot
of headers, quite likely out of your own control). The arguments keep seem
to be boiling down to "I don't like CONTINUATION, so let's find some reason
to get rid of it".

Another issue is this: I have large headers to send. How do I inform my
peer of that, assuming they have advertised a smaller frame size? I can't.
Even worse: someone has large headers to send to me (lots of set-cookie, or
a kerberos token). I don't want frames larger than 16k in any case, as it
hurts the muxing and prioritization. I'm either stuck not being able to
talk to that peer (bad) or I have to open myself up to really bad muxing
and prioritization (also bad).

Nope, none of those eventualities sound good. In fact, it sounds more like
we're either (1) ensuring a lot of situations where interop won't exist, or
(2) forcing everyone to accept large frames (which plenty of us have
already said we won't do). This is not the way to make a working,
interoperable protocol.
--
Peace,
  -Nick