Re: HTTP/2.0 Magic

Willy Tarreau <w@1wt.eu> Tue, 19 February 2013 06:59 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 4CE2421F8D63 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 18 Feb 2013 22:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.231
X-Spam-Level:
X-Spam-Status: No, score=-10.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, 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 E5EDrveNBbH6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 18 Feb 2013 22:59:29 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C0AB621F8D02 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 18 Feb 2013 22:59:29 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U7h9w-0006OK-1S for ietf-http-wg-dist@listhub.w3.org; Tue, 19 Feb 2013 06:58:36 +0000
Resent-Date: Tue, 19 Feb 2013 06:58:36 +0000
Resent-Message-Id: <E1U7h9w-0006OK-1S@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1U7h9o-0006NJ-C5 for ietf-http-wg@listhub.w3.org; Tue, 19 Feb 2013 06:58:28 +0000
Received: from 1wt.eu ([62.212.114.60]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1U7h9n-0000Br-9k for ietf-http-wg@w3.org; Tue, 19 Feb 2013 06:58:28 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r1J6vumN027996; Tue, 19 Feb 2013 07:57:56 +0100
Date: Tue, 19 Feb 2013 07:57:56 +0100
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20130219065756.GB26186@1wt.eu>
References: <CABkgnnV1AqvPk3513rReH-rktYuxf9zDTHpQT9agfZgKrqF_aw@mail.gmail.com> <8F582448-A298-4BC0-A843-ACA4354AB109@gbiv.com> <641194C3-9EF5-4B67-BFB6-6605983ED6A0@mnot.net> <20130219062100.GA26186@1wt.eu> <5C517A54-2C3D-40C3-8C87-C1A362F6CC70@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5C517A54-2C3D-40C3-8C87-C1A362F6CC70@mnot.net>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.747, RP_MATCHES_RCVD=-0.554, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1U7h9n-0000Br-9k 22935041460007340822aae4286dee27
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2.0 Magic
Archived-At: <http://www.w3.org/mid/20130219065756.GB26186@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16681
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, Feb 19, 2013 at 05:24:02PM +1100, Mark Nottingham wrote:
> > However, I remember that when the same approach was proposed on hybi, one
> > of the concerns that was raised was that some servers will happily return
> > a valid response and may corrupt intermediary caches. I remember that about
> > all intermediary implementations authors explained that no cache will ignore
> > the method in the request, but still that was a concern that plagued the
> > design.
> 
> I'm not convinced it's a concern.

I'm convinced it's not. But I mentionned this so that we get prepared
to see such comments come back again.

> > We should absolutely not have a "banner protocol".
> 
> Definitely not; question is whether the server prepends something to the
> start of the framing layer.

I'm only seeing two valid reasons for prepending something :
  1) if the frame encoding is compact enough to use all bits and make
     an HTTP/1 response look like a possibly valid frame which the
     client must parse, we'd prefer to avoid this useless work ;
  2) if the frame can be tailored to look like an HTTP/1 response,
     we'd prefer to avoid the possibility that this is triggered from
     the client.

So maybe something looking like an HTTP/1 error may be useful then
(eg: "HTTP/1.0 505 V2ONLY CRLF CRLF").

Willy