Re: [hybi] More feedback on WebSockets

Ian Hickson <ian@hixie.ch> Tue, 27 October 2009 21:23 UTC

Return-Path: <ian@hixie.ch>
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 2B7FD3A6781 for <hybi@core3.amsl.com>; Tue, 27 Oct 2009 14:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level:
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599]
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 PWimROjQBLGC for <hybi@core3.amsl.com>; Tue, 27 Oct 2009 14:23:40 -0700 (PDT)
Received: from looneymail-a2.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 3CB873A688C for <hybi@ietf.org>; Tue, 27 Oct 2009 14:23:38 -0700 (PDT)
Received: from hixie.dreamhostps.com (hixie.dreamhost.com [208.113.210.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a2.g.dreamhost.com (Postfix) with ESMTP id 1F6D816D3F7; Tue, 27 Oct 2009 14:23:53 -0700 (PDT)
Date: Tue, 27 Oct 2009 21:23:59 +0000 (UTC)
From: Ian Hickson <ian@hixie.ch>
To: Greg Wilkins <gregw@webtide.com>
In-Reply-To: <4AE76221.30908@webtide.com>
Message-ID: <Pine.LNX.4.62.0910272123060.25608@hixie.dreamhostps.com>
References: <FDC38D4B-AB64-4F6B-B569-81D7A56DEC8D@mnot.net> <Pine.LNX.4.62.0910270912040.9145@hixie.dreamhostps.com> <4AE6C7D1.30003@webtide.com> <Pine.LNX.4.62.0910271834480.25616@hixie.dreamhostps.com> <4AE75D12.4060302@webtide.com> <Pine.LNX.4.62.0910272055390.25608@hixie.dreamhostps.com> <4AE75FEA.3090001@webtide.com> <Pine.LNX.4.62.0910272104140.25608@hixie.dreamhostps.com> <4AE76221.30908@webtide.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: hybi@ietf.org
Subject: Re: [hybi] More feedback on WebSockets
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: Tue, 27 Oct 2009 21:23:42 -0000

On Wed, 28 Oct 2009, Greg Wilkins wrote:
> Ian Hickson wrote:
> > On Wed, 28 Oct 2009, Greg Wilkins wrote:
> >>> For the packet-forwarding ones, are we talking about inserting a 
> >>> header on incoming connections (client to server) or outgoing 
> >>> responses (server back to client)?
> >> Again - there are a huge number of variations.
> >>
> >> But inserting X-forwarded-for headers on requests and Via headers on 
> >> responses is common. So is setting cookies on responses so that 
> >> subsequent connections can be balanced the same. Also SSL offload 
> >> will want to set certificate details in the request header.
> > 
> > It sounds like there are some intermediaries that are harmless and 
> > would work fine, and others that are harmful and which WebSocket would 
> > correctly detect and prevent connections through. If someone wants to 
> > deploy a WebSocket server behind the latter, they'll quickly discover 
> > the problem, so it doesn't seem like it'd be a barrier to adoption. 
> > It's client-side intermediaries that are the main concern (and for 
> > which TLS-based WebSocket is the most obvious solution in most cases).
> 
> But they need to be able to set cookies and headers in order to work.
> 
> Setting these on the upgrade request and response should be perfectly 
> possible and HTTP legal.  It would allow existing intermediaries to 
> communicate important information to client (which node they are stuck 
> to) and to server (ssl and original client details).
> 
> These are just a few of many examples of why allowing an intermediary to 
> add meta data is an important part of a web protocol.
> 
> WS does not allow this because it is trying to do an end-run around 
> intermediaries rather then trying to sensibly work with them.

WebSocket doesn't preclude WebSocket-aware intermediaries inserting data 
into the stream. It will have no effect, though; a WebSocket client isn't 
going to change any cookies or change behaviour based on headers set on 
the handshake.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'