Re: draft-ietf-httpbis-header-structure: handling multiple field values

Julian Reschke <> Wed, 13 May 2020 03:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5E403A07BA for <>; Tue, 12 May 2020 20:22:14 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qT9AQyMkZ-4e for <>; Tue, 12 May 2020 20:22:12 -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 974CD3A07B6 for <>; Tue, 12 May 2020 20:22:12 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jYhvE-00050f-Lo for; Wed, 13 May 2020 03:19:04 +0000
Resent-Date: Wed, 13 May 2020 03:19:04 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jYhvC-0004zu-W7 for; Wed, 13 May 2020 03:19:03 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jYhv7-0005Kq-3e for; Wed, 13 May 2020 03:19:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1589339901; bh=FCyZtMdfjLy0E7eJ7Xg6HYIbOVlGp8TOjgeyCLz0OuM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Tpdfh6R0SwbOZ8p1RGc7XLu9w1RLZPriGbDLnxvRz2p4J2Hmsuc8o1+n30v2fwVtk elMgFKjPuIMPcY9g7Ct887cl3DQA2UyXw2ziBVTcRUWBaEN/oG7tTPkVGH7aM2sQJu w+RGnzAu6ExOtnxFFxVv/XNZdxfh/qiQ0rU53Wsg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1MMGN2-1jqmSZ1E0M-00JKXC; Wed, 13 May 2020 05:18:21 +0200
To: Poul-Henning Kamp <>
Cc: Ian Clelland <>, Willy Tarreau <>, HTTP Working Group <>
References: <> <> <> <> <> <> <> <> <>
From: Julian Reschke <>
Message-ID: <>
Date: Wed, 13 May 2020 05:18:19 +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:ByeIvTAfL9HbOxaQLfRVeHr9a8mCn1XOvW91C4Qd1gSu9STxjDE 96UN20lYgMyOpppqw+0satZk/Aw8lqPBklf3lc4prmKcRkk0RJN7BIArN6F1ABrIXMt+QMx knsUyFYNBvTSeaYvxnRycHOfUewB/76LFjIUiSovljaqgS3kblDL2vnDx+EqWXfliHHVEcf BR9hLscOH1hG8xe7NxJvA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:/cr73KnxSi0=:3zybh1cO2JKDNZvXxwylJZ 7I7ZZQuX6mIXJxeID22QBWO8bZKzbfbAKw2dG++eBORkhjwm6oNSaS3vvMiP+ql7rYFcFOdON T7VfQSVCz72W350sZ9ydB+oWRV5+I9hcCVL/gJ+rRHVPSH7hd0LZG9hIgWJ/M996XzoQWDucw Qqwdngir6kpVLRHVMKfE1Nd9RVCEN13ciGYks06KsD9pWIMxXRuRtImVOr3RwuIV+arxO7ffO eGn6tOAOf/wJsac+/xfbM8f1C2frdr0Xg6DTeAbkoYtxf0n3z8c+RuQgjgNoBBUB/tUGBN2Ca ABytEYXBXhgtR5iHbAS5dK3UaCTg+0/B+NgPf0g0N+xRwlb2JURIDHnAranmmbNSP35B2iczE i2pixk0WDJ5+nA6MBZ81R/TQlKyBhCFj30EwbU5fDOjOfNBW17oh7vs5NPx5ZfnenfXEJHGnK 4xvppQYn+6lptU/Lj2qW84qegq/MGSVdUKXg0ZjEsyTg5FMKQZrtgvKakDoIsD5YqT+D3r23G HG9Gu9ovCRu0UtuKLG7QYYAS2DOX/DJp05IDvjFzBYaM5h1X5HV95JxI/X7ilrih0GKB3e4g5 RxN8feldK6p6XRqGGAyH3XrMn4oHtsMQxsVbFnhvsYpyU3Xe46tF2ovsg0M5lllUsNfClBSBg 3maVF2GncMK5UnY++8P6AYdP73xQOetCXDEC8+OtVB0UFqu5MqpqtOZew01a5+4OBqE/uXLG/ zcqA3/3tLxlcD1uWpf96V8J099qWIvr/TYUPJVa5P4YCtDK59eRbD3JWYzcYsZ8q8YFcMtB1B rq2RXC9jr3Qw7+uj759dSc0k8VEloUzovLBgEe9fNjXqUfFv40DO5OebiO6QQsla6G/ifPpiP HN3SGRNs1rkY6q1mZWomSBGWePEWGbcxO7w0x7rIM9OU1ix/py4LXCMlovA4PtWF7ruxp7+x4 cjTuTivb54MSW6zIffyeV5irbPgtWlTWTNBFxUo0dN6C2r407xKSs43EbYdQs3yKJENIGR+GS Gn5QLvatpsGcKLCMeoQFFF16t+M+Sd+NPFOEWDjpp20f8uPX42EywbCCpiI5F4Uz8+HvOtp9r 9iI2JAN7VTrCSIb/dt7V6dTFmrIJuU4iIDGe5ecvS3KVRJoSZBfXrug5uWy/UpN9Lf43RcIcd RD1kf+bErZ8yvXOCu0Y4pMd7JooTOX+4wPikrvlDjeuyscMDLKRm/Wf8+vQmP9h/R5IFRftEC h3XF6DybuZWjgKsoo
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: 1jYhv7-0005Kq-3e d7c46b179d14760c3c9a82ddff9d29e2
Subject: Re: draft-ietf-httpbis-header-structure: handling multiple field values
Archived-At: <>
X-Mailing-List: <> archive/latest/37613
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 12.05.2020 23:22, Poul-Henning Kamp wrote:
> --------
> In message <>de>, Julian Reschke writes
> :
>> The issue here is that combining
>>    Foo: "a
>> and
>>    Foo: b"
>> into
>>    Foo: "a, b"
>> *hides* an issue, and no failure will occur. Furthermore, we not only
>> get no failure, but the resulting string may vary depending on how the
>> fields were combined.
>> I get that it's unavoidable that this *can* happen, but does this mean
>> we should *disallow* failing for that input?
> Yes, we should disallow it, because that would cause a valid request
> to fail unless a proxy implemented a particular way is in the path.

How can the request be valid, if the resulting string is not fully

> I think we say this very clearly on page 23:
>     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.
> Poul-Henning
> PS: I think your example is wrong, the combined header would be:
>      Foo: "a,b"
> Because there is an important asymmetry in RFC7230/3.2.2.
> A sender is required to know the syntax of the header is a comma
> separated list, before can split the header.
> A receiver on the other hand is under no such obligation, and therefore
>     "…by appending each subsequent field value to
>     the combined field value in order, separated by a comma."
> should be interpreted narrowly:  Only a comma, not whitespace.

(see Willy's reply) FWIW, the latest spec says:

"A recipient MAY combine multiple field lines with the same field name
into one field line, without changing the semantics of the message, by
appending each subsequent field line value to the initial field line
value in order, separated by a comma and optional whitespace. For
consistency, use comma SP."

We go on with

"This means that, aside from the well-known exception noted below, a
sender MUST NOT generate multiple field lines with the same name in a
message (whether in the headers or trailers), or append a field line
when a field line of the same name already exists in the message, unless
that field's definition allows multiple field line values to be
recombined as a comma-separated list [i.e., at least one alternative of
the field's definition allows a comma-separated list, such as an ABNF
rule of #(values) defined in Section 4.5]."

I wonder whether we should point out that each *individual* field line
needs to conform to the syntax defined for the field value, so that
splitting strings over lines would be disallowed.

Best regards, Julian