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

Matt Menke <mmenke@google.com> Fri, 14 October 2016 19:42 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 35F86129501 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 14 Oct 2016 12:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.896
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-NLBksKamfk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 14 Oct 2016 12:42:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1DE1293DF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 14 Oct 2016 12:42:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bv8J9-0000uU-MP for ietf-http-wg-dist@listhub.w3.org; Fri, 14 Oct 2016 19:38:19 +0000
Resent-Message-Id: <E1bv8J9-0000uU-MP@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1bv8J4-0000tk-Br for ietf-http-wg@listhub.w3.org; Fri, 14 Oct 2016 19:38:14 +0000
Received: from raoul.w3.org ([128.30.52.128]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1bv8J3-0006V9-BF for ietf-http-wg@w3.org; Fri, 14 Oct 2016 19:38:13 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=[192.168.1.37]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1bv8J2-0009NS-S6 for ietf-http-wg@w3.org; 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 <mmenke@google.com>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Thu, 13 Oct 2016 20:53:43 +0000
Content-Transfer-Encoding: quoted-printable
Resent-Date: Fri, 14 Oct 2016 21:38:09 +0200
Resent-To: ietf-http-wg@w3.org
Message-Id: <CAEK7mvoXqyX3cADJytjU+C158EULgPLbzAb5kiUN=8WWxhi29Q@mail.gmail.com>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
To: ietf-http-wg@w3.org
X-Mailer: Apple Mail (2.3226)
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, NML_ADSP_CUSTOM_MED=0.9, RP_MATCHES_RCVD=-0.425, W3C_NW=0.5
X-W3C-Scan-Sig: maggie.w3.org 1bv8J3-0006V9-BF 288f1d45bc65eb348f1ed069d485c5a0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: draft-ietf-httpbis-jfv: what's next
Archived-At: <http://www.w3.org/mid/CAEK7mvoXqyX3cADJytjU+C158EULgPLbzAb5kiUN=8WWxhi29Q@mail.gmail.com>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32587
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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<

Or:

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?