Re: [hybi] Intermediaries and idle connections (was Re: Technical feedback.)

Maciej Stachowiak <mjs@apple.com> Sun, 31 January 2010 00:57 UTC

Return-Path: <mjs@apple.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 D56BF3A67A8 for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 16:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.582
X-Spam-Level:
X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 zTszeohMOqg6 for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 16:57:58 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 929563A67B3 for <hybi@ietf.org>; Sat, 30 Jan 2010 16:57:58 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id DB6F68965CAA for <hybi@ietf.org>; Sat, 30 Jan 2010 16:58:26 -0800 (PST)
X-AuditID: 11807137-b7bd4ae000000f0d-60-4b64d5b2b549
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay16.apple.com (Apple SCV relay) with SMTP id 34.07.03853.2B5D46B4; Sat, 30 Jan 2010 16:58:26 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_dAWo/1DAkUgOfH+qo5lPsw)"
Received: from [10.0.1.5] (c-69-181-42-237.hsd1.ca.comcast.net [69.181.42.237]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX300G5W6PEAM70@et.apple.com> for hybi@ietf.org; Sat, 30 Jan 2010 16:58:26 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <4B64D0B3.7050503@webtide.com>
Date: Sat, 30 Jan 2010 16:58:25 -0800
Message-id: <3A1BA23A-D9B6-48F5-8639-DE12CF9939C0@apple.com>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <4B620B8F.6030706@gmx.de> <Pine.LNX.4.64.1001282217320.22053@ps20323.dreamhostps.com> <bbeaa26f1001281449q1a6e1813q3f537fe15a5a9d60@mail.gmail.com> <4B625733.2020907@webtide.com> <6.2.5.6.2.20100128225542.06fa8d68@resistor.net> <Pine.LNX.4.64.1001290817520.22020@ps20323.dreamhostps.com> <4B62C5FE.8090904@it.aoyama.ac.jp> <Pine.LNX.4.64.1001291134350.22020@ps20323.dreamhostps.com> <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com> <E379EA13-D58A-4BFB-A62D-2B931A54E276@apple.com> <4B63DD6B.5030803@webtide.com> <E765982E-06B5-48BC-B75D-02E3F9555018@apple.com> <4B64B179.9050502@webtide.com> <2D6C6FEE-2019-44E4-BD82-7BF68B30A518@apple.com> <4B64D0B3.7050503@webtide.com>
To: Greg Wilkins <gregw@webtide.com>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Intermediaries and idle connections (was Re: Technical feedback.)
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: Sun, 31 Jan 2010 00:58:00 -0000

On Jan 30, 2010, at 4:37 PM, Greg Wilkins wrote:

>> 
>> I don't know whether the hardcoded handshake format it the right
>> tradeoff overall. But reasons have been given for it, so I don't think
>> its fair to call it "just for giggles".
> 
> Sorry for my choice of language.    Reasons have been given, but I
> have seen zero support for those reasons from anybody but the
> author.

As I understand it, the reason is security. If you strictly limit the format of the handshake interchange, then its less likely that WebSocket could be abused to talk to a non-WebSocket server - if you need to trick it into echoing back something very specific, that's a harder problem. It also makes the checks that the handshake was correct simpler and therefore potentially more robust.

However, from what you said in the rest of your message, it seems like the implementation cost is very high for servers that want to offer WebSocket services on the same host/port as ordinary HTTP services. (For clients it matters less, because they know up front if a connection is WebSocket or HTTP, so they don't have to make a WebSocet handshake go through a general-purpose HTTP stack.) I'm not sure that's a good tradeoff. Making something hard to implement is itself likely to lead to security problems.

(No time to comment on the rest of your message right now, but I wanted to reply to that point.)

Regards,
Maciej