Re: Clarify some handling about extension frame and unknown frame on HTTP/2

Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Sat, 21 January 2017 08:27 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 3E89A12998F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 21 Jan 2017 00:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.699
X-Spam-Level:
X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOjpEOjz-53S for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 21 Jan 2017 00:27:16 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBAA12944C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 21 Jan 2017 00:27:16 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cUqxf-0002Cx-LS for ietf-http-wg-dist@listhub.w3.org; Sat, 21 Jan 2017 08:23:47 +0000
Resent-Date: Sat, 21 Jan 2017 08:23:47 +0000
Resent-Message-Id: <E1cUqxf-0002Cx-LS@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tatsuhiro.t@gmail.com>) id 1cUqxb-0002C0-A4 for ietf-http-wg@listhub.w3.org; Sat, 21 Jan 2017 08:23:43 +0000
Received: from mail-qt0-f181.google.com ([209.85.216.181]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <tatsuhiro.t@gmail.com>) id 1cUqxV-0003yE-0d for ietf-http-wg@w3.org; Sat, 21 Jan 2017 08:23:37 +0000
Received: by mail-qt0-f181.google.com with SMTP id v23so65812328qtb.0 for <ietf-http-wg@w3.org>; Sat, 21 Jan 2017 00:23:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CiAwdzxdcX1Ity982U7uNe79qVleI4bJJYvCPrZaU+8=; b=EfgrQ31ZI+4s9XCtgktZSrtkT4pal2IZP5cw+ViUZ+6rLBiS2Qg0+HgDg4jk+XJoan +VVAnW/z5sOsZ71qohH3zUiog76ZZOXnVpqfpJ4Q4KToJo463UuyDI2lgkfBDbcBKetU /9mbLOPZjVA/151hEXlRHdLnOdFTrsmxlGj3O5e9/a/f7rBDoid9+3Uky1zqiOfskVfm 92bZkvzMRV7tvEpxx/UlUqZ7UZX6/4Y4JM3EYVAWtkj5AsIDaiqkX0539mojSEgktQa8 QmUm/22gvpDHG972ZogzK4+5TknpLLB2SAhN4VwVfMUxWzRnpSL+TcLgGu2yq71OYXXy CgWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CiAwdzxdcX1Ity982U7uNe79qVleI4bJJYvCPrZaU+8=; b=XY7PX+H2U14f4Mi2cW9WExzZhkbDurR8bsoWK7tKlU5wh1ZRQxKhPcv4ZYNfSJWXmI zrX8VyDk1uHG3Q3gWbLhtJB1jz/Vh5DZfv+4RYkt2kWm3yQJiA1XJoMggnYEdPbl87A/ 5LntTYzaqJOgrj1JfWNap98agUFPwSse3we0SgzvCHc60ugVplVG20rrvOUxm20YWFyD t4Pmdhg5rOeMjHNISsCCECH5x7hWv4DuW7S15h62/QGI1BAZvEcq/u7YmttzO/znlBEf gPVsa/sVWUzp4XIMXERr3CyJmqq8jkjC7zbFa1HaDH3uCqbpkw+O1ptO/VSSVvBJgKnp qPoQ==
X-Gm-Message-State: AIkVDXJFfJQIS1w2j6MnucXY+3E9qHmNsnxiaD+yrMqypZmGw/gApxug/f63DtcwnjSqzTnijri6Ey7eernjYg==
X-Received: by 10.200.42.200 with SMTP id c8mr16146887qta.156.1484986991266; Sat, 21 Jan 2017 00:23:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.138.186 with HTTP; Sat, 21 Jan 2017 00:22:50 -0800 (PST)
In-Reply-To: <CAJ8AU98EXyOzg2a6Oj+7hk=Dysqse_zhunjpcoCU-FO9djjDqw@mail.gmail.com>
References: <CAJ8AU98EXyOzg2a6Oj+7hk=Dysqse_zhunjpcoCU-FO9djjDqw@mail.gmail.com>
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Sat, 21 Jan 2017 17:22:50 +0900
Message-ID: <CAPyZ6=KXrzUSBrb4S5oN12m2w_ZEk8p+6aqpSv9o6WusP5RqRw@mail.gmail.com>
To: =?UTF-8?B?6JWt6ZuL5ra1?= <chhsiao90@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a1140058e1c586a0546967aa1
Received-SPF: pass client-ip=209.85.216.181; envelope-from=tatsuhiro.t@gmail.com; helo=mail-qt0-f181.google.com
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-0.998, BAYES_00=-1.9, 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cUqxV-0003yE-0d 2842eadcab202896ad1356d5a81c4c8c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Clarify some handling about extension frame and unknown frame on HTTP/2
Archived-At: <http://www.w3.org/mid/CAPyZ6=KXrzUSBrb4S5oN12m2w_ZEk8p+6aqpSv9o6WusP5RqRw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33351
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>

Hi,

On Sat, Jan 21, 2017 at 1:02 PM, 蕭雋涵 <chhsiao90@gmail.com> wrote:

> It's related to https://tools.ietf.org/html/rfc7540#section-5.5 Extending
> HTTP/2 and a test case for it https://github.com/
> summerwind/h2spec/blob/master/5_5.go#L75-L102
>
> The fourth paragraph said
>
>> Implementations MUST ignore unknown or unsupported values in all
>> extensible protocol elements. Implementations MUST discard frames
>> that have unknown or unsupported types.
>
>
> and it also said
>
>> extension frames that appear in the middle of a header block are not
>> permitted;
>> these MUST be treated as a connection error of type PROTOCOL_ERROR.
>
>
> So when one end point received one unknown frame in the middle of header
> block,
> I'm not sure what's the correct way to handle the frame with following two
> options.
> - the end point should drop the frame without any error
> - the end point should close the connection with protocol error.
>
> There is also one paragraph related to this that support the first option.
> https://tools.ietf.org/html/rfc7540#section-5.1
> at second from the last paragraph
>
>> In the absence of more specific guidance elsewhere in this document,
>> implementations SHOULD treat the receipt of a frame that is not
>> expressly permitted in the description of a state as a connection
>> error of type PROTOCOL_ERROR. Note that PRIORITY can
>> be sent and received in any stream state. Frames of unknown types
>> are ignored.
>
> That said frames of unknown types should ignore and not treat as protocol
> error.
>
> So I think each the option make sense to me, and want to clarify for which
> would be the best option.
>
>
​My understanding is that unknown frame type must be ignored except for
those which are received in the middle of header block.   The unknown frame
type appearing in the middle of header block must be treated as connection
error.

​Best regards,
Tatsuhiro Tsujikawa​





> Thanks
>