Re: The use of binary data in any part of HTTP 2.0 is not good

Mark Nottingham <mnot@mnot.net> Sun, 20 January 2013 23:49 UTC

Return-Path: <ietf-http-wg-request@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 8680421F8972 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 20 Jan 2013 15:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.95
X-Spam-Level:
X-Spam-Status: No, score=-7.95 tagged_above=-999 required=5 tests=[AWL=0.050, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bD3p-f5+HqR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 20 Jan 2013 15:49:11 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AE93221F886E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 20 Jan 2013 15:49:10 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Tx4dG-00051x-87 for ietf-http-wg-dist@listhub.w3.org; Sun, 20 Jan 2013 23:48:58 +0000
Resent-Date: Sun, 20 Jan 2013 23:48:58 +0000
Resent-Message-Id: <E1Tx4dG-00051x-87@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1Tx4dC-00051I-KL for ietf-http-wg@listhub.w3.org; Sun, 20 Jan 2013 23:48:54 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1Tx4dB-0000sI-W9 for ietf-http-wg@w3.org; Sun, 20 Jan 2013 23:48:54 +0000
Received: from mnot-mini.mnot.net (unknown [118.209.240.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5A81122E1F3; Sun, 20 Jan 2013 18:48:31 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <em670f0a0f-3c5a-4f99-88cb-03bd4234ce63@bombed>
Date: Mon, 21 Jan 2013 10:48:30 +1100
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, Pablo <paa.listas@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F8E363D-6D6E-4FDD-B8EA-24A31383B1A3@mnot.net>
References: <em670f0a0f-3c5a-4f99-88cb-03bd4234ce63@bombed>
To: "Adrien W. de Croy" <adrien@qbik.com>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-2.291, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Tx4dB-0000sI-W9 3363140ef1eeaa68c25780b96fba22d9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: The use of binary data in any part of HTTP 2.0 is not good
Archived-At: <http://www.w3.org/mid/7F8E363D-6D6E-4FDD-B8EA-24A31383B1A3@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16060
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 21/01/2013, at 10:38 AM, "Adrien W. de Croy" <adrien@qbik.com> wrote:

> 
> the thing that will make debugging harder won't be binary vs text, but the inter-dependence of messages.  Especially when it comes to looking through debug logs for issues.
> 
> On-the-wire, you already need to piece together a TCP stream to see what's going on, so having http messages effectively split over multiple frames (e.g. delta encoding, or compression) only becomes a problem when you don't capture enough to decode.
> 
> I think it might be worth-while specifying a requirement for a "debug" option for senders of binary messages which turns off all other optimisations, such as caching unchanged headers etc (so they are sent every time).  Just an idea.

That's been brought up a few times, and the reaction has been pretty positive.

Cheers,


--
Mark Nottingham   http://www.mnot.net/