Re: Clarify some handling about extension frame and unknown frame on HTTP/2
Cory Benfield <cory@lukasa.co.uk> Sat, 21 January 2017 13:55 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 07C39129A32 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 21 Jan 2017 05:55:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=lukasa-co-uk.20150623.gappssmtp.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 8AoC9YVy88Ag for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 21 Jan 2017 05:55:11 -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 85A01129A2D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 21 Jan 2017 05:55:11 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cUw4g-0003XO-5g for ietf-http-wg-dist@listhub.w3.org; Sat, 21 Jan 2017 13:51:22 +0000
Resent-Date: Sat, 21 Jan 2017 13:51:22 +0000
Resent-Message-Id: <E1cUw4g-0003XO-5g@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1cUw4b-0003WX-7X for ietf-http-wg@listhub.w3.org; Sat, 21 Jan 2017 13:51:17 +0000
Received: from mail-wm0-f54.google.com ([74.125.82.54]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <cory@lukasa.co.uk>) id 1cUw4V-0006sO-3K for ietf-http-wg@w3.org; Sat, 21 Jan 2017 13:51:11 +0000
Received: by mail-wm0-f54.google.com with SMTP id r144so85964338wme.1 for <ietf-http-wg@w3.org>; Sat, 21 Jan 2017 05:50:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QNdd4ZAvlitMLNrEGiobe856XrcbcNgx+OXomFjDKKk=; b=ggmiqiQ5ZJ93+0Elkiwv8yWFQSd/VL3KDv5yMjZCHeVa2JL5klzHmzXZua4REkEVuT KjFfbWbq1F3U3lKChqERcaiI37txQNcjtjtlq4BeprFXXg40sKfjqh9ZRoAQSLbSG/1c ydyVS633YVDQ+K3yWYZuLGS1ntR3CkSvh643uY+tFyl0URrxc3XjLfK7V0kxKG2CEifi Vx+vd+pv77v3z5r06tKNpQGrT3tf04OdHM9B+58J++jnGDXNQgp3vkz9z0widRE51MkG KCkQ5NPEg0lEDwGsRXvVgiJ5dO6CLckXD5NCrPfIFIIh0VWARqL8C07uAR5bySF2mdko foJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QNdd4ZAvlitMLNrEGiobe856XrcbcNgx+OXomFjDKKk=; b=q6wH4UtA+swTmywcGOCnZLT+CoIdG3p29GhNmAcb5JpAdUmmPeVTHmT/Nl5dYBklMT 9O7kPhWZkfzBFSjtb1T/HuPn3lrvFdPlSyGfCm4nMUqY2sKf7e0X0nCEBblUV+iWoiqG P/jOXBvSpgHWiC+nCr6tgLkT4WNzzLlehgEH8lIkmjURvpjLPeMlOxRdTklMJeMPjpa1 4IUAF/WmWxMQoxOSuAVeDzS7ZLEhPXC0PAmNofwchy/KKAVqmoEwRadgkWIYYtyz8cd3 HC9+HJ1/zXISM/hOLN9t7F5PEjuLl+lzX3XvfrgNITgx76fDc2MZm5z0lwQ1F03MA0oE JAug==
X-Gm-Message-State: AIkVDXLIIWAVebD++h6x5NPte8pHCNZTAgC23SJf2x+dFNTe6Y0VfxyOSbBXN9W//3VsQA==
X-Received: by 10.28.214.144 with SMTP id n138mr6781874wmg.136.1485006643643; Sat, 21 Jan 2017 05:50:43 -0800 (PST)
Received: from [192.168.1.3] (227.71.125.91.dyn.plus.net. [91.125.71.227]) by smtp.gmail.com with ESMTPSA id o143sm11072076wmd.3.2017.01.21.05.50.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jan 2017 05:50:42 -0800 (PST)
From: Cory Benfield <cory@lukasa.co.uk>
Message-Id: <AE2DAED4-7938-419C-B97B-4759D469214A@lukasa.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DCA11BC7-4CC5-439A-B58C-20DB3625AAE9"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Sat, 21 Jan 2017 13:50:41 +0000
In-Reply-To: <CAPyZ6=KXrzUSBrb4S5oN12m2w_ZEk8p+6aqpSv9o6WusP5RqRw@mail.gmail.com>
Cc: 蕭雋涵 <chhsiao90@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
References: <CAJ8AU98EXyOzg2a6Oj+7hk=Dysqse_zhunjpcoCU-FO9djjDqw@mail.gmail.com> <CAPyZ6=KXrzUSBrb4S5oN12m2w_ZEk8p+6aqpSv9o6WusP5RqRw@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
Received-SPF: pass client-ip=74.125.82.54; envelope-from=cory@lukasa.co.uk; helo=mail-wm0-f54.google.com
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-0.157, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: mimas.w3.org 1cUw4V-0006sO-3K 3b9d69f09ea608b979d651776b2098f2
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/AE2DAED4-7938-419C-B97B-4759D469214A@lukasa.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33352
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 21 Jan 2017, at 08:22, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote: > > 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. This is correct. A header block must always be a HEADERS frame, followed by zero or more CONTINUATION frames until one of these frames is marked with the END_HEADERS. If an unknown frame appears in that sequence, that violates the HEADERS rules, and so is a connection error. Cory