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

Willy Tarreau <w@1wt.eu> Sat, 15 October 2016 21:39 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 070ED129586 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 15 Oct 2016 14:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.332
X-Spam-Level:
X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, 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 55bg9UTTDgS7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 15 Oct 2016 14:39:57 -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 6307B129529 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 15 Oct 2016 14:39:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bvWcT-0006XK-Ah for ietf-http-wg-dist@listhub.w3.org; Sat, 15 Oct 2016 21:35:53 +0000
Resent-Date: Sat, 15 Oct 2016 21:35:53 +0000
Resent-Message-Id: <E1bvWcT-0006XK-Ah@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 <w@1wt.eu>) id 1bvWcP-0006Wb-7P for ietf-http-wg@listhub.w3.org; Sat, 15 Oct 2016 21:35:49 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from <w@1wt.eu>) id 1bvWcM-00018z-Rj for ietf-http-wg@w3.org; Sat, 15 Oct 2016 21:35:48 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id u9FLZJec028610; Sat, 15 Oct 2016 23:35:19 +0200
Date: Sat, 15 Oct 2016 23:35:19 +0200
From: Willy Tarreau <w@1wt.eu>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Martin Thomson <martin.thomson@gmail.com>, Matt Menke <mmenke@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20161015213519.GA28177@1wt.eu>
References: <CAEK7mvoXqyX3cADJytjU+C158EULgPLbzAb5kiUN=8WWxhi29Q@mail.gmail.com> <78301.1476524467@critter.freebsd.dk> <CABkgnnXw7WacnMf4Nsx-drktn__V4afK61G67A5bT5SSdqaucQ@mail.gmail.com> <79226.1476546544@critter.freebsd.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <79226.1476546544@critter.freebsd.dk>
User-Agent: Mutt/1.6.0 (2016-04-01)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.575, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bvWcM-00018z-Rj 89657450e56802f2744fe305ea64e7ff
X-Original-To: ietf-http-wg@w3.org
Subject: Re: draft-ietf-httpbis-jfv: what's next
Archived-At: <http://www.w3.org/mid/20161015213519.GA28177@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32605
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>

On Sat, Oct 15, 2016 at 03:49:04PM +0000, Poul-Henning Kamp wrote:
> --------
> In message <CABkgnnXw7WacnMf4Nsx-drktn__V4afK61G67A5bT5SSdqaucQ@mail.gmail.com>
> , Martin Thomson writes:
> >On 15 October 2016 at 20:41, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> >> Looking forward, if we want to be able to use CS to build H3
> >> compression, we cannot allow CS headers with format errors.
> >
> >I tend to agree with this, though there are levels of format errors.
> >For instance, if you use the >< notation and the < is absent, that's a
> >flat parse error (I would argue that the < is redundant actually, save
> >an octet).
> 
> It is redundant, but it might still be a good idea.
> 
> Truncation of headers happens a lot more than it should in the wild,
> so apart from the recursive role of the '<' I do like that it also
> tells you that you are not missing half the header.

And it also helps when headers are duplicated. Below it's becoming
obvious what type of duplication happened, and where :

     Foo1: >blah<, >bar<
     Foo2: >blah, bar<

> >But what I think that Matt is looking for is a grammar that supports
> >an in-band signal about type so that syntax checking can be done by
> >the parser (and not by the semantics layer).  That - to me - seems
> >like a pretty reasonable request.
> 
> Yes, I agree, but it runs into the very inclusive definition of
> RFC7230::token.
> 
> We need three markers: '(h1_)number', 'h1_timestamp' and 'h1_blob',
> which are all valid 'identifier' (= RFC7230::token) today.
> 
> We have three options:
> 
> 1. Keep using RFC7230::token for 'identifier'
(...)
> 2. Restrict 'identifier'
(...)
> 3. Let the semantic layer sort it out.
(...)

> I picked 3 based on 'minimum intrusiveness', but I can live with
> all three.

And what about #4 consisting in indicating the encoding in the header
field *name* instead, since we're suggesting to use this for new fields ?
It could be possible to prepend something like "-1", "-2", etc... in front
of the field name to indicate its expected type and how it's supposed to
be decoded, and reserve such fields' name syntax only for these typed
header fields.

Just my two cents,
Willy