Subject: SETTINGS error handling

From: Patrick McManus <[email-masked]>
Date: Mon, 15 Jul 2013 15:44:24 -0400

Section 6.5
   single SETTINGS frame MUST NOT contain multiple values for the same
   ID.  If the receiver of a SETTINGS frame discovers multiple values
   for the same ID, it MUST ignore all values for that ID except the
   first one.

I'm wondering why the text proscribes error handling of MUST ignore in
response to violation of the MUST NOT send provision. I'd rather my
implementation be strict and enforce the MUST NOT send via PROTOCOL ERROR
when receiving this. The kindler gentler days of being liberal in what we
receive have sailed. There is not yet an argument for backwards
compatibility to not do that, but if I did so I would also be in non
compliance.

Can we either change it to PROTOCOL ERROR (preferred) or just be silent on
handling of the error?

-Patrick

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jul 2013 15:20:30 -0700

On 15 July 2013 12:44, Patrick McManus <[email-masked]> wrote:
> response to violation of the MUST NOT send provision.

I think that someone either caught Postel's DIsease, or is in remission.

> Can we either change it to PROTOCOL ERROR (preferred) or just be silent on

PROTOCOL_ERROR seems appropriate.

Opened:
https://github.com/http2/http2-spec/issues/174

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 17 Jul 2013 00:22:24 +1200

> https://github.com/http2/http2-spec/issues/174

+1. And double that for more strictness everywhere.

Amos

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 17 Jul 2013 00:32:11 +0900

+1 for strict validation.

Regarding validation for SETTINGS, how about validating the values in
SETTINGS frame?

For example, the value in SETTINGS has unsigned 32 bit and it means
SETTINGS_INITIAL_WINDOW_SIZE
could have, say, 2^31, which is invalid for flow control.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#section-6.9.1 says
if such value is received in
WINDOW_UPDATE frame, it must be responded with FLOW_CONTROL_ERROR.
But it does not say about SETTINGS frame for invalid window size (it may
infer that but still).
I think it would be good to add some error handling of values on SETTINGS
frame reception.

Best regards,

Tatsuhiro Tsujikawa

On Tue, Jul 16, 2013 at 9:22 PM, Amos Jeffries <[email-masked]> wrote:

>> https://github.com/http2/**http2-spec/issues/174<https://github.com/http2/http2-spec/issues/174>
>>
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 16 Jul 2013 09:26:48 -0700

I think that knowledge client-side of things like that is unwarranted
complexity -- the server must sanity check that data anyway to deal with
malicious clients, or, in the case of port-80 checksum "failures" which
have allowed corrupted bits through.

-=R
On Jul 16, 2013 8:35 AM, "Tatsuhiro Tsujikawa" <[email-masked]>
wrote:

> On Tue, Jul 16, 2013 at 9:22 PM, Amos Jeffries <[email-masked]>wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 16 Jul 2013 09:31:20 -0700

Clarification:
If you were meaning to say that the server/client should close the
connection, etc. upon receipt of bad settings, then I wholly agree.

The client shouldn't bother to validate data that it won't interpret,
however, which is what I was saying very poorly in the last email.

-=R

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 17 Jul 2013 21:16:55 +0900

> connection, etc. upon receipt of bad settings, then I wholly agree.

I think that is what I was meant to say.

> however, which is what I was saying very poorly in the last email.
Yes, the current spec says this about unknown settings. The point is flow
control window size affects the interactions between client and server,
clearly misinterpreting it will lead to deadlock situation. So it should be
validated and if it is bad, then tear down the connection.

Best regards,

Tatsuhiro Tsujikawa

-=R
>>> I think it would be good to add some error handling of values on
>>> SETTINGS frame reception.
>>>
>>> Best regards,
>>>
>>> Tatsuhiro Tsujikawa
>>>
>>>