Re: Should Web Services be served by a different HTTP n+1?

Nico Williams <nico@cryptonector.com> Thu, 24 January 2013 22:19 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 36C8611E8099 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 14:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.032
X-Spam-Level:
X-Spam-Status: No, score=-7.032 tagged_above=-999 required=5 tests=[AWL=2.945, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 D5nNUZ8G5Xzc for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 14:19:00 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5E40F21F857C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 24 Jan 2013 14:19:00 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TyV7j-0003Wv-1E for ietf-http-wg-dist@listhub.w3.org; Thu, 24 Jan 2013 22:18:19 +0000
Resent-Date: Thu, 24 Jan 2013 22:18:19 +0000
Resent-Message-Id: <E1TyV7j-0003Wv-1E@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <nico@cryptonector.com>) id 1TyV7d-0003W5-4c for ietf-http-wg@listhub.w3.org; Thu, 24 Jan 2013 22:18:13 +0000
Received: from caiajhbdcagg.dreamhost.com ([208.97.132.66] helo=homiemail-a87.g.dreamhost.com) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <nico@cryptonector.com>) id 1TyV7a-00015T-8T for ietf-http-wg@w3.org; Thu, 24 Jan 2013 22:18:13 +0000
Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id D9B7426C073 for <ietf-http-wg@w3.org>; Thu, 24 Jan 2013 14:17:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FINx8ZVS4z2qbjm6d0ws OnBTdEg=; b=qG8BWtQ6wVJiE4qwglJOfnamD6IDnBntBn/xYOti2HJ6w+9LAtTA NzhSGQlF5wUmafO5j84OTncEQqpnRGEk/Bk+n9TvSr8iu0Pzd/zK1JpGY+6cQ0b9 pkc1iG6yzrTLkSokv3d+zHDRtxg8LS41Fl0DcZLcFuDeI29r++Miets=
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 7CBA826C069 for <ietf-http-wg@w3.org>; Thu, 24 Jan 2013 14:17:48 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id t11so3076953wey.14 for <ietf-http-wg@w3.org>; Thu, 24 Jan 2013 14:17:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.77.13 with SMTP id o13mr5604481wjw.58.1359065867281; Thu, 24 Jan 2013 14:17:47 -0800 (PST)
Received: by 10.217.39.133 with HTTP; Thu, 24 Jan 2013 14:17:47 -0800 (PST)
In-Reply-To: <4613980CFC78314ABFD7F85CC302772111990734@IL-EX10.ad.checkpoint.com>
References: <CAMm+LwgTSw05QLUspAbAyRSWfd8j27fhwPiDSF_TaD8LevftBA@mail.gmail.com> <CAH_y2NEPLt=GkO575MfCi2aW4X+w40CzOVB05Z1+_rmLMXXSpw@mail.gmail.com> <CAMm+LwhJvSXgPzdqv2GscD-mfR4O7R_bba5JnAbdmP+uR+6SYA@mail.gmail.com> <510155E3.5020208@gmx.de> <CAMm+LwhCtd-m5uJnv+vcTTq9WcR3bEDQndV2cZqQE1ApNasCXA@mail.gmail.com> <CAA4WUYh3uP228QKjMwtTT2QQb9ypijdHPY-CkZF36j6DuTH4+A@mail.gmail.com> <CAMm+LwgqYmwomf_3XFmqkS9bLTCEAaTt=f9bFuqhTfFzjFk3AQ@mail.gmail.com> <CAA4WUYj3rDUQQ4crdyJrun=2-MwOGQ32qRfv5oJKrx=JciqOCA@mail.gmail.com> <CAK3OfOhbOnCHCp7fKeG6QLKcdoYhAXcL1nkW6220+9xb-W5Gyw@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772111990734@IL-EX10.ad.checkpoint.com>
Date: Thu, 24 Jan 2013 16:17:47 -0600
Message-ID: <CAK3OfOibmHdBnYnXzbXxag+2ATkFVxEyfzPuT+ywXRO09ZSBRQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: none client-ip=208.97.132.66; envelope-from=nico@cryptonector.com; helo=homiemail-a87.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-3.217, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: lisa.w3.org 1TyV7a-00015T-8T ea11b3d6e0a9f5c3c39601f3649aaf2f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Should Web Services be served by a different HTTP n+1?
Archived-At: <http://www.w3.org/mid/CAK3OfOibmHdBnYnXzbXxag+2ATkFVxEyfzPuT+ywXRO09ZSBRQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16182
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 Thu, Jan 24, 2013 at 4:03 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> On Jan 24, 2013, at 9:01 PM, Nico Williams <nico@cryptonector.com> wrote:
>> IMO we need stateful compression to be absolutely optional to
>> implement.  (If we choose to go with stateful compression in the first
>> place.  I think we shouldn't.)
>
> I think we need to do a little more. I think we should define a "minimal implementation" and have a way for client and server to signal this. A minimal implementation would not be able to do any or some of these:
>  - compression
>  - server-initiated streams
>  - stream priority
>  - credentials
>  - all but a small set of headers.
>  - multiple concurrent streams

As long as each can negotiate all-but-stateful-compression I'm happy.
I'd strongly object to having to forego the other things in order to
forego stateful compression.

Also, while we are this, IMO we should first produce minimal encodings
of headers and values where that's meaningful, *then* add optional
stateful compression.

> Maybe we need a CAPABILITIES control frame that will allow client or server to communicate to the other what capabilities they don't have.

Sure, but that's definitely something that had better have either
minimal encoding... or be statfully compressed.  Ugh.  Of course "no
state here" is a tiny -and therefore reasonable- amount of state.

> A truly minimal client would be capable of one stream at a time - really down to HTTP/1.0 functionality with the new syntax.

But that's not what I'm after.  I'm after the option to not implement
stateful compression.  I'm not saying the other things have to be
optional to implement -- I might, after further reading, but for now I
don't.

> Would this allow Phillip to use HTTP/2 for minimalist web services?

See my comment about minimal encodings.  Assuming we have that we'd
still have a sizeable improvement even without stateful compression,
and that would be a reason to want to use HTTP/2.0 without stateful
compression.

Nico
--