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

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 07 August 2019 14:43 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 C05E9120280 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 7 Aug 2019 07:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wLyFO7AjLvDL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 7 Aug 2019 07:43:51 -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 6E0AF120271 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 7 Aug 2019 07:43:44 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hvN8E-0006J8-J4 for ietf-http-wg-dist@listhub.w3.org; Wed, 07 Aug 2019 14:41:38 +0000
Resent-Date: Wed, 07 Aug 2019 14:41:38 +0000
Resent-Message-Id: <E1hvN8E-0006J8-J4@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 <lucaspardue.24.7@gmail.com>) id 1hvN8B-0006IL-Oy for ietf-http-wg@listhub.w3.org; Wed, 07 Aug 2019 14:41:35 +0000
Received: from mail-ua1-x930.google.com ([2607:f8b0:4864:20::930]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1hvN8A-0005Zl-E5 for ietf-http-wg@w3.org; Wed, 07 Aug 2019 14:41:35 +0000
Received: by mail-ua1-x930.google.com with SMTP id s4so35096081uad.7 for <ietf-http-wg@w3.org>; Wed, 07 Aug 2019 07:41:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qpoHYX1p5IYT37DI+iYaPOR4IdJlzeK/7GyV64A2VoQ=; b=iWbngjtbxwOCNurzCIBBSWNVGpxbFwzZaJ19FSGhl2o5FLvvH7RWlGUQprvqzWBFhK tvvVaxzkAjKL3kdoDnBhBXFyLNzX52JXsdswQpRcz01XV9bdMVvzpTJiw3uECdPQ+ru1 l+gVjyP9Jqqk1X2Kilu3DGXZfPm/wI07ZAARoyJhKd1vYO7Hgr7qMGH+C79RWGPqQEVg 3s0r+WqizJ57DLA8poLJkDo5PTlPpprBCYWoAf2UQovu4Lk5ePR3Dvoc5YZHFFvfZKRd 8mXpbm07tabDIUk0ii7NFtiLYqMy5MSAvkpRy0x2xlgUiMiiaQGkpDzGykfOeBhs43sH QIuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qpoHYX1p5IYT37DI+iYaPOR4IdJlzeK/7GyV64A2VoQ=; b=Nw36oTZiTVN+j5S9BDHGJlyqa7j3WDX85gWPCag2pA/yui8W0cqcPeaqRAzekLO0iA zB8TGOPZUKYTeOXZrxJfURFdYGkhPpDf52V0gk0E0qJePkGos1ocOnyayCK7Nn/fguzg mBH/xSPd0aIxUPVvwJWkBMZ1HFDgDrSC7MNGc4bjCu2u2EGbnkXq6E1CU6nNK3+BEdVs FS+cf/nfcEmfE6zExqTAquCDA+R7suVR03sPBqkj2lHM8zkUBfBQk8RZoAzfTcNG6aUb L2/kTKHxHLE5F3jMSlvsepahZ+GUTl1YKrkLO3XhLJQuP3CddCKHcSAdtgcAYyvIiDfT O3/g==
X-Gm-Message-State: APjAAAVKkrbsRJJXXQ5DVqxBjmOq/fZxYU7fkx1w3J3WOZt7j9QzM07O FN3WyJj3j4jff4Zpa/vMl77wN3iCJi0by4cZvWQ=
X-Google-Smtp-Source: APXvYqxK+PIswbcaSogqv/YrBawH5kxhXSs13fuuCBlE451Bo8Tdxrxxzl68x35PNvWka62x+wvK3Hz3wagE/Vc7law=
X-Received: by 2002:ab0:48e7:: with SMTP id y36mr6007214uac.79.1565188873129; Wed, 07 Aug 2019 07:41:13 -0700 (PDT)
MIME-Version: 1.0
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>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 7 Aug 2019 15:41:02 +0100
Message-ID: <CALGR9obzFKQ1JqoDDZhBa0tkHge2koDdLuWFw88t1gZjs3LiYg@mail.gmail.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.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>
Content-Type: multipart/alternative; boundary="000000000000ca137d058f87eeef"
Received-SPF: pass client-ip=2607:f8b0:4864:20::930; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-ua1-x930.google.com
X-W3C-Hub-Spam-Status: No, score=-2.3
X-W3C-Hub-Spam-Report: AWL=1.513, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hvN8A-0005Zl-E5 f66ac6478b34dc5db24a6ee0bc446dd3
X-Original-To: ietf-http-wg@w3.org
Subject: =?UTF-8?Q?Re=3A_Repurpose_of_protocol_elements_=7C_Re=3A_Repurpose_o?= =?UTF-8?Q?f_priority_=7C_=E2=8B=AF_=7C_Re=3A_Setting_to_disable_HTTP=2F2_Priorities?=
Archived-At: <https://www.w3.org/mid/CALGR9obzFKQ1JqoDDZhBa0tkHge2koDdLuWFw88t1gZjs3LiYg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36941
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>

Hi Kari,

Thanks for sharing your thoughts on this thread (and also thanks to you and
Matthew Kerwin for sharing your thoughts on other threads).

To best track things, I plan to summarize some of the discussed options as
an issue on the I-D's repo. When I get around to that, I'll share the link
back to the list.

Cheers
Lucas

On Sat, Aug 3, 2019 at 9:07 AM Kari Hurtta <hurtta-ietf@elmme-mailer.org>;
wrote:

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