But it does not remove the continuation 'kludge'. It substitutes one
'kludge' for another 'kludge' and doesn't change the orthogonal requirement
to handle arbitrarily large headers...
Continuation has the advantage of being a known annoyance.
There have been proposals for requiring that CONTINUATION (and similar
non-stream-initiating-HEADERS frames) carry only non-state-modifying data,
in which case many of the annoyances w.r.t. continuation go away.
I'd prefer investigation into avenues like that, personally.
Jumbo frames have the disadvantage of folks not realizing the harm they
cause, and then causing it anyway.
-=R
On Wed, Jun 25, 2014 at 2:04 PM, <K.Morgan@iaea.org> wrote:
> On 25 June 2014 22:22, grmocg@gmail.com wrote:
> > The sender determines how to apportion data into frames.
> > We were seeing whole files transmitted as a single frame.
> > -=R
>
> The sender can only apportion data into frames less than
> SETTINGS_MAX_FRAME length; and if you never change it, he has to use 16K or
> less.
>
> This is exactly the point. The jumbo frames eliminates the CONTINUATION
> "kludge" & allows use cases which need jumbo frames to have them if the
> peer gives consent. All while not preventing efficient muxing with 16K
> frames.
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>