W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Framing and control-frame continuations

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 6 Feb 2013 12:14:28 -0800
Message-ID: <CAP+FsNdvAwThsTfp1FATETABT=fVP0pPOYkei2hWQh8Ys=RiWw@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: James M Snell <jasnell@gmail.com>, Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
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.

Essentially, the receiver not being DoS'd is the smaller of the problems
here-- the sender causing random, unnecessary HoL blocking/contention and
not effectively being able to switch to using the TCP channel for higher
importance data is the bigger issue, coupled with the likelihood of
exercising all of the code regularly (and if you don't think that is an
issue, try using the not-regularly-sent parts of HTTP/1.0 and see if it is
successful on many implementations...)


On Wed, Feb 6, 2013 at 11:23 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <CABP7Rbdv-zuAg3=O6oHRqJY0=
> xBYsBZ7kQpV0cqjePjk3+O2EA@mail.gmail.com>
> , James M Snell writes:
> >flow (honestly, I think allowing 32-bit
> >length control frames is just asking for trouble by encouraging bad
> >behavior).
> The important thing is that you have to announce your bad behaviour
> up front, that makes it very easy to deal with it on the receiving end.
> --
> 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.
Received on Wednesday, 6 February 2013 20:14:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC