Re: reserved bit from Flags field | Re: new type number versus repurpose of existing field | … | Re: Setting to disable HTTP/2 Priorities

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Fri, 09 August 2019 11:18 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 6A52A120161 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Aug 2019 04:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 JsrSdfTTTI-l for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Aug 2019 04:18:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2140120162 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 9 Aug 2019 04:18:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hw2s7-00023B-9n for ietf-http-wg-dist@listhub.w3.org; Fri, 09 Aug 2019 11:15:47 +0000
Resent-Date: Fri, 09 Aug 2019 11:15:47 +0000
Resent-Message-Id: <E1hw2s7-00023B-9n@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <hurtta@siilo.fmi.fi>) id 1hw2rv-0001t3-FN for ietf-http-wg@listhub.w3.org; Fri, 09 Aug 2019 11:15:35 +0000
Received: from smtpvgate.fmi.fi ([193.166.223.36]) by mimas.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from <hurtta@siilo.fmi.fi>) id 1hw2rt-0004n1-Ax for ietf-http-wg@w3.org; Fri, 09 Aug 2019 11:15:34 +0000
Received: from souk.fmi.fi (souk.fmi.fi [193.166.211.113]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20181030/smtpVgate) with ESMTP id x79BE7Sm007150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2019 14:14:07 +0300
Received: from shell.siilo.fmi.fi by souk.fmi.fi with ESMTP id x79BE7gB006183 ; Fri, 9 Aug 2019 14:14:07 +0300
Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id x79BE6hx000404 ; Fri, 9 Aug 2019 14:14:06 +0300
Received: by shell.siilo.fmi.fi id x79BE6fC000403; Fri, 9 Aug 2019 14:14:06 +0300
Message-Id: <201908091114.x79BE6fC000403@shell.siilo.fmi.fi>
In-Reply-To: <CALGR9oYvjcAnsYr+ZqxZCSidLbidf5n31pvTTe8NgnQkd5r_Ng@mail.gmail.com>
References: <20190808173909.F07B645B6B@welho-filter4.welho.com> <20190809052701.1C4A4157CD@welho-filter1.welho.com> <CALGR9oYvjcAnsYr+ZqxZCSidLbidf5n31pvTTe8NgnQkd5r_Ng@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 9 Aug 2019 14:14:06 +0300 (EEST)
Sender: hurtta@siilo.fmi.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Matthew Kerwin <matthew@kerwin.net.au>, Brad Lassey <lassey@chromium.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
X-Mailer: ELM [version ME+ 2.5 PLalpha49]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20190809/30643/01
X-Filter: smtpVgate.fmi.fi: ID 30643/01, 1 parts scanned for known viruses
X-Filter: souk.fmi.fi: ID 214287/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Fri, 09 Aug 2019 14:14:09 +0300 (EEST)
Received-SPF: none client-ip=193.166.223.36; envelope-from=hurtta@siilo.fmi.fi; helo=smtpVgate.fmi.fi
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=0.046, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hw2rt-0004n1-Ax dbc807a5818237349d1c8f4938e1cd68
X-Original-To: ietf-http-wg@w3.org
Subject: Re: reserved bit from Flags field | Re: new type number versus repurpose of existing field | =?UTF-8?Q?=E2=80=A6_=7C_Re:_Setting_to_disable?= HTTP/2 Priorities
Archived-At: <https://www.w3.org/mid/201908091114.x79BE6fC000403@shell.siilo.fmi.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36965
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Lucas Pardue <lucaspardue.24.7@gmail.com>;: (Fri Aug  9 13:08:52 2019)
> I'd treat both options as a class of change that RFC 7540 says MUST be
> negotiated:
> 
>    Extensions that could change the semantics of existing protocol
>    components MUST be negotiated before being used.  For example, an
>    extension that changes the layout of the HEADERS frame cannot be used
>    until the peer has given a positive signal that this is acceptable.
> 
> 
> Changing frame flags relies on implementations both understanding the flag
> and its meaning, which is difficult to do in an uncoordinated and robust
> way. For example, adding a field and setting a flag that no one knows to
> check will likely result in extant HEADERS frame parsers detecting a . size
> error, resulting in a connection error. That's pretty high risk.

Yes. Recipient of these changed frames needs send first SETTINGS frame
(for example) which it tells that that change is supported.

Also new type codes for HEADERS and PRIORITY frames need similar negotiation
(because accounting of frames and HPACK is affected; they can not just
ignored as unknwon frame type codes are ignored).
 
> Lucas

/ Kari Hurtta