Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities
Kari Hurtta <hurtta-ietf@elmme-mailer.org> Sat, 03 August 2019 08:11 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 1E296120124 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 3 Aug 2019 01:11:27 -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 ixHdpzSjGwMq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 3 Aug 2019 01:11:24 -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 981C412003E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 3 Aug 2019 01:11:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1htp5a-0006rQ-U2 for ietf-http-wg-dist@listhub.w3.org; Sat, 03 Aug 2019 08:08:30 +0000
Resent-Date: Sat, 03 Aug 2019 08:08:30 +0000
Resent-Message-Id: <E1htp5a-0006rQ-U2@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <khurtta@welho.com>) id 1htp5T-0006T3-Eg for ietf-http-wg@listhub.w3.org; Sat, 03 Aug 2019 08:08:23 +0000
Received: from welho-filter4.welho.com ([83.102.41.26]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <khurtta@welho.com>) id 1htp5R-0000nT-Gu for ietf-http-wg@w3.org; Sat, 03 Aug 2019 08:08:23 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 2CDEC4552F; Sat, 3 Aug 2019 11:07:58 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id za4Hi1yzJ9RC; Sat, 3 Aug 2019 11:07:57 +0300 (EEST)
Received: from kasvihuone.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPS id 7FB2D7A; Sat, 3 Aug 2019 10:58:22 +0300 (EEST)
In-Reply-To: <CALGR9obEjQnFTSnyUjx40vd8EvwHLjuovNxjWaT_3euKcnm1Hg@mail.gmail.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>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Date: Sat, 03 Aug 2019 10:58:22 +0300
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 PLalpha50a]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190803080758.2CDEC4552F@welho-filter4.welho.com>
Received-SPF: none client-ip=83.102.41.26; envelope-from=khurtta@welho.com; helo=welho-filter4.welho.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=0.986, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1htp5R-0000nT-Gu bdc6e9271dbae3e00f5598bd6a42190c
X-Original-To: ietf-http-wg@w3.org
Subject: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities
Archived-At: <https://www.w3.org/mid/20190803080758.2CDEC4552F@welho-filter4.welho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36929
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>
> 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
- Setting to disable HTTP/2 Priorities Brad Lassey
- Re: Setting to disable HTTP/2 Priorities Dmitri Tikhonov
- Re: Setting to disable HTTP/2 Priorities Lucas Pardue
- Re: Setting to disable HTTP/2 Priorities Brad Lassey
- Re: Setting to disable HTTP/2 Priorities Willy Tarreau
- Re: Setting to disable HTTP/2 Priorities Lucas Pardue
- Re: Setting to disable HTTP/2 Priorities Willy Tarreau
- RE: Setting to disable HTTP/2 Priorities Mike Bishop
- Re: Setting to disable HTTP/2 Priorities Kazuho Oku
- Re: Setting to disable HTTP/2 Priorities Willy Tarreau
- RE: Setting to disable HTTP/2 Priorities Mike Bishop
- SETTINGS_PRIORITY_SCHEME | Re: Setting to disable… Kari Hurtta
- Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to dis… Lucas Pardue
- Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to dis… Matthew Kerwin
- Re: Setting to disable HTTP/2 Priorities Willy Tarreau
- Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to dis… Lucas Pardue
- ENABLE ⇒ PROVIDE | Re: SETTINGS_PRIORITY_SCHEME |… Kari Hurtta
- SETTINGS_HTTP3_PRIORITY_MASK? | Re: SETTINGS_PRIO… Kari Hurtta
- Re: ENABLE ⇒ PROVIDE | Re: SETTINGS_PRIORITY_SCHE… Lucas Pardue
- SETTINGS_ENABLE_HTTP2_PRIORITIES default value | … Kari Hurtta
- Re: SETTINGS_ENABLE_HTTP2_PRIORITIES default valu… Lucas Pardue
- Re: SETTINGS_HTTP3_PRIORITY_MASK? | Re: SETTINGS_… Lucas Pardue
- Re: ENABLE ⇒ PROVIDE | Re: SETTINGS_PRIORITY_SCHE… Matthew Kerwin
- Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to dis… Matthew Kerwin
- Re: ENABLE ⇒ PROVIDE | Re: SETTINGS_PRIORITY_SCHE… Kari Hurtta
- HTTP/2 (RFC7540) tree priorities exit (opt out) |… Kari Hurtta
- Re: SETTINGS_ENABLE_HTTP2_PRIORITIES default valu… Willy Tarreau
- Re: SETTINGS_ENABLE_HTTP2_PRIORITIES default valu… Willy Tarreau
- [resend] SETTINGS_HTTP2_PRIORITY_MODEL (or SETTIN… Kari Hurtta
- Re: [resend] SETTINGS_HTTP2_PRIORITY_MODEL (or SE… Willy Tarreau
- Repurpose of priority | Re: SETTINGS_PRIORITY_SCH… Kari Hurtta
- Re: Repurpose of priority | Re: SETTINGS_PRIORITY… Lucas Pardue
- Repurpose of protocol elements | Re: Repurpose of… Kari Hurtta
- Re: Repurpose of protocol elements | Re: Repurpos… Lucas Pardue
- new type number versus repurpose of existing fiel… Kari Hurtta
- Re: new type number versus repurpose of existing … Lucas Pardue
- Re: new type number versus repurpose of existing … Matthew Kerwin
- Re: new type number versus repurpose of existing … Lucas Pardue
- reserved bit from Flags field | Re: new type numb… Kari Hurtta
- Re: reserved bit from Flags field | Re: new type … Lucas Pardue
- Re: reserved bit from Flags field | Re: new type … Kari Hurtta
- Re: reserved bit from Flags field | … | Re: Setti… Kari Hurtta
- Re: reserved bit from Flags field | … | Re: Setti… Lucas Pardue
- RE: Repurpose of protocol elements | Re: Repurpos… Mike Bishop
- Re: Repurpose of protocol elements | Re: Repurpos… Lucas Pardue