IETF Logo Mail Archive

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

"Simon Pieters" <simonp@opera.com> Fri, 10 December 2010 00:11 UTC

Return-Path: <simonp@opera.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 B605928C10B for <hybi@core3.amsl.com>; Thu, 9 Dec 2010 16:11:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.007
X-Spam-Level:
X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4]
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 uzpsPLiJij6u for <hybi@core3.amsl.com>; Thu, 9 Dec 2010 16:11:01 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 4BB4228B23E for <hybi@ietf.org>; Thu, 9 Dec 2010 16:11:00 -0800 (PST)
Received: from dhcp-190.linkoping.osa (c-2e98e355.410-6-64736c14.cust.bredbandsbolaget.se [85.227.152.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oBA0CORP028232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Dec 2010 00:12:25 GMT
Content-Type: text/plain; charset="utf-8"; format="flowed"; delsp="yes"
To: Zhong Yu <zhong.j.yu@gmail.com>, 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>
Date: Fri, 10 Dec 2010 01:12:23 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: Simon Pieters <simonp@opera.com>
Message-ID: <op.vng1ixmaidj3kv@dhcp-190.linkoping.osa>
In-Reply-To: <AANLkTimg774w-JVExm4YQJzuBv3gaJZOLMo5OymDsMiE@mail.gmail.com>
User-Agent: Opera Mail/11.00 (MacIntel)
X-Scanned-By: MIMEDefang 2.64 on 213.236.208.81
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 00:11:03 -0000

On Fri, 10 Dec 2010 00:46:34 +0100, John Tamplin <jat@google.com> wrote:

> On Thu, Dec 9, 2010 at 2:42 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
>
>> 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.
>>
>
> The app can't send HTTP-only cookies, since it has no access to them.   
> One
> of the big problems with cookies in HTTP is that you send them on every
> request so they can take up a sizeable percentage of the bandwidth of the
> request, but in WebSockets that isn't a problem.
>
> Whatever cookies shortcomings, they are still being used and there is no
> viable replacement so I don't think we should drop support for them in
> WebSockets.

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.)

-- 
Simon Pieters
Opera Software

v2.23.0 | Report a Bug | By Email