Re: Should Web Services be served by a different HTTP n+1?
Roberto Peon <grmocg@gmail.com> Thu, 24 January 2013 22:26 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 40D3F11E80BA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 14:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.382
X-Spam-Level:
X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 XogMle7Ldeo9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 14:26:25 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id EB9CE11E8099 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 24 Jan 2013 14:26:24 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TyVFC-0007hq-G9 for ietf-http-wg-dist@listhub.w3.org; Thu, 24 Jan 2013 22:26:02 +0000
Resent-Date: Thu, 24 Jan 2013 22:26:02 +0000
Resent-Message-Id: <E1TyVFC-0007hq-G9@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1TyVF7-0007gi-0W for ietf-http-wg@listhub.w3.org; Thu, 24 Jan 2013 22:25:57 +0000
Received: from mail-lb0-f176.google.com ([209.85.217.176]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1TyVF5-0001MW-AC for ietf-http-wg@w3.org; Thu, 24 Jan 2013 22:25:56 +0000
Received: by mail-lb0-f176.google.com with SMTP id s4so4967326lbc.35 for <ietf-http-wg@w3.org>; Thu, 24 Jan 2013 14:25:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=L3R+/yMigV8atXBWP+jlrWR4aOIZFn2agpWXyjDyuI4=; b=gJ3jpDNJoTVuKfwJuTtnmO6BN+sqe7b4OE7AeT8pnYAujCV274G6oQhm7XxFhmzNB5 +Ql7O3eyZWnOAmNZB5kgVJzQP45FerlZ1LCflrkBkoGGd/MNfgd3Tj42EgYIajhsWCsN OXd8PslFuebK1UfBDCYog7NZB9VVHKtwjjEGp6hKp8IrX27crWPRLllkaKKBNMpTeBNa LWinJzkdfhycIO0FFfccI9W99IOiG6Sn1/Ia0Vz3W+6BMTMwLu59Ti0tjBxEP6ASUkKj N1glpY6YHcg/Fu6x8inrW2zRe5+ylnhvTLAf2KzZAMVt/ji+684Sl8gDQ74wqhQHhOI0 lckg==
MIME-Version: 1.0
X-Received: by 10.152.133.52 with SMTP id oz20mr3269683lab.30.1359066328603; Thu, 24 Jan 2013 14:25:28 -0800 (PST)
Received: by 10.112.81.5 with HTTP; Thu, 24 Jan 2013 14:25:28 -0800 (PST)
In-Reply-To: <CAP+FsNe5hOQ=j7VGfUhfYUAj6p8dYiDE6hATtkUwahSi-89mJA@mail.gmail.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> <4613980CFC78314ABFD7F85CC3027721119908B4@IL-EX10.ad.checkpoint.com> <CAP+FsNe5hOQ=j7VGfUhfYUAj6p8dYiDE6hATtkUwahSi-89mJA@mail.gmail.com>
Date: Thu, 24 Jan 2013 14:25:28 -0800
Message-ID: <CAP+FsNfOE4MxwYOo9ELzmyAYH2dfMLJi0mrOnKCUvsL34Sv9Qw@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: Nico Williams <nico@cryptonector.com>, Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="f46d0435c24cbe1d0b04d4104925"
Received-SPF: pass client-ip=209.85.217.176; envelope-from=grmocg@gmail.com; helo=mail-lb0-f176.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.633, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 1TyVF5-0001MW-AC 41276117d014dd7a5714b85c27cd40f7
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/CAP+FsNfOE4MxwYOo9ELzmyAYH2dfMLJi0mrOnKCUvsL34Sv9Qw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16186
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>
And by "people who don't want" I mean implementors who don't wish to implement the full-set of HTTP/2 features, even when many of them get out of the way when you don't want 'em (e.g. the proposed compression stuff). -=R On Thu, Jan 24, 2013 at 2:23 PM, Roberto Peon <grmocg@gmail.com> wrote: > That is the rub-- this forces complexity into every web-application by > forcing devlopers to have to do contingency and error cases for each > potentially optional parameter. > .. essentially, since people cannot rely upon it, they don't use it. This > happens today with HTTP/1 and it.. really sucks. > > This doesn't seem like a good tradeoff when people who don't want these > things or the latency benefit can simply fall-back to HTTP/1 > > -=R > > > On Thu, Jan 24, 2013 at 2:19 PM, Yoav Nir <ynir@checkpoint.com> wrote: > >> 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> 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> wrote: >> >>> >>> On Jan 24, 2013, at 9:01 PM, Nico Williams <nico@cryptonector.com> >>> wrote: >>> >>> > On Thu, Jan 24, 2013 at 12:41 PM, William Chan (陈智昌) >>> > <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 >> >> >> >
- Should Web Services be served by a different HTTP… Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Tim Bray
- Re: Should Web Services be served by a different … James M Snell
- Re: Should Web Services be served by a different … Martin Thomson
- Re: Should Web Services be served by a different … Greg Wilkins
- Re: Should Web Services be served by a different … Grahame Grieve
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Julian Reschke
- Re: Should Web Services be served by a different … Julian Reschke
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Julian Reschke
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Julian Reschke
- Re: Should Web Services be served by a different … William Chan (陈智昌)
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Roberto Peon
- Re: Should Web Services be served by a different … William Chan (陈智昌)
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Julian Reschke
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Julian Reschke
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Mark Nottingham
- Re: Should Web Services be served by a different … Yoav Nir
- Re: Should Web Services be served by a different … Roberto Peon
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Yoav Nir
- Re: Should Web Services be served by a different … Roberto Peon
- Re: Should Web Services be served by a different … Roberto Peon
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … Roberto Peon
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Roberto Peon
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Roberto Peon
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Roberto Peon
- RE: Should Web Services be served by a different … Robert Brewer
- Re: Should Web Services be served by a different … William Chan (陈智昌)
- Re: Should Web Services be served by a different … Nico Williams
- Re: Should Web Services be served by a different … Phillip Hallam-Baker
- Re: Should Web Services be served by a different … William Chan (陈智昌)
- Re: Should Web Services be served by a different … William Chan (陈智昌)
- Re: Should Web Services be served by a different … Julian Reschke
- Re: Should Web Services be served by a different … Julian Reschke
- Re: Should Web Services be served by a different … Hassnaa Moustafa
- Re: Should Web Services be served by a different … Roberto Peon
- Re: Should Web Services be served by a different … Yoav Nir