Re: draft-ietf-httpbis-jfv: what's next

Matt Menke <> Fri, 14 October 2016 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35F86129501 for <>; Fri, 14 Oct 2016 12:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.896
X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F-NLBksKamfk for <>; Fri, 14 Oct 2016 12:42:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB1DE1293DF for <>; Fri, 14 Oct 2016 12:42:19 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bv8J9-0000uU-MP for; Fri, 14 Oct 2016 19:38:19 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bv8J4-0000tk-Br for; Fri, 14 Oct 2016 19:38:14 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bv8J3-0006V9-BF for; Fri, 14 Oct 2016 19:38:13 +0000
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bv8J2-0009NS-S6 for; Fri, 14 Oct 2016 19:38:13 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Matt Menke <>
Resent-From: Yves Lafon <>
Date: Thu, 13 Oct 2016 20:53:43 +0000
Content-Transfer-Encoding: quoted-printable
Resent-Date: Fri, 14 Oct 2016 21:38:09 +0200
Message-Id: <>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
X-Mailer: Apple Mail (2.3226)
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Scan-Sig: 1bv8J3-0006V9-BF 288f1d45bc65eb348f1ed069d485c5a0
Subject: Re: draft-ietf-httpbis-jfv: what's next
Archived-At: <>
X-Mailing-List: <> archive/latest/32587
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I think the draft looks good, but have a couple comments:

The token rule in RFC7230 already includes asterisks, so I don't think identifier or token_or_asterix is needed.

Would it make sense to codify behavior if a part of a h1_common_structure value fails to parse, at least if it uses the proposed "><" format)?  I suspect what browsers do is inconsistent here, and having some official rule (ignore the entire element vs ignore the entire line vs ignore the broken parameter) seems like it would be worth having?  I'd go with throw away the entire header line, if it uses the new format and that happens, since that's easiest to standardize on.

I think it's unfortunate that the HTTP/1 serialization can't distinguish between identifiers, numbers, and timestamps.  It means that per-specific-header logic will have to be responsible for that extra round of parsing for HTTP/1 headers.  If H2/QUIC goes with a fancier binary encoding scheme that doesn't have that issue, that means that those formats would not have to do the extra found of parsing, which seems a bit weird, but I don't see a good way around that asymmetry.

On single/multiple headers:  The draft has a comment about this, but it doesn't really comment on whether the following is legal:

Foo: >bar<
Foo: >baz<


Foo: >bar<, >baz<

According to Chrome's current logic, both would be valid and are equivalent (Assuming >< is treated like quotes, with extra logic for nested quotes, and "Foo" isn't one of a small set of non-coalescing headers).  Is different behavior intended in these two cases?