- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 24 Nov 2014 07:24:38 +0100
- To: Roberto Peon <grmocg@gmail.com>
- Cc: brad@danga.com, Matthew Kerwin <matthew@kerwin.net.au>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Nov 23, 2014 at 08:07:45PM -0800, Roberto Peon wrote: > Yup, modulo the lack of knowledge on the first RT or so... There's another case where network latency adds some uncertainty : when clients abort some streams from time to time and consider they can immediately open a new one as a replacement (the stop button or Ctrl-F5). It is possible that for internal scheduling reasons or flow control in the client, the abort is sent after the new stream is presented, and that from time to time a new stream is rejected. It would cause some interop issues to break the whole connection when this happens, and the resulting effect will certainly be that clients will be more careful and will ensure never to reach the limit. In parallel I agree for being strict. I think it can make sense to consider that whatever exceed the configured limit ends up with RST_STREAM and that a GOAWAY happens if "too many" consecutive RST_STREAM have to be sent, or when the hard limit is significantly passed over (eg: 10% more or double etc). At least clients must know that there's a risk of getting a GOAWAY if they do not respect the rules so that they are carefully implemented. Willy
Received on Monday, 24 November 2014 06:25:17 UTC