Re: [hybi] workability (or otherwise) of HTTP upgrade

Zhong Yu <zhong.j.yu@gmail.com> Thu, 09 December 2010 19:41 UTC

Return-Path: <zhong.j.yu@gmail.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B18C3A69A3 for <hybi@core3.amsl.com>; Thu, 9 Dec 2010 11:41:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.061
X-Spam-Level:
X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjNiLzhaqIC7 for <hybi@core3.amsl.com>; Thu, 9 Dec 2010 11:41:13 -0800 (PST)
Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by core3.amsl.com (Postfix) with ESMTP id 650503A6994 for <hybi@ietf.org>; Thu, 9 Dec 2010 11:41:13 -0800 (PST)
Received: by eyg5 with SMTP id 5so2331587eyg.16 for <hybi@ietf.org>; Thu, 09 Dec 2010 11:42:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ruv5ZJqqPbbgx6V8loGxnNXYfn4gH77dphYkoe2kGM4=; b=Zj4ygwKWJMJtg4eSQqtpMK0SMCycFK3eE8Mx3r6kFV8vBANawFDPMqIc+yTDHidi0L j+5KNOXNX2W3JihmCzYpUOR20kDSuQVhzeEBuO6CWm22186IvE085JrdsvZwqHWvaMJV WbBaMVbOO1uQQhfq018pOfvRO+NZbQ9Q0bS4A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ah1JYNLgh3TEDfuTfP1KT2kD3B7Olqa1DEjqT3/P22LXITfwsNaksdjyEHQ6IMuL9m KHV/elZHOCs8QdQ2PHUYjWMSHYn1K1OsDn19mmlJf4Gr0KE47Y/7Q5pyvgCypp2NK8TT syY5RwXWF4B8JT3buTpFPbmBiPsV5H1Wh86qQ=
MIME-Version: 1.0
Received: by 10.213.34.198 with SMTP id m6mr1110874ebd.88.1291923762677; Thu, 09 Dec 2010 11:42:42 -0800 (PST)
Received: by 10.213.16.142 with HTTP; Thu, 9 Dec 2010 11:42:42 -0800 (PST)
In-Reply-To: <4D011146.3080906@caucho.com>
References: <BB947F6D-15AA-455D-B830-5E12C80C1ACD@mnot.net> <81870DB1-B177-4253-8233-52C4168BE99D@apple.com> <F4D1B715-3606-4E9A-BFB2-8B7BC11BE331@mnot.net> <57D4B885-B1D8-482F-8747-6460C0FFF166@apple.com> <37A00E8D-B55C-49AD-A85C-A299C80FFF17@mnot.net> <4F2580A7-79C2-4B0A-BCE5-7FB6D9AA0ED7@apple.com> <BB31C4AB95A70042A256109D461991260583956C@XCH117CNC.rim.net> <EA41A6C7-971C-4EC8-AA6F-96363B7FDC4C@gmail.com> <73E53F19-E0E7-4ADB-B765-ABAF0B4A6736@mnot.net> <r2f0g6d7bj770kg0db5ptr027ninmckns8@hive.bjoern.hoehrmann.de> <20C2FBB9-901F-4235-AF23-EC8262585905@mnot.net> <1291905941.2315.2113.camel@ds9.ducksong.com> <4D011146.3080906@caucho.com>
Date: Thu, 9 Dec 2010 13:42:42 -0600
Message-ID: <AANLkTi=CKU8H5A2f7rSGZ9h5mrp=NZW0yLB9O6=MDW5i@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: Scott Ferguson <ferg@caucho.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: hybi <hybi@ietf.org>
Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2010 19:41:14 -0000

On Thu, Dec 9, 2010 at 11:26 AM, Scott Ferguson <ferg@caucho.com> wrote:
> When the draft used GET+Upgrade, servers could reuse things like the HTTP
> authentication, cookie headers, etc., and reuse the existing protocol stack

I believe HTTP cookies shouldn't be included in WS, and I'll make that
case in time.

http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html
HTTP cookie is a mess, we don't want to introduce that mess to WS. And
even worse, if WS interacts with cookies too, it will add yet another
dimension of  complexity to the existing mess. HTTP is connection-less
in spirit, WS is connection-ful and stateful in nature, some benefits
of cookies to HTTP don't apply to WS. If an app needs to transmit HTTP
cookies to WS app, it's easy to do without any help from WS protocol.
If we must have a persistent tag for different WS connections from
same user, we can introduce a much simpler and cleaner mechanism. But
say no to cookies.

- Zhong