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
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. `._.-(,_..'--(,_..'`-.;.'
- [hybi] More feedback on WebSockets Mark Nottingham
- Re: [hybi] More feedback on WebSockets Ian Hickson
- Re: [hybi] More feedback on WebSockets Greg Wilkins
- Re: [hybi] More feedback on WebSockets Ian Hickson
- Re: [hybi] More feedback on WebSockets Greg Wilkins
- Re: [hybi] More feedback on WebSockets Ian Hickson
- Re: [hybi] More feedback on WebSockets Greg Wilkins
- Re: [hybi] More feedback on WebSockets Ian Hickson
- Re: [hybi] More feedback on WebSockets Greg Wilkins
- Re: [hybi] More feedback on WebSockets Mark Nottingham
- Re: [hybi] More feedback on WebSockets Ian Hickson
- Re: [hybi] More feedback on WebSockets Ian Hickson