IETF Logo Mail Archive

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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 10 December 2010 09:47 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 A67D03A6C93 for <hybi@core3.amsl.com>; Fri, 10 Dec 2010 01:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.174
X-Spam-Level:
X-Spam-Status: No, score=-100.174 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 oxWzT89WCZeJ for <hybi@core3.amsl.com>; Fri, 10 Dec 2010 01:47:30 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 467AC3A6C92 for <hybi@ietf.org>; Fri, 10 Dec 2010 01:47:29 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id oBA9mt6k003062 for <hybi@ietf.org>; Fri, 10 Dec 2010 18:48:55 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 4329_9ff2_b3e8179c_0442_11e0_8664_001d096c566a; Fri, 10 Dec 2010 18:48:55 +0900
Received: from [IPv6:::1] ([133.2.210.1]:36359) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S149E1F5> for <hybi@ietf.org> from <duerst@it.aoyama.ac.jp>; Fri, 10 Dec 2010 18:48:56 +0900
Message-ID: <4D01F77B.60100@it.aoyama.ac.jp>
Date: Fri, 10 Dec 2010 18:48:43 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John Tamplin <jat@google.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> <AANLkTi=CKU8H5A2f7rSGZ9h5mrp=NZW0yLB9O6=MDW5i@mail.gmail.com> <AANLkTimg774w-JVExm4YQJzuBv3gaJZOLMo5OymDsMiE@mail.gmail.com> <op.vng1ixmaidj3kv@dhcp-190.linkoping.osa> <AANLkTi=Ow=hGxwuOdMBtfmm2mBnYHK3d5TLRMkrpK_kd@mail.gmail.com>
In-Reply-To: <AANLkTi=Ow=hGxwuOdMBtfmm2mBnYHK3d5TLRMkrpK_kd@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Fri, 10 Dec 2010 09:47:31 -0000

On 2010/12/10 9:48, John Tamplin wrote:
> On Thu, Dec 9, 2010 at 7:12 PM, Simon Pieters<simonp@opera.com>  wrote:
>
>> But what is the use case for cookies in WebSockets? (If it has been
>> discussed before then I have missed it and would appreciate pointers.)
>>
>
> Simply that applications split between HTTP and WebSockets are likely to
> want to share that data.  If you don't include cookies, then you force every
> app to reinvent the wheel of how to transfer their session ID/etc.

Another use I was thinking about: WebSockets sessions are long-living, 
but they can occasionally be cut and need to be restarted. As an 
example, let's say that I take an hour to contemplate the next move in 
Ian's famous tick-tack-toe game. The connection may have been lost, for 
any of a number of reasons. With a cookie identifying the game, I may be 
able to finish my game rather than having to start a new one.

Regards,   Martin.

P.S.: I agree that Chess or Go or whatever might make a better example.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

v2.23.0 | Report a Bug | By Email