RE: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities

Mike Bishop <mbishop@evequefou.be> Tue, 13 August 2019 18:52 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 2444F12082A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 13 Aug 2019 11:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 gTWYudntKaEY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 13 Aug 2019 11:51:58 -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 8E211120819 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 13 Aug 2019 11:51:58 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hxbrD-0000xr-FY for ietf-http-wg-dist@listhub.w3.org; Tue, 13 Aug 2019 18:49:19 +0000
Resent-Date: Tue, 13 Aug 2019 18:49:19 +0000
Resent-Message-Id: <E1hxbrD-0000xr-FY@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 <mbishop@evequefou.be>) id 1hxbr8-0000vn-Fm for ietf-http-wg@listhub.w3.org; Tue, 13 Aug 2019 18:49:14 +0000
Received: from mail-eopbgr760097.outbound.protection.outlook.com ([40.107.76.97] helo=NAM02-CY1-obe.outbound.protection.outlook.com) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mbishop@evequefou.be>) id 1hxbr6-0005II-1O for ietf-http-wg@w3.org; Tue, 13 Aug 2019 18:49:14 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DNLegbe44uUeUpIegs/FPE1xiPjC2n8uonAR7VzfJhv0hICUMzUWIJ5bN+WRWLDbVz8o95gEFHbX57Hyt1e1SWkEB8xVNUDmNzLadfugdF4XbiYnIlnwf8Ap2W6HmY49gy+tUIlCPWEKzz4FRNJCLbt6OyC6ACikCDhOufaX5FRFR8n0KygvnTGtmloTN6wXXRRCOgJEiRSD4DZJibFI3QbiWZsvLthCr4hJM+xBKWrggxxflq91tR3S3lbdUg+dHo5h78WBmx6yKm4VrA39babeq0lVdAS0wHIjRMBUMHwJt93gZUdoJbwCyPYHVLhGzoq3ybiJ2gY2ewRbwEGimQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LJyPDzdZa1UrOWoyFvcER2GQlZo4ICkXZOxeNra89hw=; b=nwRUp0wWpJvgJYEKGlzMJBoxFY9HhaNQA3COrxPN51vconwzJP5fVqOQxmKIWzJSOOwwxZFpbdH/MaS9xpfbobIoR6WIqcRs3Icbq294dnunI7pRBLoXQPN8SBWH4r8bJrLfjwsu9foBPN3OZbcJNSTn56qX1iIDTok96dtbl+49vBk3PfN7ADBXSs2KamrAeTgqUj639tynebZwEBRfqv/RD0xrcCEojOLPEfEDsVx3obxneTisJDjthMXqSX1Crki7nhtWDP/2NpWXdsr/+DMs5cKPoaiq9G8Kd8wZRmFhVLnPj7kdBAmtpTCE9hPR/I5BiqajhQssJ2SgK1yOzQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LJyPDzdZa1UrOWoyFvcER2GQlZo4ICkXZOxeNra89hw=; b=eFR908BhUuCE2cHtpG6OipC2rJlYz155I3MYW1akjNDW4F9T3DnMayXXsJQa/L3YFScUJvutfhPGMRCoez2eeJThL2WGj6M2Dt6tIKshOz/ez4Y4aj5nvtybP/ICiT1CcDiu6DSCxiaoy6hUSkMCbvLYiQ21j4gN56uqSEKB1EY=
Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0182.namprd22.prod.outlook.com (10.169.185.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Tue, 13 Aug 2019 18:48:49 +0000
Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::4190:c9d6:bf3f:2432]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::4190:c9d6:bf3f:2432%4]) with mapi id 15.20.2157.022; Tue, 13 Aug 2019 18:48:49 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
CC: HTTP Working Group <ietf-http-wg@w3.org>, Matthew Kerwin <matthew@kerwin.net.au>, Brad Lassey <lassey@chromium.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Thread-Topic: =?utf-8?B?UmVwdXJwb3NlIG9mIHByb3RvY29sIGVsZW1lbnRzIHwgUmU6IFJlcHVycG9z?= =?utf-8?B?ZSBvZiBwcmlvcml0eSB8ICDii68gfCBSZTogU2V0dGluZyB0byBkaXNhYmxl?= =?utf-8?Q?_HTTP/2_Priorities?=
Thread-Index: AQHVSdMErqg+r7mwH0qMNGMCgSuOXKb5dVBA
Date: Tue, 13 Aug 2019 18:48:48 +0000
Message-ID: <CY4PR22MB0983632F7DCA64E22028D4BEDAD20@CY4PR22MB0983.namprd22.prod.outlook.com>
References: <20190725191746.GB12596@ubuntu-dmitri> <20190730154809.BBE3412178@welho-filter1.welho.com> <CALGR9oZnKo1JXnxLiKp+04kJeT5Uek3BiCPq=XSq4dG4B3AUBA@mail.gmail.com> <CACweHNDChKtVBTzQGctxAFdgZydrOKt8a9oAKrYbbq1JKLFPNg@mail.gmail.com> <CALGR9oaM2JaAnFJt+e6B87jNYgGd42_fRbycSrqU31tEgR=AEg@mail.gmail.com> <20190801164638.522628CD1@welho-filter3.welho.com> <CALGR9obEjQnFTSnyUjx40vd8EvwHLjuovNxjWaT_3euKcnm1Hg@mail.gmail.com> <20190803080758.2CDEC4552F@welho-filter4.welho.com>
In-Reply-To: <20190803080758.2CDEC4552F@welho-filter4.welho.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [2600:2b00:9326:a801:f02b:a4fa:6e65:f89a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6105188a-c15b-4316-60d8-08d7201ee0f6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0182;
x-ms-traffictypediagnostic: CY4PR22MB0182:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <CY4PR22MB018230C66DFAF16C0F1BFEA1DAD20@CY4PR22MB0182.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 01283822F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(396003)(366004)(136003)(376002)(346002)(199004)(189003)(13464003)(86362001)(55016002)(508600001)(53546011)(6436002)(8936002)(6506007)(110136005)(81166006)(76176011)(4326008)(81156014)(2906002)(102836004)(14454004)(256004)(6116002)(53936002)(33656002)(7696005)(54906003)(486006)(66556008)(66476007)(76116006)(66946007)(11346002)(446003)(476003)(64756008)(46003)(229853002)(74316002)(25786009)(5660300002)(186003)(7736002)(316002)(66446008)(6246003)(71200400001)(6306002)(71190400001)(52536014)(790700001)(99286004)(9686003)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0182; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: j4VI6Sm7tHq8cTvigaBasBEK37RqVQKRY10BGWOGWgp+p4Gxt+i8KAEzBEKARzcnr0HupszAGl9qoT/r/XkZF7pwBLyQJb7NRhmXQfm+931Hp1XBlNTttp7DTc3flXAobbnTu9QLcMA3dk+tRVONQn6hA0SNvLWPO72dgWF5MbPwCsFFBmMiNWMoP1NYIUW8kTqRb4qRJyfBr8q7JES6wr8Q/F8sON37wo4y8DzXAcbPt3EJO6cWoOhMiPTo3LCvzFNw3ip6EgeLuneoospjuZy/aUys06hyBRg9Bt56SMDXh4OfomtcBVEKK4sYPEhf0xpRri0HeCbcndeVMxKM0bMPg73eizZkK5zI5VZXyts54Csv+9lfiDTg5pRG4s6qHwhMxBiHv3tvjWbZ/tvUeMZw/O7AVAwye/C9N3WONLw=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983632F7DCA64E22028D4BEDAD20CY4PR22MB0983namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 6105188a-c15b-4316-60d8-08d7201ee0f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 18:48:49.0355 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +htAWB5ylRXqPJyO7apfMd3f6UgCrK64Yr/jgTV7nBXhBVvUQnkXRVC7dbKPPplZSt7AbCDT92tlyhQEWlWCFg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0182
Received-SPF: pass client-ip=40.107.76.97; envelope-from=mbishop@evequefou.be; helo=NAM02-CY1-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hxbr6-0005II-1O 83a3bf2833be2751467a3292fd3f29bf
X-Original-To: ietf-http-wg@w3.org
Subject: =?utf-8?B?UkU6IFJlcHVycG9zZSBvZiBwcm90b2NvbCBlbGVtZW50cyB8IFJlOiBSZXB1?= =?utf-8?B?cnBvc2Ugb2YgcHJpb3JpdHkgfCAg4ouvIHwgUmU6IFNldHRpbmcgdG8gZGlz?= =?utf-8?Q?able_HTTP/2_Priorities?=
Archived-At: <https://www.w3.org/mid/CY4PR22MB0983632F7DCA64E22028D4BEDAD20@CY4PR22MB0983.namprd22.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36974
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>

This form of negotiation appears to presuppose sending multiple SETTINGS frames.  First you advertise that something is available, and only if it's available on the other side do you then declare that you're sending it.



HTTP/3 only permits a single SETTINGS frame in each direction, and for latency reasons you really shouldn't wait to see the peer's values before sending your own.  Therefore, I think you wind up in one of three postures for negotiating something like this:

  *   Each side declares their supported schemes.  There is a defined algorithm by which each side, having both declarations, can conclude the most mutually-preferred scheme.  Clients can’t generate PRIORITY frames until they’ve seen the server’s declaration.
  *   The server declares its supported schemes, each of which will use different frame types.  The client SHOULD NOT send more than one scheme simultaneously (but perhaps MAY send all of them until it sees the SETTINGS frame).
  *   Define a separate extension which is used for negotiation separate from SETTINGS.



-----Original Message-----
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>;
Sent: Saturday, August 3, 2019 3:58 AM
To: Lucas Pardue <lucaspardue.24.7@gmail.com>;; HTTP Working Group <ietf-http-wg@w3.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>;
Subject: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities



> Any client that is taking the chance to make a semantic change to the

> frames it is sending would be foolish to not wait on an affirmative

> signal from the server. RFC 7540 Section 5.5. calls specific attention

> to such a

> repurposing:

>

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

>

> Lucas



Okei,



Generally repurpose of protocol element requires 3 values (or 2 bits from bitmask) for SETTINGS parameter SETTINGS_ENABLE_{feature}.

For example values



•  0       {feature}_NOT_SUPPORTED,

•  1       {feature}_AVAILABLE

•  3       SENDING_{feature}





Recipient of repurposed protocol element sends first SETTINGS parameter SETTINGS_ENABLE_{feature} with value

1 ({feature}_AVAILABLE).





Sender of repurposed protocol element sends SETTINGS parameter SETTINGS_ENABLE_{feature} with value 3 (SENDING_{feature}) before it starts sending repurposed protocol element.





Recipient interprets protocol element without {feature}

until it receives SETTINGS parameter SETTINGS_ENABLE_{feature}

with value 3 (SENDING_{feature}).





Sending SETTINGS parameter SETTINGS_ENABLE_{feature} with

value 3 (SENDING_{feature}) is protocol violation unless

SETTINGS parameter SETTINGS_ENABLE_{feature} with value

1 ({feature}_AVAILABLE) or 3 (SENDING_{feature}) is received

first.



Both directions needs separately send SETTINGS parameter

SETTINGS_ENABLE_{feature} with value 3 (SENDING_{feature})

before repurposed protocol element can be sent.



SETTINGS parameter SETTINGS_ENABLE_{feature} value 3 (SENDING_{feature})

imply total ordering of frames, so this means HTTP/2. ( Also

HTTP/3 do not allow several SETTINGS frames.)



SETTINGS frame with parameter SETTINGS_ENABLE_{feature} with

value 3 (SENDING_{feature}) indicates time when change

on purpose of protocol element happens.



It is not just enough to know that change is acceptable

for recipient. Recipient must know when change happens.



Introducing of new protocol elements do not require

sending SETTINGS parameter SETTINGS_ENABLE_{feature}

with value 3 (SENDING_{feature}) when frame content

indicates precense of protocol element.



/ Kari Hurtta