Re: If not JSON, what then ?

Willy Tarreau <w@1wt.eu> Tue, 02 August 2016 14:02 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 C84C312D66E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 2 Aug 2016 07:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.208
X-Spam-Level:
X-Spam-Status: No, score=-8.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 iqUN83UdDg_7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 2 Aug 2016 07:02:05 -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 EA8F612D661 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 2 Aug 2016 07:02:04 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bUZFB-0001bc-PE for ietf-http-wg-dist@listhub.w3.org; Tue, 02 Aug 2016 12:56:25 +0000
Resent-Date: Tue, 02 Aug 2016 12:56:25 +0000
Resent-Message-Id: <E1bUZFB-0001bc-PE@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 1bUZF7-0001ag-H1 for ietf-http-wg@listhub.w3.org; Tue, 02 Aug 2016 12:56:21 +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 1bUZEs-0003VU-U0 for ietf-http-wg@w3.org; Tue, 02 Aug 2016 12:56:16 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id u72CtfNO032239; Tue, 2 Aug 2016 14:55:41 +0200
Date: Tue, 02 Aug 2016 14:55:41 +0200
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20160802125541.GF32124@1wt.eu>
References: <77778.1470037414@critter.freebsd.dk> <12ED69B4-C924-475E-9432-B8FEB4B9DF80@mnot.net> <20160802115355.GD32124@1wt.eu> <ECE83331-ACDD-42E7-B99C-3E4E4C66DD13@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ECE83331-ACDD-42E7-B99C-3E4E4C66DD13@mnot.net>
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.574, 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 1bUZEs-0003VU-U0 906c6bb63c86beb1022f7b33ef746006
X-Original-To: ietf-http-wg@w3.org
Subject: Re: If not JSON, what then ?
Archived-At: <http://www.w3.org/mid/20160802125541.GF32124@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32141
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 Tue, Aug 02, 2016 at 02:41:19PM +0200, Mark Nottingham wrote:
> Not stupid at all, but I am concerned about adding too much "magic"; if
> implementations are doing too much on your behalf, issues will arise (see
> above).

You probably know that I hate magic as well, that's why I prefer to rely
on what we have. For example, passing "connection:" with the new headers
to optimize their eviction along non-compatible paths is doable. It's not
100% safe but doable. Ensuring that compatible actors replace the old
version is doable as well because it would be a "MUST" in the spec and we
know these actors don't exist yet. So all in all we can possibly do useful
things. I just don't want to have a tens of headers being advertised in
Connection nor having to add many extra headers for the sake of saving
space and parsing time, because we know that it will add extra work that
may sometimes offset the savings. Hence the idea to compact what can be
compacted if we went down that route.

Cheers,
Willy