Re: Framing and control-frame continuations

Why would I like it if the new and supposedly better stuff is worse with
naive implementations, given that a requirement for a smaller frame size
would likely do a good job of preventing the sucking in the first place? :)

This problem isn't theoretical, by the way-- we've seen it in the wild. It
is something which, unless one stops to think, one won't realize why it
would cause a problem, but that doesn't stop it from doing so.

-=R


On Wed, Feb 6, 2013 at 12:21 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <CAP+FsNdvAwThsTfp1FATETABT=fVP0pPOYkei2hWQh8Ys=
> RiWw@mail.gmail.com>
> , Roberto Peon writes:
>
> >Unfortunately, by the time the reciever sees the frame the damage is
> likely
> >already done.  As a result of sending a large frame, the session may back
> >up and prevent other data from being sent on other streams either
> >successfully, or without undue delay.
>
> And who gets a problem ?
>
> If a browser does this, its user exeperience suckage.
>
> If a webservers does this, the webserver will appear sucky to people
> visiting it.
>
> What's not to like about that ?
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>