- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 11 Jul 2014 20:23:55 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- cc: Jason Greene <jason.greene@redhat.com>, Greg Wilkins <gregw@intalio.com>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CABkgnnV=zt7bs_0AfydAPfN0_bYbQ4k6qFUxVpZ0qodN5VuLQw@mail.gmail.com>, Martin Thomson w rites: >On 11 July 2014 13:09, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >>>This point: >>>> The current design handles this fairly well, at most one set of headers can >>>> be incomplete at any point in time (sending a large number of incomplete >>>> headers and keeping most of them incomplete most of the time is an >>>> excellent attack vector, which the design currently precludes). >> >> This would be even more the case if we insist, as proposed, that all >> headers go into a single frame. > >You mean that it would help avoid having multiple incomplete header >blocks outstanding. If so, then yes. Knowing size up front means >that you can RST streams that you know will blow your limits (though >with compression, you can't be sure that a smaller frame won't). I mean that if we insist the entire header-set goes into a single frame at most *zero* set of headers can be incomplete at any point in time. -- 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 Friday, 11 July 2014 20:24:20 UTC