- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Tue, 25 Nov 2014 07:56:17 +1000
- To: brad@danga.com
- Cc: Roberto Peon <grmocg@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
So, back on track... On 24/11/2014, Brad Fitzpatrick <brad@danga.com> wrote: > If the peer has ACKed as many SETTINGS as you've sent, and then proceeds to > violate the latest SETTINGS, it's obvious then that said peer just can't > count (and it wasn't a network latency race). If so, what else can't they > follow the directions of? I'm at least in favor of hanging up on them in > that case. > Are you saying you want it to be a GOAWAY if you're confident the client should know better? As I read the PRs, the question is about what code to put in a RST_STREAM, and as far as I'm aware there's no reasonable way to upgrade RST_STREAM to GOAWAY, and it's pretty rude (or pathological) to FIN without warning or reason. Isn't it counter to interop to send an error signal that isn't prescribed by the spec? We *could* add a bunch more words to get to the Connection Error/Stream Error place, but I don't know if it's worth the extra convolution. Maybe it is, if the words are good ones. -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Monday, 24 November 2014 21:56:46 UTC