Repurpose of priority | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities
Kari Hurtta <hurtta-ietf@elmme-mailer.org> Thu, 01 August 2019 16:49 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 D2A7D12022E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Aug 2019 09:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=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 VrPldewQJwZo for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Aug 2019 09:49:00 -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 D8D10120229 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 1 Aug 2019 09:49:00 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1htEEO-0007z5-2f for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Aug 2019 16:47:08 +0000
Resent-Date: Thu, 01 Aug 2019 16:47:08 +0000
Resent-Message-Id: <E1htEEO-0007z5-2f@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 1htEEK-0007yI-2D for ietf-http-wg@listhub.w3.org; Thu, 01 Aug 2019 16:47:04 +0000
Received: from welho-filter3.welho.com ([83.102.41.25]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <khurtta@welho.com>) id 1htEEH-0002IN-Ko for ietf-http-wg@w3.org; Thu, 01 Aug 2019 16:47:03 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 522628CD1; Thu, 1 Aug 2019 19:46:38 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id kVIJYY0SQBO7; Thu, 1 Aug 2019 19:46:37 +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-smtp3.welho.com (Postfix) with ESMTPS id 570932308; Thu, 1 Aug 2019 19:46:27 +0300 (EEST)
In-Reply-To: <CALGR9oaM2JaAnFJt+e6B87jNYgGd42_fRbycSrqU31tEgR=AEg@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>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Date: Thu, 01 Aug 2019 19:46:26 +0300
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Matthew Kerwin <matthew@kerwin.net.au>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, 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: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20190801164638.522628CD1@welho-filter3.welho.com>
Received-SPF: none client-ip=83.102.41.25; envelope-from=khurtta@welho.com; helo=welho-filter3.welho.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=0.995, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.232, 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 1htEEH-0002IN-Ko a599761084b13f683a0329535c3c1278
X-Original-To: ietf-http-wg@w3.org
Subject: Repurpose of priority | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities
Archived-At: <https://www.w3.org/mid/20190801164638.522628CD1@welho-filter3.welho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36921
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>
> It's difficult for a server to guess at the client intent. Not sending > PRIORITY information is also a signal to prioritise the request with > default RFC7540 parameters (depend on root node with weight 16). So having > a clear signal from client to server along the lines of "I don't intend to > send, and don't infer any RFC7540 meaning from it" avoids that problem and > my impression from Montreal was that this is a desirable goal. In Montreal > we also discussed a possible experiment where the H2 PRIORITY frame > contents would be repurposed, which requires a compatible server to read it > correctly. In this case the signal would be more like "will send in an > RFC7540-incompatible format". > > Lucas Note that http client may send data before it is read SETTINGS frame which is part of the server connection preface. https://tools.ietf.org/html/rfc7540#section-3.5https://tools.ietf.org/html/rfc7540#section-3.5 | To avoid unnecessary latency, clients are permitted to send | additional frames to the server immediately after sending the client | connection preface, without waiting to receive the server connection | preface. It is important to note, however, that the server | connection preface SETTINGS frame might include parameters that | necessarily alter how a client is expected to communicate with the | server. Upon receiving the SETTINGS frame, the client is expected to | honor any parameters established. In some configurations, it is | possible for the server to transmit SETTINGS before the client sends | additional frames, providing an opportunity to avoid this issue. So if SETTINGS frame changes meaning of PRIORITY data which is already sent, that causes that server will interpreted it different than what http client intended. There may be also Stream Dependency field on HEADERS frame. And also PRIORITY frame may be send before HEADERS frame when stream is on idle state. So that repurpose will not work. / 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