Re: Working Group Last Call: HTTP/2 revision
Martin Thomson <mt@lowentropy.net> Fri, 23 July 2021 07:16 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 D9F1D3A07F7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 23 Jul 2021 00:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level:
X-Spam-Status: No, score=-2.996 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.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=lowentropy.net header.b=o5asTcPv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SaziQtkY
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 DczdDJbLIDAn for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 23 Jul 2021 00:16:13 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 40FA03A07F5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 23 Jul 2021 00:16:13 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1m6pNm-00016f-Fu for ietf-http-wg-dist@listhub.w3.org; Fri, 23 Jul 2021 07:14:06 +0000
Resent-Date: Fri, 23 Jul 2021 07:14:06 +0000
Resent-Message-Id: <E1m6pNm-00016f-Fu@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1m6pNk-00015t-3s for ietf-http-wg@listhub.w3.org; Fri, 23 Jul 2021 07:14:04 +0000
Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1m6pNi-00059p-3R for ietf-http-wg@w3.org; Fri, 23 Jul 2021 07:14:03 +0000
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9293F5C018A for <ietf-http-wg@w3.org>; Fri, 23 Jul 2021 03:13:49 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Fri, 23 Jul 2021 03:13:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=E9PAAZ1nBshZgoYKouWN76/X5+zGIud Q215ranFP16o=; b=o5asTcPviILKPFopNRDalCxtd8wfmyOuOnvN6vOqAeqT7Yj J6OZo7FJUH9LggopX7UFllKH7eOiTf92wA3mvYYoZcUZjlf+tZHVgV+uiRHhRtLM Iz7oGpzw1D29Ohct8BtF085xPD3FB7W65Q0diYfLBsTnKkA2eHugt/wknqwiASbX SnNPWTeLKSwb0pWqlzknxCg2Le8QaZTaHraT2/HEhT+ea6ZNngyTAI7+oToIK0Sq MZMuUIU1jaBPpsprb91wj1mSJuXHoexVu8AEJAy1rIuHepX4WC/io0zohRaHJ1u1 w3M1nyqvjRc61l/gb2zH6ABH9pR5C72NN2vvLjA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=E9PAAZ 1nBshZgoYKouWN76/X5+zGIudQ215ranFP16o=; b=SaziQtkY8EwOCq4yJ3oLg9 yTDkPlznimWsVKZoQaFzehO1xFfxvL+JbiD5KNsNDQi1NMhgZ4XiqZbY+h/ldHLZ 0mcqSd4ZRVFw8CP6XcMlR5exfuY0j4v27vO5B0ZQjxWlEBwpst1z6jrORPWnZ5vF kQjj4WHBoq7bGhtq/tHU0tUEzdmjloV5n+YqTcudWBWWtZn8wPxcBUBlhj5MRYRW oU0TozFsH9Np/j3b57kayiQKjhRw79GNqsMcgIhT52+5Hy+8jFE376NTQB56/BZf GutPbkHW8jKwbpDGS9hwjLnEAIIw4exAW7PClahSUELUZt1JSVW/HMffAJjQQGWw ==
X-ME-Sender: <xms:LWz6YET8Xqb36Y6r34dLlfm5TRkJyGu0oKx5jiaSQE-kIIXeoN_EDA> <xme:LWz6YBydvPsd-i-Y7GQjrxK9DxvespZMJyQg2fbndyrktsHbqPTLO2HTYWAwmkoU6 9Ba8Ao7NNYvdkyS2uw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeejgdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeffveekgeetvdeuvedtve evtdeuleegveejhfehgfetffeiiefgveefleffteeuleenucffohhmrghinhepghhithhh uhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:LWz6YB1lprnwsUG2hn4J9UZznG3jrUjjXsUOFtVS3ohOXTDOvFJOvQ> <xmx:LWz6YICHUCyuBIvL5R8cTEE_8eTKWIe-Wyh_KzPtB5rUBaBr0f0ybQ> <xmx:LWz6YNh1Sl4ItS4b1ggcLTLQ66rI9ABdfCrgi0bGWjhZqxU9Zj-fIw> <xmx:LWz6YIsrEa9TIt1RUP5f9lTyUzKcxcNSlp31UyVWJ9aQH_PeJ7Z5HA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4B9793C0471; Fri, 23 Jul 2021 03:13:49 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-540-g21c5be8f1e-fm-20210722.001-g21c5be8f
Mime-Version: 1.0
Message-Id: <f48c7add-ac41-47bc-83cd-b4cf7773c930@www.fastmail.com>
In-Reply-To: <20210723065224.GA6702@1wt.eu>
References: <CC0F1E6C-2DA9-42FB-B1FB-1BF3EFEB32B2@mnot.net> <20210723065224.GA6702@1wt.eu>
Date: Fri, 23 Jul 2021 17:13:28 +1000
From: Martin Thomson <mt@lowentropy.net>
To: ietf-http-wg@w3.org
Content-Type: text/plain
Received-SPF: pass client-ip=66.111.4.29; envelope-from=mt@lowentropy.net; helo=out5-smtp.messagingengine.com
X-W3C-Hub-DKIM-Status: validation passed: (address=mt@lowentropy.net domain=lowentropy.net), signature is good
X-W3C-Hub-DKIM-Status: validation passed: (address=mt@lowentropy.net domain=messagingengine.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1m6pNi-00059p-3R 15abde91d48a35e925418492ffc0ba66
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Working Group Last Call: HTTP/2 revision
Archived-At: <https://www.w3.org/mid/f48c7add-ac41-47bc-83cd-b4cf7773c930@www.fastmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/39070
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 Willy, How does this look? https://github.com/httpwg/http2-spec/pull/877 I agree that this was getting a bit unwieldy. It's nice to have it all spelled out, but we ended up with a lot of independent fields. A little vertical space does seem to help with readability. On Fri, Jul 23, 2021, at 16:52, Willy Tarreau wrote: > Hi Mark, > > On Fri, Jul 23, 2021 at 10:05:40AM +1000, Mark Nottingham wrote: > > Hello everyone, > > > > This is the start of Working Group Last Call announcement for this document: > > https://www.ietf.org/archive/id/draft-ietf-httpbis-http2bis-03.html > > > > Please take time to review it carefully and raise any remaining issues you > > see (keeping in mind the scope of work),[1] either on the issues list[2] or > > on this mailing list. Also, we'd like to hear whether you think this document > > is ready to progress (on this list, please). > > Overall it still looks good to me, however I've just noticed something that > seriously bothers me about the new representation of the frames formats. I > simply don't find them legible at all. Example: > > > https://www.ietf.org/archive/id/draft-ietf-httpbis-http2bis-03.html#name-headers > > 6.2 Headers > > HEADERS Frame { > Length (24), > Type (8) = 1, > Unused Flags (2), > PRIORITY Flag (1), > Unused Flag (1), > PADDED Flag (1), > END_HEADERS Flag (1), > Unused Flag (1), > END_STREAM Flag (1), > Reserved (1), > Stream Identifier (31), > [Pad Length (8)], > [Exclusive (1)], > [Stream Dependency (31)], > [Weight (8)], > Field Block Fragment (..), > Padding (..), > } > > Most programming languages use byte boundaries, and I really dare anyone > to visually spot the byte address of each field there. Worse, some > implementors, in an attempt to avoid mistakes, could describe them using > bit fields like this: > > struct headers { > int length:24; > int type:8; > int unused1:2; > int flag:1; > int unused2:1; > int padded:1; > int end_headers:1; > init unused3:1; > int end_stream:1; > int reserved:1; > int stream_id:31; > }; > > But this would in fact follow their machine's byte-ordering and invert > all fields within words! Adding to that that the protocol itself is > byte-oriented, I'd request two minor changes: > > - that a delimiter is placed at each byte boundary before or after a > sub-byte field to help visually count without having to mentally > maintain a modulo 8 when enumerating fields. Even just an empty > line would be sufficient I guess. > > - that something helps figure that the high-order bits are enumerated > first. And please don't start telling me "they're in network byte > order" (as I'm already expecting to hear :-)), as except for those > having been in low-level protocols for at least two decades, nobody > knows how bits are serialized on the wire, and in practice due to > modern encodings like 64/66, bits are not even serialized anymore > and only bytes or words are relevant. And I'm not even counting > crypto that is also byte- or block- oriented. Given that fields are > of different sizes, it's not easy to place a bit number or a hex > mask there, except for the flags, so probably it should be mentioned > in 4.1 "Frame Format". Something like "All fields, including single > bits, are represented and enumerated in network order, which means > from MSB to LSB". > > This would certainly avoid some trivial traps. And I think that writing > the flags' hex masks directly as a comment in front of the bits in the > frame definition would provive a lot more legibility. > > Another point is that I haven't seen any mention of RFC8441 about the > extended CONNECT scheme. Given that the rules imposed to CONNECT handling > require to write an exception in the code, I think it would be worth > mentioning in 8.5 after "A CONNECT request that does not conform to these > restrictions is malformed", "Please note that negotiable extensions to > this method exist" with a link to 8441. It doesn't imply users will > implement it but it can hint them to help better design a parser to > deal with this exception, because writing exceptions is annoying, but > writing code later to work around purposely written exceptions is even > more annoying. > > Otherwise I'm pretty happy with the quality and clarity of this document, > which constitutes a nice improvement over 7540. Great work from our editors! > > Cheers, > Willy > >
- Working Group Last Call: HTTP/2 revision Mark Nottingham
- Re: Working Group Last Call: HTTP/2 revision Willy Tarreau
- Re: Working Group Last Call: HTTP/2 revision Martin Thomson
- Re: Working Group Last Call: HTTP/2 revision Willy Tarreau
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Willy Tarreau
- Re: Working Group Last Call: HTTP/2 revision Martin Thomson
- Re: Working Group Last Call: HTTP/2 revision Mark Nottingham
- Re: Working Group Last Call: HTTP/2 revision Willy Tarreau
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Willy Tarreau
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- states as subsesctions, was: Working Group Last C… Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Martin Thomson
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Willy Tarreau
- Re: Working Group Last Call: HTTP/2 revision Julian Reschke
- Re: Working Group Last Call: HTTP/2 revision Willy Tarreau
- Re: Working Group Last Call: HTTP/2 revision Roy T. Fielding
- Re: Working Group Last Call: HTTP/2 revision Willy Tarreau
- Host and :authority (was Re: Working Group Last C… Martin Thomson
- Re: Host and :authority (was Re: Working Group La… Willy Tarreau
- Re: Host and :authority (was Re: Working Group La… Greg Wilkins
- Re: Host and :authority (was Re: Working Group La… Stefan Eissing
- Re: Host and :authority (was Re: Working Group La… Willy Tarreau
- Re: Host and :authority (was Re: Working Group La… Greg Wilkins
- Re: Host and :authority (was Re: Working Group La… Willy Tarreau
- Re: Host and :authority (was Re: Working Group La… Stefan Eissing
- Re: Host and :authority (was Re: Working Group La… Willy Tarreau
- Re: Working Group Last Call: HTTP/2 revision Greg Wilkins
- Re: Working Group Last Call: HTTP/2 revision Ryan Hamilton
- Re: Working Group Last Call: HTTP/2 revision Martin Thomson