- From: Jason Greene <jason.greene@redhat.com>
- Date: Sat, 28 Jun 2014 15:48:08 -0500
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Greg Wilkins <gregw@intalio.com>, Willy Tarreau <w@1wt.eu>, Patrick McManus <pmcmanus@mozilla.com>, Johnny Graettinger <jgraettinger@chromium.org>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Mark Nottingham <mnot@mnot.net>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Jun 28, 2014, at 3:38 PM, Jason Greene <jason.greene@redhat.com> wrote: > > On Jun 28, 2014, at 2:48 PM, Roberto Peon <grmocg@gmail.com> wrote: > >> If you're concerned that headers are being sent a byte-at-a-time (slowloris style), then you could do that with a regular headers frame anyway. >> If you're concerned that the overhead of frames is blowing up the bandwidth, then that could happen with PING, SETTINGS, DATA, etc. and is not unique to HEADERS or HEADERS processing. >> It is also point-to-point, and so any non-malicious client should be unaffected by malicious clients. >> >> The requirement to send END_HEADERS unless it is at max size adds a DoS vector because it makes it impossible for a proxy to forward anything or send anything until it has buffered the entire HEADERS, even when it has all of the information necessary to figure out to which server it should forward. >> >> It is better to allow a proxy to forward data if it can. > > True, although if it does that the HOL blocking will force it to buffer all the other streams, so its not reliably helpful to break things up like that (forgot to say assuming coalescing) -Jason
Received on Saturday, 28 June 2014 20:49:04 UTC