Re: Magnus Westerlund's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)

Mark Nottingham <mnot@mnot.net> Thu, 21 May 2020 03:32 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 90E323A0A43 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 May 2020 20:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
X-Spam-Status: No, score=-2.749 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, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=JrwsIoLn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xukncDj0
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 vxC9v75u4AYf for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 May 2020 20:32:55 -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 ACC0A3A0A3E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 May 2020 20:32:55 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jbbuF-0003Mu-Nn for ietf-http-wg-dist@listhub.w3.org; Thu, 21 May 2020 03:30:03 +0000
Resent-Date: Thu, 21 May 2020 03:30:03 +0000
Resent-Message-Id: <E1jbbuF-0003Mu-Nn@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mnot@mnot.net>) id 1jbbuE-0003M3-Go for ietf-http-wg@listhub.w3.org; Thu, 21 May 2020 03:30:02 +0000
Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mnot@mnot.net>) id 1jbbuC-0002lG-CT for ietf-http-wg@w3.org; Thu, 21 May 2020 03:30:02 +0000
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7835C5C010A; Wed, 20 May 2020 23:29:47 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 20 May 2020 23:29:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=7 i4zEjbKBKUmM2n6pRCt6YzN+bsTbJEmkluV/PrYdxw=; b=JrwsIoLnis7Pqq50J jag/C5anQ0pedLce91xblPMhdvh56MuKfMT+k3bwODbxnan7T0LXK8guRxvXvmlj QAuGTfoqHBRZ4JNQ0a2ra9i2/5BcPTiVVJZtjBaFEI3WWlFELUO2859NmvATVprC 5kJGxQIsTgIwPTnFERBhmW3Oz+GBLqYfqjvLn5X8yIGWSI+P80w5YbtVB1Ll37MN cmB59IwGieS++j+7iQVkSK+bSBMqcT+UxUoOkEHSIduplkDE1M/ZhiFo4Q9IAGGj NA/XxhMGyyGWTZujyFtBEQOFpXOrOQ/szSkTkUeqcCYEtJpkt8CiUQKsXrNUEu1d ct93g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm2; bh=7i4zEjbKBKUmM2n6pRCt6YzN+bsTbJEmkluV/PrYd xw=; b=xukncDj0wyTOd9/jGAQwWgp/dqVDQdVPI8I/0OMlLeE8TiiWmzpONI9H8 qNeBIkAb0rPgP61hdjMrAKLEnM4qvcswxO8D8TRcMhTd61g2ipSkQRTdznrYdDDh 3m6E8Kj0O2tawouFy+qjsUHhozDyB9mcQoAbpEgBhJV3Kd2bjVK57RvWRz18oS/D 2EPQ7ozKWA/sIPaaKI+xz8S4RthMJQSEPKmqgsCrtQyV7B0Jwz3iPVJwoBopcAwE Qaupkku3pzmkTibOgNUnuFlJueGQqTnXaf+bbFmqeQKfv8ORlWeqanEoUUH6QJy1 FbWbZXR+sRsxrEY81Haq0aN9MtBMA==
X-ME-Sender: <xms:qvXFXvK6olDnbWqxuu3eYPxj5wF-22divhPmps1_axN-iGdTSbvUAQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddutddgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeegjeeuuddukedtgfetiedvfeeuhfejtddvgfeuleeikedvgeetteetgeffiedt teenucffohhmrghinhephhhtthhphhgvrgguvghrfhhivghluggtohhnvhgvhihsihhnfh horhhmrghtihhonhgrsghouhhthhhofihmuhgthhhfohhothhhvghmvghsshgrghgvhhgr shdrfhhoohdpvgigrghmphhlvgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeduudelrd dujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:qvXFXjIhTQTOBZTnxhe6-aq9_sVzBVxPnChFoiPVSMHYKRop8rKf3w> <xmx:qvXFXntmIg5TBEifbTqJr3jZhdltGtY9NOj-b2j5es6UWP0l7KEgUA> <xmx:qvXFXoaQ_1RiskgsWhNCPh2NwUoqnJEDO8mpGZAyDVqkXepQttOu8g> <xmx:q_XFXtz6PtGFhSf5QKwudl-Wx1Z0Sq1LPMVrd38OF_OgkAJcs9_1zw>
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A7DD3280059; Wed, 20 May 2020 23:29:43 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <158999125648.6532.5459156073983471929@ietfa.amsl.com>
Date: Thu, 21 May 2020 13:29:41 +1000
Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-header-structure@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, Tommy Pauly <tpauly@apple.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <319DABED-996F-415A-9A6F-1CB13C77C40E@mnot.net>
References: <158999125648.6532.5459156073983471929@ietfa.amsl.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Received-SPF: pass client-ip=66.111.4.25; envelope-from=mnot@mnot.net; helo=out1-smtp.messagingengine.com
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_H3=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: titan.w3.org 1jbbuC-0002lG-CT c8299991475176a70156541497368e7c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Magnus Westerlund's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)
Archived-At: <https://www.w3.org/mid/319DABED-996F-415A-9A6F-1CB13C77C40E@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37694
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 Magnus,

