Return-Path: 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 22E5D21F9C41 for ; Tue, 16 Jul 2013 08:34:46 -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 LTt8E9jeCupY for ; Tue, 16 Jul 2013 08:34:41 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AB96F21F9D62 for ; Tue, 16 Jul 2013 08:34:40 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1Uz7Fa-0002Se-Rl for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Jul 2013 15:33:14 +0000 Resent-Date: Tue, 16 Jul 2013 15:33:14 +0000 Resent-Message-Id: Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1Uz7FS-0002Rj-TV for ietf-http-wg@listhub.w3.org; Tue, 16 Jul 2013 15:33:06 +0000 Received: from mail-ie0-f169.google.com ([209.85.223.169]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1Uz7FK-0000yZ-Eq for ietf-http-wg@w3.org; Tue, 16 Jul 2013 15:33:06 +0000 Received: by mail-ie0-f169.google.com with SMTP id 10so1980869ied.0 for ; Tue, 16 Jul 2013 08:32:31 -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=575tc/D+qPJZ74R+DerhzgNW2lLDZ33Rw2YczWqZKoA=; b=Y95idgMC4/6WJtehuLMhRzXan5P+SH12Xr9YAdBsGevH8zW4JYp6vxS/6MtlWeMURx /U0mmWCZ+BHA4OQWiGCDqZfZ/WYuVlOQisrBudYi2mnSe3SbuNatrIRt/9mvpe6kO608 igaii3cVJl9rjeqvLeGhB2/6CxdYglsqwVHE413WUO0fO/E547Pt27kzzpQA3hbjFyZs 5FtU1DRNt30PNkn8vSZ5PttspQlSg58C0TE7ogagEhVWJWyVyqKD6ZSBucFr2pMqlQQQ V+GEUde8vN/NEG+wbeJ5gXOvC+rt78IwkVkAFRwHTBxWhQw3CgD1ncquNXAGPcgJKGLE vIMg== X-Received: by 10.42.76.5 with SMTP id c5mr1293550ick.91.1373988751814; Tue, 16 Jul 2013 08:32:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.103 with HTTP; Tue, 16 Jul 2013 08:32:11 -0700 (PDT) In-Reply-To: <51E53B00.1090504@treenet.co.nz> References: <51E53B00.1090504@treenet.co.nz> From: Tatsuhiro Tsujikawa Date: Wed, 17 Jul 2013 00:32:11 +0900 Message-ID: To: Amos Jeffries Cc: "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary=90e6ba3fcee17a37cf04e1a2afba Received-SPF: pass client-ip=209.85.223.169; envelope-from=tatsuhiro.t@gmail.com; helo=mail-ie0-f169.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 1Uz7FK-0000yZ-Eq ebb0ad54bdb4493e4098da44faad4fb0 X-Original-To: ietf-http-wg@w3.org Subject: Re: SETTINGS error handling Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/18810 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --90e6ba3fcee17a37cf04e1a2afba Content-Type: text/plain; charset=ISO-8859-1 +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 wrote: > On 16/07/2013 10:20 a.m., Martin Thomson wrote: > >> On 15 July 2013 12:44, Patrick McManus 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 >> > > +1. And double that for more strictness everywhere. > > > Amos > > --90e6ba3fcee17a37cf04e1a2afba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 for strict validation.

Regardi= ng validation for SETTINGS, how about validating the values in SETTINGS fra= me?

For example, the value in SETTINGS has unsigned 32 b= it and it means=A0SETTINGS_I= NITIAL_WINDOW_SIZE
could have, say, 2^31, which is invalid for fl= ow control.
WINDOW_UPDATE frame, it must be responded with=A0FLOW_CONTROL_ERROR.
But it does not say about S= ETTINGS frame for invalid window size (it may infer that but still).=
I think it would be goo= d to add some error handling of values on SETTINGS frame reception.<= br>
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<= br> 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<= br> handling of the error?
PROTOCOL_ERROR seems appropriate.

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

+1. And double that for more strictness everywhere.


Amos


--90e6ba3fcee17a37cf04e1a2afba--