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

Willy Tarreau <w@1wt.eu> Fri, 15 May 2020 15:17 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 0BF2C3A0B62 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 May 2020 08:17:32 -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=unavailable 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 CjF0kYqcul9u for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 May 2020 08:17:30 -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 D97873A0ABC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 May 2020 08:17:25 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jZc2G-0004wB-E8 for ietf-http-wg-dist@listhub.w3.org; Fri, 15 May 2020 15:14:04 +0000
Resent-Date: Fri, 15 May 2020 15:14:04 +0000
Resent-Message-Id: <E1jZc2G-0004wB-E8@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 1jZc2E-0004vP-Sc for ietf-http-wg@listhub.w3.org; Fri, 15 May 2020 15:14:02 +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 1jZc2C-0001pe-T8 for ietf-http-wg@w3.org; 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 <w@1wt.eu>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, last-call@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, barryleiba@gmail.com, draft-ietf-httpbis-header-structure@ietf.org
Message-ID: <20200515151336.GB8412@1wt.eu>
References: <158740521959.1174.9556681562748997101@ietfa.amsl.com> <bb3a29ff-1a0f-964d-c764-4d4819d338da@gmx.de> <4184EA3A-793F-4F29-8E99-FD371F35F6AC@mnot.net> <0150efc3-9d69-3ada-b714-5d2d6c9dbed3@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0150efc3-9d69-3ada-b714-5d2d6c9dbed3@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 1jZc2C-0001pe-T8 170e804d2a769e291807a643e82d01af
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Last Call: <draft-ietf-httpbis-header-structure-18.txt> (Structured Field Values for HTTP) to Proposed Standard
Archived-At: <https://www.w3.org/mid/20200515151336.GB8412@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37630
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>

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,
Willy