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

Roberto Peon <grmocg@gmail.com> Thu, 24 January 2013 18:37 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 E5DAA21F8650 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 10:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.317
X-Spam-Level:
X-Spam-Status: No, score=-10.317 tagged_above=-999 required=5 tests=[AWL=0.281, 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 zGFgaC59bXqC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Jan 2013 10:37:14 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E7C7B21F8607 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 24 Jan 2013 10:37: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 1TyReq-0004bh-55 for ietf-http-wg-dist@listhub.w3.org; Thu, 24 Jan 2013 18:36:16 +0000
Resent-Date: Thu, 24 Jan 2013 18:36:16 +0000
Resent-Message-Id: <E1TyReq-0004bh-55@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 1TyRek-0004ax-PY for ietf-http-wg@listhub.w3.org; Thu, 24 Jan 2013 18:36:10 +0000
Received: from mail-lb0-f171.google.com ([209.85.217.171]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1TyRei-0008Oi-MO for ietf-http-wg@w3.org; Thu, 24 Jan 2013 18:36:10 +0000
Received: by mail-lb0-f171.google.com with SMTP id gg13so6263742lbb.30 for <ietf-http-wg@w3.org>; Thu, 24 Jan 2013 10:35: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=a0InPjslx9uVzaTIVqTVKYJIf0x/ArUNI2rDL6Bc6G8=; b=wrd+YpuzXNrsyK4dUvQmZTps3cmTUxtuRSFyq/V0U/UKnDCQilR47SPjJY/igE1gCI P5Eu4L/nILF8NUtf9oWWi+lbLD/LOEhs7PmqZUmgYTcr5kYomyQfCNFwCxzTFzAvITCO wwtG3Lb7KUTYXv3RZBD3pEdxWyKFCvhypuN3ORb5zkB546rP+GcJ1OcyoDGkf61A2+i/ m8ZWoWaizTerXpIIkbMXUm8rK0O+x7VjXZXwdoONGq/JgBqslDamCeVa9ugtFH/b5nyy mgCHeI+e/ImA5cpm8cYHrrGZt/tzooxBiCS6HHNYJRrmaboOA8D8JvJAcr0LjwXnhDLa +gMw==
MIME-Version: 1.0
X-Received: by 10.112.86.67 with SMTP id n3mr1198647lbz.28.1359052541971; Thu, 24 Jan 2013 10:35:41 -0800 (PST)
Received: by 10.112.81.5 with HTTP; Thu, 24 Jan 2013 10:35:41 -0800 (PST)
In-Reply-To: <CAMm+LwgqYmwomf_3XFmqkS9bLTCEAaTt=f9bFuqhTfFzjFk3AQ@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>
Date: Thu, 24 Jan 2013 10:35:41 -0800
Message-ID: <CAP+FsNdbyOjbds9+6rFDtUNkV3dnzX_j=EWosf1Jv-d1-zKGNQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, Julian Reschke <julian.reschke@gmx.de>, Greg Wilkins <gregw@intalio.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="bcaec554e114fecd9c04d40d1393"
Received-SPF: pass client-ip=209.85.217.171; envelope-from=grmocg@gmail.com; helo=mail-lb0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.683, 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 1TyRei-0008Oi-MO 3b00d16541c337daf2de91f7f875fb44
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+FsNdbyOjbds9+6rFDtUNkV3dnzX_j=EWosf1Jv-d1-zKGNQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16169
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>

I think your objections to using SSL are something I'm finding difficult to
understand. You don't like it that SSL cuts off man-in-the-middles?
SSL doesn't prevent a proxy, by the way, it simply requires that one is
configured explicitly instead of being implicit.

I'm also confused that you're advocating both keeping no state and keeping
state (e.g. cookies) at the same time?
-=R


On Thu, Jan 24, 2013 at 9:49 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

>
>
> On Thu, Jan 24, 2013 at 12:34 PM, William Chan (陈智昌) <
> willchan@chromium.org> wrote:
>
>> I think SPDY is simpler for parsing headers in comparison to HTTP/1
>> except for the compression part. Would you agree? Patrick has written
>> up a good comparison here:
>>
>> http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html#c5703739431744738432
>> .
>>
>> Can you clarify what exactly bothers you about piping your messages
>> through a compression library? There are clearly some concerns, but I
>> want to hear what specifically bothers you.
>
>
> The main one is that the receiver has to have enough memory to store the
> dictionary.
>
> That in turn means that the sender has to know whether the receiver has
> enough space which in turn means that they have to have some way of
> negotiating the dictionary size if the result is going to be reliable.
>
>
> As currently specified, SPDY makes no sense to me because the first step
> in SPDY is to essentially short circuit any intermediary or proxy by
> layering over SSL. So now we have a Web browser talking directly to the Web
> Server. So
>
> 1) Every header that has to do with intermediaries just became irrelevant
> 2) There is no reason that the client should send cookies on any request
> after the first
> 3) The content preferences of a browser are unlikely to change either
>
> Seems to me like delta encoding of the header set and converting well
> known headers to tokens is all we need. Coap has already done this work.
>
>
> --
> Website: http://hallambaker.com/
>