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, 1 Aug 2019 19:46:26 +0300 (EEST)
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