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

Willy Tarreau <> Fri, 15 May 2020 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BF2C3A0B62 for <>; Fri, 15 May 2020 08:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CjF0kYqcul9u for <>; Fri, 15 May 2020 08:17:30 -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 D97873A0ABC for <>; Fri, 15 May 2020 08:17:25 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jZc2G-0004wB-E8 for; Fri, 15 May 2020 15:14:04 +0000
Resent-Date: Fri, 15 May 2020 15:14: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 1jZc2E-0004vP-Sc for; Fri, 15 May 2020 15:14:02 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1jZc2C-0001pe-T8 for; Fri, 15 May 2020 15:14:02 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 04FFDaIE008427; Fri, 15 May 2020 17:13:36 +0200
Date: Fri, 15 May 2020 17:13:36 +0200
From: Willy Tarreau <>
To: Julian Reschke <>
Cc: Mark Nottingham <>,,,,,
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=;;
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: 1jZc2C-0001pe-T8 170e804d2a769e291807a643e82d01af
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/37630
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, May 15, 2020 at 10:20:21AM +0200, Julian Reschke wrote:
> > > 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).
> Yes.
> > 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 agree with this. Typically the problem is that clients could abuse
intermediaries to transform their requests. So adding a hint for
intermediaries here would help. If it's explicitly written that a
recipient is allowed to reject a request having such invalid header
value, I'm fine telling haproxy users that what haproxy does on this
or that header field is correct and spec-compliant. Otherwise the best
I can do is encourage them to add blocking rules it if they dare do it.

The problem is always the same: intermediaries are forced to remain as
transparent as possible (even violating specs sometimes) because when
inserting them results in breakage, it's necessary their fault. Here we
have an opportunity to allow them to be a bit stricter, we really ought
to take it!

Just my two cents,