Re: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities
Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 13 August 2019 19:51 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 F361812018B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 13 Aug 2019 12:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 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.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 (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 770XW5ZJ3s6y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 13 Aug 2019 12:51:22 -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 7CBA8120898 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 13 Aug 2019 12:51:22 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hxcnD-0004Tf-Q5 for ietf-http-wg-dist@listhub.w3.org; Tue, 13 Aug 2019 19:49:15 +0000
Resent-Date: Tue, 13 Aug 2019 19:49:15 +0000
Resent-Message-Id: <E1hxcnD-0004Tf-Q5@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 <lucaspardue.24.7@gmail.com>) id 1hxcn9-0004So-A2 for ietf-http-wg@listhub.w3.org; Tue, 13 Aug 2019 19:49:11 +0000
Received: from mail-vs1-xe32.google.com ([2607:f8b0:4864:20::e32]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1hxcn7-00063q-5l for ietf-http-wg@w3.org; Tue, 13 Aug 2019 19:49:10 +0000
Received: by mail-vs1-xe32.google.com with SMTP id 2so72962516vso.8 for <ietf-http-wg@w3.org>; Tue, 13 Aug 2019 12:48:48 -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=kPV3AcNHoUA9O0+NjUP+iitqDLimzJNiPjS8toEcz/o=; b=gJlHn3dQqi85ZWWB2gHREd6cpBHUdBGWzyW4JL804Eg9hk9Y6vA8d8rbLn20VbRgyp lvWBlYlsCWYGLGLwbV2sBhDTxKTvtxsoYKXqL3IKatGk+SR/ny9UHhXSBQv2rH0p3al8 3vZ5z+MWXDMBvVlwadBsaPmeXVjj4omVkJI9DqTeo7QPV0gE7E75KZGH0330JUEe4EzO dipuaDdwT2YoNR85QItbRYDU3plGE5Qkap6GzPHdchDe+uDKcvxuUFhiA7FuMI7lW6xh IfA/6zqAFQf9b4jwQW6xwG2pHMh8wuGTWsY+BOvO7LJywD5W/bucN90OiRsCKBOYejAa /xww==
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=kPV3AcNHoUA9O0+NjUP+iitqDLimzJNiPjS8toEcz/o=; b=YiYw2dymDO+a4vZjII0LHKBlStMay7Pzh5MkaDIRfkrWWfKMsHRuYhjt+CiitJPnCS tkrj89+Ct1rgOct1DlT58pd/txj1pPl8bsk9Y9vhgO63yqAnRtMVEmtmFoS6kZzftxXc VQTezM8HAFWai8FENedGIBeKNKED5LTrQM7wN+5aTdfzKH2ea2oViN7gE65VfJ2wRL9R 4amVs3OPlbBCY+u70jlMs4VDyUc+JZglWc1OlGak/pvFTGGH/ZOMiVuwtvXdJjUYWW4u syvHtvYNKa5j60sfvACIhvU0hhLfpFgj1zEA51CBqvT/K2J0ZNTNi83+r+j3goO6I3aL 8tNw==
X-Gm-Message-State: APjAAAXDmZYdfWccCqxhcKKqB+IIVnMNbM7UFOxLH9FtiDrMVEMjoy9F J++M4AYhaz26Oh1okBX8127VYVFiWxbTY9VgpdDiYQ==
X-Google-Smtp-Source: APXvYqzEFvlIJTLOVF2r2kgSrIiAVTXTQRn4QdoRoazpc0u5MtsD3d0Z2TrsPE6tkzVfl6hb4jlUuFGCo71COGbXlAo=
X-Received: by 2002:a67:3141:: with SMTP id x62mr10283329vsx.15.1565725728167; Tue, 13 Aug 2019 12:48:48 -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> <CY4PR22MB0983632F7DCA64E22028D4BEDAD20@CY4PR22MB0983.namprd22.prod.outlook.com>
In-Reply-To: <CY4PR22MB0983632F7DCA64E22028D4BEDAD20@CY4PR22MB0983.namprd22.prod.outlook.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 13 Aug 2019 20:48:39 +0100
Message-ID: <CALGR9oY8ymGqJDKFsWjkqf2qXVhvkNHo8WUo17F5S-7_CZFNOQ@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
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>
Content-Type: multipart/alternative; boundary="000000000000d7e5cc059004edff"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e32; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-vs1-xe32.google.com
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Hub-Spam-Report: AWL=1.477, 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: titan.w3.org 1hxcn7-00063q-5l 9492c1a42cdf4ec2cfdcfe2b91ac7590
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities
Archived-At: <https://www.w3.org/mid/CALGR9oY8ymGqJDKFsWjkqf2qXVhvkNHo8WUo17F5S-7_CZFNOQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36975
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 Mike, On Tue, 13 Aug 2019, 19:48 Mike Bishop, <mbishop@evequefou.be> wrote: > 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. > > > I agree. If I were to enumerate your points, then for point 1 Brad has some WIP text that makes our initial proposal more robust in this sense. And for point 3 I have a strawman not-yet-shared negotiation mechanism that uses extension frames in the manner you describe. Though seeing it written down I'm not convinced it doesn't generate another set of complication. Lucas > -----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 > > > > >
- 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