- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Mon, 24 Nov 2014 09:08:18 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Received on Sunday, 23 November 2014 23:08:46 UTC
On 24 November 2014 at 07:26, Martin Thomson <martin.thomson@gmail.com> wrote: > PROTOCOL_ERROR: > https://github.com/http2/http2-spec/pull/651 > > PROTOCOL_ERROR or REFUSED_STREAM: > https://github.com/http2/http2-spec/pull/652 > > There's two views on this: the zero tolerance extreme who would > probably also choose to treat the stream error as a connection error; > the permissive one who don't like to punish errors more than is > necessary. The full range of views is accommodated by the second PR, > so I prefer that marginally. It still lets implementations fail as > hard as possible. > > I don't follow your discussion; isn't a stream error of type PROTOCOL_ERROR still just a stream error? I don't think it's cool to treat RST_STREAM(PROTOCOL_ERROR) the same as GOAWAY(PROTOCOL_ERROR). That said, I prefer #652. It allows implementations to say: "things are cool, but I didn't read those HEADERS" vs. "stop breaking the protocol you jerk." Depending on how egregious you consider a peer ignoring/exceeding the stream limit. (Is that what you were saying?) -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Sunday, 23 November 2014 23:08:46 UTC