Re: SETTINGS error handling

Roberto Peon <grmocg@gmail.com> Tue, 16 July 2013 16:32 UTC

Resent-Date: Tue, 16 Jul 2013 16:31:56 +0000
Resent-Message-Id: <E1Uz8AO-0002Q9-Fa@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <CAP+FsNexmQ40N-imoNYkCSEttYsUqjLzeHr1Yvz-Brp1AfoiMw@mail.gmail.com>
References: <CAOdDvNoPRmM-8hpbrCoQ4GQFJTd0qPjONTyJuF6Pu2UhoyQ_zA@mail.gmail.com> <CABkgnnVretqeOtEFr=9zHbP77UtS4AyA9YfnSVXUNaz5rSytQA@mail.gmail.com> <51E53B00.1090504@treenet.co.nz> <CAPyZ6=J=jumG=+aKyjuDNiB5oVAGEJ7axjQ6-TH3+DvsQGH0NQ@mail.gmail.com> <CAP+FsNexmQ40N-imoNYkCSEttYsUqjLzeHr1Yvz-Brp1AfoiMw@mail.gmail.com>
Date: Tue, 16 Jul 2013 09:31:20 -0700
Message-ID: <CAP+FsNeK4cFuEVhty2oOW+jp-xi4y3tn31n7Q+5FCs_Dn86Oiw@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>
Content-Type: multipart/alternative; boundary="047d7b41c746d1df6404e1a38141"
Received-SPF: pass client-ip=209.85.219.50; envelope-from=grmocg@gmail.com; helo=mail-oa0-f50.google.com
Subject: Re: SETTINGS error handling
Archived-At: <http://www.w3.org/mid/CAP+FsNeK4cFuEVhty2oOW+jp-xi4y3tn31n7Q+5FCs_Dn86Oiw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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
On Jul 16, 2013 9:26 AM, "Roberto Peon" <grmocg@gmail.com> wrote:

> 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" <tatsuhiro.t@gmail.com>
> wrote:
>
>> +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 <squid3@treenet.co.nz>wrote:
>>
>>> On 16/07/2013 10:20 a.m., Martin Thomson wrote:
>>>
>>>> On 15 July 2013 12:44, Patrick McManus <pmcmanus@mozilla.com> wrote:
>>>>
>>>>> I'm wondering why the text proscribes error handling of MUST ignore in
>>>>> 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
>>>>> handling of the error?
>>>>>
>>>> PROTOCOL_ERROR seems appropriate.
>>>>
>>>> Opened:
>>>> https://github.com/http2/**http2-spec/issues/174<https://github.com/http2/http2-spec/issues/174>
>>>>
>>>
>>> +1. And double that for more strictness everywhere.
>>>
>>>
>>> Amos
>>>
>>>
>>

SETTINGS error handling Patrick McManus
Re: SETTINGS error handling Martin Thomson
Re: SETTINGS error handling Amos Jeffries
Re: SETTINGS error handling Tatsuhiro Tsujikawa
Re: SETTINGS error handling Roberto Peon
Re: SETTINGS error handling Roberto Peon
Re: SETTINGS error handling Tatsuhiro Tsujikawa