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

Julian Reschke <julian.reschke@gmx.de> Wed, 13 May 2020 04:04 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 C397D3A0A86 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 May 2020 21:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 d8zekQZIT9L9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 May 2020 21:04:50 -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 17B543A0A3C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 12 May 2020 21:04:49 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jYiZ8-0001OP-IZ for ietf-http-wg-dist@listhub.w3.org; Wed, 13 May 2020 04:00:18 +0000
Resent-Date: Wed, 13 May 2020 04:00:18 +0000
Resent-Message-Id: <E1jYiZ8-0001OP-IZ@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 <julian.reschke@gmx.de>) id 1jYiZ7-0001Ne-JE for ietf-http-wg@listhub.w3.org; Wed, 13 May 2020 04:00:17 +0000
Received: from mout.gmx.net ([212.227.15.18]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <julian.reschke@gmx.de>) id 1jYiZ5-0006JY-DX for ietf-http-wg@w3.org; Wed, 13 May 2020 04:00:17 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589342397; bh=CcBSk0mFFyiHzWagLVF1nCDJNwbydx3FCLQgxWGFx+A=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=E4UNLJzWkCh6+U9fxdnPY1uSZPWlsu1P8axgraIXXveslcJtJYFhpZFo4JfInfs54 rPBz8ugME4qj/UTN6Nya4zx2zhdpOyDQiaOKrGMXRcTOI8uQob9r8pwWI1T6OWrvJ8 Mz71HtbwP8ZhQA3i4K6RADGGrARzc9AiTWLlhySc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.182] ([84.171.147.129]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MNt0M-1jjdjR0zYe-00OIVG; Wed, 13 May 2020 05:59:57 +0200
To: last-call@ietf.org
Cc: httpbis-chairs@ietf.org, ietf-http-wg@w3.org, barryleiba@gmail.com, draft-ietf-httpbis-header-structure@ietf.org
References: <158740521959.1174.9556681562748997101@ietfa.amsl.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <bb3a29ff-1a0f-964d-c764-4d4819d338da@gmx.de>
Date: Wed, 13 May 2020 05:59:53 +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: <158740521959.1174.9556681562748997101@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:cHXrfcy5UX7ACDo8pHgF8af7lq4lfunbIEKLXRdW7BoGXIf03E/ LzhajZejeY6dkqc6FCJuhUEFoAX03oCgeoNdKqsgNnSpMHgW5vJKCfYF7VM/s583t1d0Vxe BWeWbJh9c8Gil2eqSN38HjIy+LJYwJP/yV0Tu+CMgH9ol/vk7uIB2AR0ILYrs5oU+oM8/7n hIR75FQ/0WDCndBGECrBA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:6v+eO1dhcfY=:R23xiMQQjqmqJIdr6Fyc7f tbdHezVTkPhTRNPtFFpxdaKBWDzvmu7TEXw5s2uyzdOfMq4nZa0YvX2UH9yL9KHozlb86+KvN JytXxGi9CniRaorJo9QXny2igmlgX1vb6twoJw7KX52BYZYJBwKeAQqUdNAmnKp2NRAq78zi3 3r5WEh3qbHX7Popzx+mnsnKWrdfwpi6o+crQwFSt6FvofD0v55lMGbFlFug219Xa6CW62/sch PP4Lua/UJhx9djUMudKT7gQufn20SMwd1Olt6YL7E15Bo7CUuIC8KZuhwqDO/DTDFBvEKHhZ3 CAk0mOAWVe8mnei7mvPwzbgjzJqIfJeS/I80IKe0mXiN1fwgzvTe1z2dUF+HaO2dW3/UEocdo eEnv8u3kcqX31B0BKg5vvqXU9w7dOuMt7lvKzl+Y4/C3YFqmRLPEUsJA9btlXu/GGbYcbpzsP uKblWt9PVZ3bYQlQC8f/dwp8YYS9B+l1lt6Qt7upLOHHihOZi8D7AFV1vgyjFmktNyJ2rL3N+ EY5y5ShdRbAhWIZy1zcJVZkqW/GIRhGPvrhfc5dvKtynA7kOc+RlyBRXnAufaS5bViNBeD2Ey B5G95GeO3mDlX5tdxQBqVQ9K4mUYenDSzr167Gtd+F07ducM9o8PJzI9PJciHlvR+44IS2kkd EHIBW3wrfgVrtrzBev+4VqxuGvA5k/6nvdAAGCLTZrtgw4k1dlhj69DwGETNTTMjpHY1iMzbE KnGG1f3ttVUQh7tty8Id4By07AgNj7YNTM9ZEakxLVhRHM984h9XxFcgerDJZkrB1PvwzvFHk 52ZIT/+oFxxfLxCkmkc89pEvSA3nrGJ2o4GzYQh7DIB8EOwa7CfLOz7X4XoCFCl0JbZNAllsU B+yYNe1Iu2JoGI3KHj7m2JbEiuRPsW0PmRPxxoEOE8vVNmt+K9Vz9SWfvlh/uBLjQ179sljj0 6Jj82Fk4oXWDyOBizs4lm7Z/q4O4CHwXvEB+zlZ2G6CHq3DmJIDs0mQ3COt+3UVCxgyY5pbt/ 6x+TCVjVPXOUN0PszFKLTe0089GPqJDUwDJy0wSInxpzEcDfzHjKZqSSTMLc/p6Xg7M8c4FCp G1/puhfexfOUqHPYo/anXflg/6E11+0JuQ5m+OVLSa3QW/i6lw+kJpYtTjeFSANluLg0iZA/o Vyb6VeXPwWfDAoaN5cRIVAqOnS4+w8gCtvikhEq+QbmwKY8u847ODtIMptvC5bOUSTopBHNi3 nMDSaB/AV/QbxEo10
Received-SPF: pass client-ip=212.227.15.18; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
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: mimas.w3.org 1jYiZ5-0006JY-DX 4bba699e8bccdde2871688f33de2f382
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/bb3a29ff-1a0f-964d-c764-4d4819d338da@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37615
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 there,

I note that this mail was cc'd to the HTTP WG mailing list
(ietf-http-wg@w3.org), but apparently didn't make it there (see
<https://lists.w3.org/Archives/Public/ietf-http-wg/2020AprJun/>). We
really should find out what went wrong here.

(the same seems to have happened for the LC on
draft-ietf-httpbis-client-hints-13 a few days later)

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

<https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-18#section-4.2>
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).

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.

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.

If it is really intended to forbid that it might be good to add a short
explanation why this is the case.

Best regards, Julian