IETF Logo Mail Archive

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

Willy Tarreau <w@1wt.eu> Tue, 12 May 2020 17:26 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 576783A07F9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 May 2020 10:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
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 BlDK1AGcIrJF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 May 2020 10:26:34 -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 E42BF3A07F7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 12 May 2020 10:26:33 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jYYdQ-0008Bs-4c for ietf-http-wg-dist@listhub.w3.org; Tue, 12 May 2020 17:24:04 +0000
Resent-Date: Tue, 12 May 2020 17:24:04 +0000
Resent-Message-Id: <E1jYYdQ-0008Bs-4c@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 <w@1wt.eu>) id 1jYYdP-0008B6-Au for ietf-http-wg@listhub.w3.org; Tue, 12 May 2020 17:24:03 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1jYYdN-0005pP-AR for ietf-http-wg@w3.org; Tue, 12 May 2020 17:24:03 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 04CHNlXI005216; Tue, 12 May 2020 19:23:47 +0200
Date: Tue, 12 May 2020 19:23:47 +0200
From: Willy Tarreau <w@1wt.eu>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20200512172347.GB4817@1wt.eu>
References: <f55521dd-e1d3-d925-688c-c472ad67bfb4@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <f55521dd-e1d3-d925-688c-c472ad67bfb4@gmx.de>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jYYdN-0005pP-AR 98f8b6598ae2da1f69e5bbabf6e310f5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: draft-ietf-httpbis-header-structure: handling multiple field values
Archived-At: <https://www.w3.org/mid/20200512172347.GB4817@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37600
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 Julian,

On Tue, May 12, 2020 at 06:53:40PM +0200, Julian Reschke wrote:
> Hi there,
> 
> while working on an implementation I encountered the following question.
> 
> Consider something defined as "sh-list". If a value is received spread
> over multiple field instances, recipients *can* recombine the value
> before processing. So for
> 
>   Foo: "1
>   Foo: 2"
> 
> ...the parser would see the string "1,2" (or maybe "1, 2").
> 
> What's not totally clear to me is whether recipients are *allowed* to
> process the field values separately, in which case parsing would fail.

Note that they might not be aware that these were two values
because the folding might have been performed by an upstream
gateway.

Regards,
Willy

v2.23.0 | Report a Bug | By Email