Re: Last Call: <draft-ietf-httpbis-header-structure-18.txt> (Structured Field Values for HTTP) to Proposed Standard

Mark Nottingham <> Fri, 15 May 2020 02:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7FE63A0538 for <>; Thu, 14 May 2020 19:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Status: No, score=-2.748 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.25, 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: (amavisd-new); dkim=pass (2048-bit key) header.b=PxCFKsZ5; dkim=pass (2048-bit key) header.b=DV4P+L85
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DTHCcArCsfHQ for <>; Thu, 14 May 2020 19:30:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BA293A0496 for <>; Thu, 14 May 2020 19:30:27 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jZQ4W-0002w4-TH for; Fri, 15 May 2020 02:27:36 +0000
Resent-Date: Fri, 15 May 2020 02:27:36 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jZQ4V-0002v2-4Q for; Fri, 15 May 2020 02:27:35 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jZQ4R-0004qk-19 for; Fri, 15 May 2020 02:27:34 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id C8227745; Thu, 14 May 2020 22:27:16 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Thu, 14 May 2020 22:27:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=Z ME4aqP17FqVOiFCyWk/RchAhGoYZ0ddQutN516POBc=; b=PxCFKsZ5iXxuEPmYW oFJEeHiOXCst7WOdSea3cJ4CoXf8hP9MZYsJX5C5SSGna3EOFT2oATPDJkJU25JR IvHL4fpMlWmkCeT+unGZ3CZ6VLyINMOl/+f3ZB03ofu1i/NLYIdPq8if7VfUpA63 DuB+S4vqHG8PZzJLi4DDPDFdmTtuKiJK6piY/v17KvWWbZaP7NgbPt5sIsBHa0fs 28gO8PjMdz+NSHbK0SuOWj2Uha1GPYvONyq29YItdZDsyQV4hh8TSHAPbpW0zxsA YbdWmlTJG4ccym5DS/fGW+2LRkY4s5UlK0smSDyYBi8zvTg+StIo33r1/KbaDeVZ sMJbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=ZME4aqP17FqVOiFCyWk/RchAhGoYZ0ddQutN516PO Bc=; b=DV4P+L85ltmSqSojeLcqtmnqI1j9iXBzPO27JW5WAMk247Pekw2us+x+s 40MxY9dj7qn0g/jv6QP8Hv+CwGQMkzc9srvKGRTU3An5YA00xlWcaQr8wOky2DdO l4aiyXpc+JfeaSspEnWvJtAPvW3TO9HvM62XNWFv6fB5bbOYo9ZFPVmMWONUNnHG nHt4SXchPJ0ZXXhf4MXKbjiKE1KXs80rNxzDVSFusr963LZ9npHdxeUPX8iEWsog gp8WNlP7DN4jDX7s6fUoVI9yGiEVJscHiKEx5WcbhqAYYlfFGmIxttDqrC1LoEMX 2StVG5w+dT/B8YN8gTAsbU8YFNxRw==
X-ME-Sender: <xms:Av69XnmbW-yzJ54jHngRx08W-H2PGXSQW4RBH0e0SfMTc5yMUtznbg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleejgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepudfgleegtdekfffhheehtdefiedtieehvdfghfehkeegteegudejkeejiefftedt necuffhomhgrihhnpeiffedrohhrghdpihgvthhfrdhorhhgpdhmnhhothdrnhgvthenuc fkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:Av69Xq0EMnqwsL6j-IElFdxQz1XevHTjfCGsa9UorazF7z-kk9oqyw> <xmx:Av69XtrDW0RWaDfQrvwCBi6Ou2WJT0A9LdbyEA3othfVuQ_2PbwRgQ> <xmx:Av69Xvmr42rIyp4Bn0LEfS7yZIZ-0G-1jvvGcZceePMJtbjtT2Lu0w> <xmx:BP69Xt-rXYG0rVQwPLoCtKKozRvLjYGa_xD58YRwhguGA0c5h5nrqg>
Received: from ( []) by (Postfix) with ESMTPA id A1C8F3060C1B; Thu, 14 May 2020 22:27:12 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Fri, 15 May 2020 12:27:00 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Julian F. Reschke" <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
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: 1jZQ4R-0004qk-19 e7dec8cf3c97690942bbc7adc5c54b48
Subject: Re: Last Call: <draft-ietf-httpbis-header-structure-18.txt> (Structured Field Values for HTTP) to Proposed Standard
Archived-At: <>
X-Mailing-List: <> archive/latest/37625
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Julian,

> On 13 May 2020, at 1:59 pm, Julian Reschke <> wrote:
> Hi there,
> I note that this mail was cc'd to the HTTP WG mailing list
> (, but apparently didn't make it there (see
> <>). We
> really should find out what went wrong here.
> (the same seems to have happened for the LC on
> draft-ietf-httpbis-client-hints-13 a few days later)

Will look into it.

> I'll use that as somewhat lame excuse for a very late comment on the
> document (I've been working on an implementation and this came up just
> yesterday):
> <>
> says:
>>   When generating input_bytes, parsers MUST combine all lines in the
>>   same section (header or trailer) that case-insensitively match the
>>   field name into one comma-separated field-value, as per [RFC7230],
>>   Section 3.2.2; this assures that the entire field value is processed
>>   correctly.
> It doesn't require *how* to combine these values (and that's ok because
> it can't).

Right; the "how" is in 7230 3.2.2.

> Later on it says:
>>   Strings split across multiple field lines will have unpredictable
>>   results, because comma(s) and whitespace inserted upon combination
>>   will become part of the string output by the parser.  Since
>>   concatenation might be done by an upstream intermediary, the results
>>   are not under the control of the serializer or the parser.
> So there are HTTP messages that can lead to different parsing results,
> depending on what intermediaries do (how *they* combine the lines), and
> what the final recipient does.
> That this can happen for certain inputs is a given; *this* spec can't do
> anything about that as it doesn't control the other parts in the
> transmission chain.

Yes. That part of the text is really an aside explaining how things work, rather than anything normative.

> What bugs me is that we have an invalid message to start with, but the
> spec apparently *requires* receivers to accept it, albeit with
> potentially unpredictable results.
> IMHO it would be better to allow those recipients that *can* detect the
> brokenness to reject these fields.

The problem is that many recipients won't be able to. This includes not only when an intermediary combines multiple field lines into one, but also when a server or library does so (which is more common IME).

We already have potential inconsistency in whitespace caused by such combination. I'm reluctant to add another dimension of inconsistency (whether or not the SH^HF implementation can recognise this situation and reject early).

> If it is really intended to forbid that it might be good to add a short
> explanation why this is the case.


Also, I think we can more clearly prohibit implementations from sending that form (although I doubt it's much of an issue in practice).


Mark Nottingham