Re: SETTINGS error handling

Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Wed, 17 July 2013 12:19 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAE821F9EB8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jul 2013 05:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1divZaSgkyL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jul 2013 05:18:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 682BB21F9E76 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Jul 2013 05:18:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UzQg2-0002QL-Tp for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Jul 2013 12:17:50 +0000
Resent-Date: Wed, 17 Jul 2013 12:17:50 +0000
Resent-Message-Id: <E1UzQg2-0002QL-Tp@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <tatsuhiro.t@gmail.com>) id 1UzQfv-0002P9-0Z for ietf-http-wg@listhub.w3.org; Wed, 17 Jul 2013 12:17:43 +0000
Received: from mail-ie0-f174.google.com ([209.85.223.174]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <tatsuhiro.t@gmail.com>) id 1UzQft-0000eb-Jc for ietf-http-wg@w3.org; Wed, 17 Jul 2013 12:17:42 +0000
Received: by mail-ie0-f174.google.com with SMTP id 9so3795945iec.5 for <ietf-http-wg@w3.org>; Wed, 17 Jul 2013 05:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EbHQq4qHPNMyK7boo1EXn7eQaBQLGyrUfSHq/aKzHbc=; b=xR+QsEnYCGibNhwifp2HuDb4uHWBKnHNTlkkvMmx8ymC1zrAtNFi9qDCvotiLI8aU6 Gaec94Tm7nIuXy7W0+qEn2i9r5yL0WVjdyP884tdLc4JHe0FUqvleYCnDi8Qj9XNvzwL ilujPdo+EDEzYf5tfptN7B7+YB6KSy6VaCz000X70dxT/EtmTRDVWy4i6qYwOAkYz/4Y yeNtpd+OmGNkFURCoKRjUVvZMm3m4IISytNDyzyER60B1vur0ifjT3e2FOsEaltUqhSV f14ktMWcIm70PdTFNXzJoFO7Vw6+3kSEwcRNy5EIv6hhz3eBBNkPI6MRgnGZzjPRglvJ IE1Q==
X-Received: by 10.50.49.48 with SMTP id r16mr1215004ign.30.1374063435812; Wed, 17 Jul 2013 05:17:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.32.103 with HTTP; Wed, 17 Jul 2013 05:16:55 -0700 (PDT)
In-Reply-To: <CAP+FsNeK4cFuEVhty2oOW+jp-xi4y3tn31n7Q+5FCs_Dn86Oiw@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> <CAP+FsNeK4cFuEVhty2oOW+jp-xi4y3tn31n7Q+5FCs_Dn86Oiw@mail.gmail.com>
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 17 Jul 2013 21:16:55 +0900
Message-ID: <CAPyZ6=L0A56N=+qA5ti=kge0VkK4yRJ_X4nD-NKf5H2_Ehk1bg@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>
Content-Type: multipart/alternative; boundary="047d7bdc1c00fd980b04e1b4128a"
Received-SPF: pass client-ip=209.85.223.174; envelope-from=tatsuhiro.t@gmail.com; helo=mail-ie0-f174.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.710, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UzQft-0000eb-Jc 71b6e919a7e40afee8767c64f752dd4e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: SETTINGS error handling
Archived-At: <http://www.w3.org/mid/CAPyZ6=L0A56N=+qA5ti=kge0VkK4yRJ_X4nD-NKf5H2_Ehk1bg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18822
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Wed, Jul 17, 2013 at 1:31 AM, Roberto Peon <grmocg@gmail.com> wrote:

> 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.
>

I think that is what I was meant to say.


>  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.
>
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
> 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
>>>>
>>>>
>>>