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

Patrick McManus <mcmanus@ducksong.com> Mon, 21 January 2013 15:06 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 E939C21F8826 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 21 Jan 2013 07:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.976
X-Spam-Level:
X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 4mLGeQtlLyqB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 21 Jan 2013 07:06:06 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F337121F8820 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 21 Jan 2013 07:06:05 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TxIvc-0007Vi-Uq for ietf-http-wg-dist@listhub.w3.org; Mon, 21 Jan 2013 15:04:52 +0000
Resent-Date: Mon, 21 Jan 2013 15:04:52 +0000
Resent-Message-Id: <E1TxIvc-0007Vi-Uq@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1TxIvO-0007UH-JI for ietf-http-wg@listhub.w3.org; Mon, 21 Jan 2013 15:04:38 +0000
Received: from mail-oa0-f49.google.com ([209.85.219.49]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1TxIvJ-0002Md-Mp for ietf-http-wg@w3.org; Mon, 21 Jan 2013 15:04:38 +0000
Received: by mail-oa0-f49.google.com with SMTP id l10so6060391oag.22 for <ietf-http-wg@w3.org>; Mon, 21 Jan 2013 07:04:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UZtNLk22/NjBPG6F3HaePUs5gXQ3OL4LMgaI7HTx8Qg=; b=V9Qow9ALly5Bjkv7JLNOwxyeMF8t6rgoQrd6L1YgacRL+5cBqWX2pX98rGfpX+T+H2 NJ0J6JpdrwduVA3D+X1YswDVW5FKQymBCO0H65dHG4Dn3na8bd4/ZYpIzubddxuKKS4f 5Z+sIbk74nKgXcXIhJ6I5Gz/K9mCUu7XzdrX0LVFQ6lM1kocB+WRLcRUNnZ9kUrkItDq snOZznBGsm0zpX/g4Q22u/wv0x3KH7vG6Ln/R42px+RRa28Gc3UYSZ/dOY776m0qwrk/ WuerVO5rQQpkhKf9p3GRIPtMT1XebF1wfMSz5DwP38H4Tt9XEi+YM05TaM0kZ7U2fV5J TdUQ==
MIME-Version: 1.0
X-Received: by 10.60.12.103 with SMTP id x7mr9866645oeb.56.1358780647775; Mon, 21 Jan 2013 07:04:07 -0800 (PST)
Sender: patrick.ducksong@gmail.com
Received: by 10.76.132.165 with HTTP; Mon, 21 Jan 2013 07:04:07 -0800 (PST)
In-Reply-To: <CAP+FsNfMKT02nwX-i1LYARcjhQH3sNotkzaJH4sY0YQmHk2WcA@mail.gmail.com>
References: <CAAZO4q4vEiYhH5FaX2XCxXox9jkf4dLTy8coQZiE+CYHA-QzBg@mail.gmail.com> <CAA4WUYhkVBRAyY1O32aOiWB8=46SBidFOjKH+e7PGbB7mKzmiQ@mail.gmail.com> <DC03C924-9DCC-45CE-B9DB-5906EADAF9C4@mnot.net> <CAHBU6iuaeAeTrz6TSOyhNvW2pXWgQB_RQ+6MYAb9DyJUZ00Rcg@mail.gmail.com> <CAP+FsNfMKT02nwX-i1LYARcjhQH3sNotkzaJH4sY0YQmHk2WcA@mail.gmail.com>
Date: Mon, 21 Jan 2013 10:04:07 -0500
X-Google-Sender-Auth: Nc0pU2HXVeFZwdNMQKEFqQlA5-Q
Message-ID: <CAOdDvNpfd_DwGgv2gzuAjHZ++8_oJaK1VRvoRiQBkXyrgY5-yA@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Tim Bray <tbray@textuality.com>, Will Chan <willchan@chromium.org>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Pablo <paa.listas@gmail.com>
Content-Type: multipart/alternative; boundary="e89a8fb20570d69e9204d3cdc591"
Received-SPF: pass client-ip=209.85.219.49; envelope-from=patrick.ducksong@gmail.com; helo=mail-oa0-f49.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.711, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1TxIvJ-0002Md-Mp a772ff054d7c2cffa60e40b857e5685c
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/CAOdDvNpfd_DwGgv2gzuAjHZ++8_oJaK1VRvoRiQBkXyrgY5-yA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16082
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 Sun, Jan 20, 2013 at 6:47 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Text formats are, surprisingly, not easier to debug in my experience.
>
> +1

Beyond debugging, text formats are actually ridiculously hard to get
consistently right - partially because they lend themselves too well to "be
liberal in what you receive policies". HTTP/1 has suffered from  CRLF
injection attacks, content-length bounds check failures, a wide variety of
line ending interop problems, etc..  all of which are derived from its text
roots. Sometimes these problems are unforseen spec issues, but sometimes
they are just derived from assumptions people have because the text format
feels more intuitive than it really is.

While text is convenient to eyeball, it is much harder to get unambiguously
correct especially in a open multiple implementation environment. 32 bits
of big endian is well defined and well bounded; a text string that
represents a quantity requires a lot more information to correctly
interpret.

http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html#c5703739431744738432

Frankly, I'd rather talk about byte order.. imo this is an application
level protocol that 98% of the time is going to be consumed by little
endian processors and could easily be defined that way. This of course runs
against tradition and isn't a huge deal computationally, but I'm not aware
of other arguments against giving the byte swap operation of our processors
a day off.