Re: Should Web Services be served by a different HTTP n+1?
Roberto Peon <grmocg@gmail.com> Thu, 24 January 2013 22:55 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 42A941F0CDF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 14:55:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.423
X-Spam-Level:
X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.175, 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 ALOezLyUzs43 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 14:55:13 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1321F84F6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 24 Jan 2013 14:55:13 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TyVga-00074I-GM for ietf-http-wg-dist@listhub.w3.org; Thu, 24 Jan 2013 22:54:20 +0000
Resent-Date: Thu, 24 Jan 2013 22:54:20 +0000
Resent-Message-Id: <E1TyVga-00074I-GM@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1TyVgS-00073T-Ml for ietf-http-wg@listhub.w3.org; Thu, 24 Jan 2013 22:54:12 +0000
Received: from mail-lb0-f173.google.com ([209.85.217.173]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1TyVgO-0002gX-UO for ietf-http-wg@w3.org; Thu, 24 Jan 2013 22:54:12 +0000
Received: by mail-lb0-f173.google.com with SMTP id gf7so7320029lbb.18 for <ietf-http-wg@w3.org>; Thu, 24 Jan 2013 14:53:42 -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=EcxaKBrgk0sTtRVYjnoNzsh9bIhQQX+G6Lcitn3ghXw=; b=I2ngGqGFboAHQG0sgfqitqqglyLJpZzXxSontennDQ1yQOsXlyPWUC/jN9UVCySrtL ol5CPooiBPm7tolb0PwYsligEmMcVeSjvACw/sAItcupWFWZlAQTYBWKi/92/HDqA/2i N1U6g2YZKu0yi880T0dMtmr5jvqssl1W3pOobwSWzSYz31+7Tf3qZgOwuCo7dJeukR+r yrDRDaXEawZQj76/xdwvyn7pmEQKNUGUeNFp+fmLefvI1jjXohC7C0k9l5kH/ynFDcst 6h/7+7CcZeJbkBqoONIiL3R6h/XPIo14zvelBEllT5zIZsd3sObcbGA3AvI4h3Jb/pIy Prbw==
MIME-Version: 1.0
X-Received: by 10.112.51.44 with SMTP id h12mr1375048lbo.111.1359068022006; Thu, 24 Jan 2013 14:53:42 -0800 (PST)
Received: by 10.112.81.5 with HTTP; Thu, 24 Jan 2013 14:53:41 -0800 (PST)
In-Reply-To: <CAP+FsNfAfdP3_0oZpozYr-+xaCpVUgS28uKXM1uG9VKOL9br8Q@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> <CAMm+Lwja9+LMwH8jdKYJqTheGKAHmWX+bCGkVUz3ocMKnjn1HQ@mail.gmail.com> <CAP+FsNfAfdP3_0oZpozYr-+xaCpVUgS28uKXM1uG9VKOL9br8Q@mail.gmail.com>
Date: Thu, 24 Jan 2013 14:53:41 -0800
Message-ID: <CAP+FsNdaEAwJ1Dk=pA2-59X_eN9rg3ApdsAucVq91Keb_QXvtQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: Yoav Nir <ynir@checkpoint.com>, Nico Williams <nico@cryptonector.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="f46d04017147ad65e804d410ae4f"
Received-SPF: pass client-ip=209.85.217.173; envelope-from=grmocg@gmail.com; helo=mail-lb0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.539, 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: maggie.w3.org 1TyVgO-0002gX-UO fb02c1374054bc54400ef5d8e78c61b0
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+FsNdaEAwJ1Dk=pA2-59X_eN9rg3ApdsAucVq91Keb_QXvtQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16194
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>
Sorry to add to what I was saying: The worst part is the high latency, especially given TCP's current cogestion avoidance implementations-- the total number of round-trips ends up dominating latency, regardless of how much bandwidth one has. -=R On Thu, Jan 24, 2013 at 2:46 PM, Roberto Peon <grmocg@gmail.com> wrote: > Well, the web has changed a lot since its inception when pages were mostly > a single resource. Now, we're nearly fetching a 100 resources per page, and > myriad people make money from it. > I think that the decision to ignore compression in the beginning was a > correct one. Now, however, the headers are causing more than acceptable > latency impediments to page loads, especially on the devices which are > becoming the most prevalent (mobile devices with relatively high latency, > and low bandwidth). > > I'm still confused about how what has been proposed would force > WebServices to fork. > Placing myself in your and Nico's imagined shoes, it still sounds like > forking would take more effort than taking someone's compression library > and hooking it in as appropriate, especially given that the overall memory > and CPU cost of doing so would be between negligible and zero. > > Are you worried about devices with extremely limited code-space/memory? > > -=R > > > On Thu, Jan 24, 2013 at 2:36 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote: > >> So don't do header compression, do a tokenization approach that does not >> cause Web Services to fork. >> >> If Web Services can't use 2.0 then you have forked the protocol whether >> they do that by continuing to use 1.1 or by developing a new protocol. >> >> Not that there would be any difference in practice since if HTTP/2.0 does >> not support Web Services in a sane fashion there will eventually be a 2.0 >> for Web Services. >> >> >> We did know about compression libraries back in '92. Latency was a much >> bigger concern back in those days when the whole of CERN was hanging off a >> not much more than a T1 and we had 10base ethernet. >> >> The idea of header compression was rejected back then as a silly >> optimization and I really can't understand why anyone thinks the situation >> has changed to make it less silly. >> >> On Thu, Jan 24, 2013 at 5: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 >>>> >>>> >>>> >>> >> >> >> -- >> Website: http://hallambaker.com/ >> > >
- 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