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

Julian Reschke <> Fri, 15 May 2020 08:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 938F03A03F3 for <>; Fri, 15 May 2020 01:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VaB0-605Bx_r for <>; Fri, 15 May 2020 01:21:09 -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 81ECE3A03F6 for <>; Fri, 15 May 2020 01:21:09 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jZVaJ-0003S0-Ch for; Fri, 15 May 2020 08:20:47 +0000
Resent-Date: Fri, 15 May 2020 08:20:47 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jZVaI-0003RF-B0 for; Fri, 15 May 2020 08:20:46 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jZVaG-00061b-4b for; Fri, 15 May 2020 08:20:46 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1589530822; bh=RcesDDIwPvf6wlzLOaiZMKrXI9dLHzLZnXHa+JeRW7o=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=imlEGDXvzBoTrJj+BHbw1MLwjtwmq9kQ6Tee6P1nM79WoMY0VWyYHw7otDNfHf3v7 PYkbnLi1L367uHhAAVR+9s2jXOUpQet5VwPz8VLQ9sMRGdypksbFaF8qSA6cAF3JY6 awCkEA3bFm0QUbOcZXd8f1B9CQNL6eW2ssUerFlM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1M2f5T-1jVwwT1NmR-004DRI; Fri, 15 May 2020 10:20:22 +0200
To: Mark Nottingham <>
References: <> <> <>
From: Julian Reschke <>
Message-ID: <>
Date: Fri, 15 May 2020 10:20:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:SE6W+wMSoKKg7Q4rAXuHvpc/ryaJpzIlqXiCy+1u92SxF6CyzL/ iuid/XtMrf1B+NRxcmArjkm3Xd8/h3wU9nRadJVLxmKsW344bAkAMwMHdm+EzRU/QlpmOLL qVontySWfJlaA33ItHlqVRhQAVrO1Qe2Qg/19FKfYI5Q5sgdTDb9JUTQpyJYAnnhGOtrjva j7nLomXKscjrX6FmlTxng==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Hwfk6Se+sbU=:QTB+/feYdQzahAvXA+nmck SOAbZKrI6jw28Wbe06Zwi6f/svVvn02vgzknXdyPNrxStkGeXzDuU6IyduJ+KR5tdnEjAJTlf nn765MDkSe6dn7Ch9eASlVM/OoPwEevR1Qgz1fomnbEtD2quNEZ4gZj3kmRVt8K6dlt0Nqphh zbuUgQ0PH9wBRbqOujR4M7VVtNz4yW0qReVRWZhmyQXHWTwi5lbQOggahum372B6C4SXS1S4S KSvTqaCaZpMZwEtXWBjyh99O6gYWfDYo+c+i1zpP0mCT6jwJkVI3iP2AhTaijv2uZE+xg3DI1 GmDldMxAEn+26xEWopqRM88BLYoJSYlHkHluXt0g9TnsA7UCFzfiKyFvN2myHoGTP0GjCVIC1 2sT36oXW5szypT8ZvaHfWU0TZ2fGZNhMUJOvWarg80lqiFeTuSz/MGErnkQP0NlzdJiUriXvp K/83lHlphI0eOFuNCrAbXIYftWBZeRxnQIE5BgDBJ9MIEz8+0wWfbFfb39Wo854ZpXkwbzGiZ eMwkoNuOxjjgKu04DCbeLTa6z/5jrQAOLLEVbjn7dEww8Ryt74Ve0jKK62iVAcL7xg0K+VE1s 4kWPmBb3ssI8RmTYjH4FKGh+oqT/Sk8+C8gU423m3ZyWumcpLay+pZx8dFoJiYUBToVdvD1/f q0kK0ifFFhetN+xc/5vVfZymflqXqutNZfcpRu5zAQaLbsJcWEI8mzW13d80Z5OPLl7z769Pm MGo/tn9VvGhuq+V5595wn0lcvh5doNuqt3oR7rb2gYEBtv/A34jwIDUm3W+K0NEyuws0nSxcx ax+IOSoLE0x2A3OEnFma8NyrO1EXrFsrPYkFEq2CFXVc+VHsOSe8xlG5MhpUvX4ExuuEel+sa dIY6YLfGHhYefmAoy7Q9KgcMcQ++qBCArGUBpusrUbQ5mMVdxHajdfgifQ5b/kbfkGdOOr0GX qpRo1ZZYHX6YThRWmBPuRyHzJlwEa0Ck4oiEbjb/ThspYRvWhfzShX8o06FNu7+bKGROCul0l qZ7RMIbAimiXVusI+KDY4QpETGTe5ULexytVsLTEMsfBPnMLbi35Tdu7riTE9rh/sVXAV6N33 gmteLVYlTKJDFfezmC7xFbMDlDYWGGX1vxuYvqQiFi26EK6T74MvS78GZB1+paDdQI+VQdCcC +e0eJZDHc6uAZyiq57V6/aQsNd2U9aexTuAiCH4aISc6faH1iYEwKgoMfd0OHSTh3O556SQXO 364csRrWEtFJ27TBB
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jZVaG-00061b-4b 9bb13b186bb3d10bb4a908729d53b8d3
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/37627
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 15.05.2020 04:27, Mark Nottingham wrote:
>  ...
>> 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.

You know that I know that :-). The point being, RFC 7230 doesn't say
either (except that it needs to be COMMA + optional surrounding whitespace).

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

Understood, but I would see it this way: having *some* implementations
able to detect broken input is better than nobody detecting it, because
this way the problem might be fixed.

I'd really like to hear some more feedback on this. Note that this is
related to what we can say in draft-ietf-httpbis-semantics - is a
recipient allowed *not* to combine field lines when they are clearly in
error, such as with:

   Location: bar


>> If it is really intended to forbid that it might be good to add a short
>> explanation why this is the case.
> Yes.
> Also, I think we can more clearly prohibit implementations from sending that form (although I doubt it's much of an issue in practice).

Yes, this is totally an edge case.

Best regards, Julian