Thanks for the review. Responses below.

> On 21 May 2020, at 2:14 am, Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> A. Section 3.1:
> 
>   The ABNF for Lists in HTTP fields is:
> 
>   sh-list       = list-member *( *SP "," *SP list-member )
>   list-member   = sh-item / inner-list
> 
>   Each member is separated by a comma and optional whitespace.
> 
> To me there is a clarity issue that could lead to interoperability issues.
> Namely the difference in the meaning of whitespace between RFC 7230 and this
> document. Structured headers appear to not allow the HTAB that RFC7230 allows.
> And that is fine, but I would expect this to be more clearly discussed. If the
> intention was to allow for HTAB you need to use WSP rather than SP in above
> rule.

Hm. Conceivably, someone (e.g., an intermediary or a library) could combine two header instances and use COMMA HTAB; while the current text in 7230 only says "separated by a comma", but the (I believe more correct) text in semantics-core says "separated by a comma and optional whitespace. For consistency, use comma SP."

I think the chances of that actually being a problem are very, very small; by far the most common practice is comma SP. However, it's hard to rule out completely.

At this late stage, this is a non-trivial change; the risk of an implementation not updating for it is relatively low, but the risk of getting the fix wrong is much higher. So, I'm going to prepare a pull request and circulate it in the community to both get more eyes on it, and make sure the change gets consensus.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 1. Section 2, page 8:
>   --8<--
>     42. Foo-Example Header
> 
>   The Foo-Example HTTP header field conveys information about how
>   much Foo the message has.
> 
>   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
>   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:
> 
>     Foo-Example = sh-integer
> 
>   Its value indicates the amount of Foo in the message, and MUST
>   be between 0 and 10, inclusive; other values MUST cause
>   the entire header field to be ignored.
> 
>   The following parameters are defined:
>   * A Parameter whose name is "foourl", and whose value is a String
>     (Section Y.Y of [RFCxxxx]), conveying the Foo URL
>     for the message. See below for processing requirements.
> 
>   "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
>   its value is not a valid URI-reference, the entire header field
>   MUST be ignored. If its value is a relative reference (Section 4.2
>   of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before
>   being used.
> 
>   For example:
> 
>     Foo-Example: 2; foourl="https://foo.example.com/"
>   --8<--
> 
> To me this example indicates several unclarities in this specification.
> 
> First there is a lack of discussion of the definition of the field-name and
> clearly identify it. In the above example it is only implicit identified. I
> would propose that this example has an additional paragraph that explicitly
> defined the Structure header name as discussed in the paragraph above this
> example.
> 
> Per RFC 7230 Section 3.2 a header field is the complete structure of field-name
> ":" OWS field-value OWS. However looking at this example it appears that
> structured header field only define the field-value. Wouldn't it be better to
> be explicit about these two components although I understand that field-name is
> a constant. This is also evident in what appears to be a grammatical error in
> the above paragraph:

This is how we define HTTP headers; see for example the core documents, RFC7230, or most any of the extensions we're working on. There's been a lot of discussion leading up to this, and I won't reiterate all of that here; but it's pretty settled.


>   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
>   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:
> 
> The second "Its" would to me indicate Foo-Example a Item Structured Header, not
> the header value (field-value in ABNF) which is defined. I would suggest
> changing the second Its to "The Structured header value ABNF is:"

I don't think that's an improvement.

Cheers,

--
Mark Nottingham   https://www.mnot.net/