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

Yoav Nir <ynir@checkpoint.com> Thu, 24 January 2013 22:21 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 87C4B21F857C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 14:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 1G7TUuCWNMCL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 14:21:01 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6C57411E8099 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 24 Jan 2013 14:21: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 1TyV9p-00051X-UW for ietf-http-wg-dist@listhub.w3.org; Thu, 24 Jan 2013 22:20:29 +0000
Resent-Date: Thu, 24 Jan 2013 22:20:29 +0000
Resent-Message-Id: <E1TyV9p-00051X-UW@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ynir@checkpoint.com>) id 1TyV9j-00050n-Vs for ietf-http-wg@listhub.w3.org; Thu, 24 Jan 2013 22:20:24 +0000
Received: from smtp.checkpoint.com ([194.29.34.68]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <ynir@checkpoint.com>) id 1TyV9g-00019z-VN for ietf-http-wg@w3.org; Thu, 24 Jan 2013 22:20:23 +0000
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0OMJp5S031510; Fri, 25 Jan 2013 00:19:51 +0200
X-CheckPoint: {5101B088-0-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([194.29.34.150]) with mapi id 14.02.0328.009; Fri, 25 Jan 2013 00:19:51 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Roberto Peon <grmocg@gmail.com>
CC: Nico Williams <nico@cryptonector.com>, Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Thread-Topic: Should Web Services be served by a different HTTP n+1?
Thread-Index: AQHN8DdCevU3c+qlbE+yorjaEbKuDphXtuWAgADT9oCAAAVpgIAAAi0AgAAdtQCAAAQugIAADoEAgAAFjoCAADMRgIAAAUwAgAADIoA=
Date: Thu, 24 Jan 2013 22:19:50 +0000
Message-ID: <4613980CFC78314ABFD7F85CC3027721119908B4@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> <CAP+FsNfB2WPkMTtjzVeJbuQPrz_srRm8ReGnx4WQi4LGmJ2Xzw@mail.gmail.com>
In-Reply-To: <CAP+FsNfB2WPkMTtjzVeJbuQPrz_srRm8ReGnx4WQi4LGmJ2Xzw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.133]
Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC3027721119908B4ILEX10adcheckpo_"
MIME-Version: 1.0
Received-SPF: pass client-ip=194.29.34.68; envelope-from=ynir@checkpoint.com; helo=smtp.checkpoint.com
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: AWL=-0.760, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1TyV9g-00019z-VN 836a96093fb87d91b05b66f6adc59458
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/4613980CFC78314ABFD7F85CC3027721119908B4@IL-EX10.ad.checkpoint.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16183
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>

It might end up smaller than what you need for an HTTP/1 client. But that also allows us to implement just one protocol on the server for both full-capability and minimal clients. Similarly for full-capabilities client working with minimal servers.

On Jan 25, 2013, at 12:08 AM, Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:

So... why would someone who didn't want these things use HTTP/2 instead of HTTP/1?

-=R


On Thu, Jan 24, 2013 at 2:03 PM, Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>> wrote:

On Jan 24, 2013, at 9:01 PM, Nico Williams <nico@cryptonector.com<mailto:nico@cryptonector.com>> wrote:

> On Thu, Jan 24, 2013 at 12:41 PM, William Chan (陈智昌)
> <willchan@chromium.org<mailto:willchan@chromium.org>> wrote:
>>> The main one is that the receiver has to have enough memory to store the
>>> dictionary.
>>
>> I think this boils down to the argument on the other thread. Do the
>> gains for keeping state outweigh the costs? Note that given Roberto's
>> delta compression proposal, the sender can disable compression
>> entirely, so the receiver does not need to maintain state. Browsers
>> probably would not do this, due to our desire to optimize for web
>> browsing speed. For web services where you control the client, you
>> indeed would be able to disable compression.
>
> 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

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

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

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

Yoav




Email secured by Check Point