- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 12 Jul 2013 08:51:19 -0700
- To: Gábor Molnár <gabor.molnar@sch.bme.hu>
- Cc: Mike Belshe <mike@belshe.com>, Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
On 12 July 2013 02:46, Gábor Molnár <gabor.molnar@sch.bme.hu> wrote: > The problem is that there's a DoS vector here. While sending the HEADERS > frames on the upstream connection, there must not be anything else sent > there. Now suppose a client is very slow, for example, it waits one second > between sending the first and the second (last) HEADERS frame to the proxy. > During this time (which can be arbitrary large), the proxy cannot send > anything on its upstream connection (and it cannot create a new connection > as it's forbidden in the current spec), so it's basically is blocked. So don't do that then. If you have to have two headers frames, then we simply don't create a restriction like the current one whereby both have to appear in immediate succession. As has been suggested, if routing information is important, we can conceive of ways to ensure that it appears first. That doesn't necessarily constrain the rest of the design. And existing constraints are a product of the existing design. A changed design necessarily creates new constraints.
Received on Friday, 12 July 2013 15:51:46 UTC