Re: [hybi] More feedback on WebSockets

Greg Wilkins <> Tue, 27 October 2009 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D6F43A6914 for <>; Tue, 27 Oct 2009 14:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.305
X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id USXlYw+NmFUU for <>; Tue, 27 Oct 2009 14:12:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2582F3A67ED for <>; Tue, 27 Oct 2009 14:12:01 -0700 (PDT)
Received: by bwz19 with SMTP id 19so182014bwz.28 for <>; Tue, 27 Oct 2009 14:12:09 -0700 (PDT)
Received: by with SMTP id k14mr180308bkd.106.1256677929745; Tue, 27 Oct 2009 14:12:09 -0700 (PDT)
Received: from ? ( []) by with ESMTPS id 14sm126961bwz.9.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 14:12:08 -0700 (PDT)
Message-ID: <>
Date: Wed, 28 Oct 2009 08:12:01 +1100
From: Greg Wilkins <>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] More feedback on WebSockets
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Oct 2009 21:12:03 -0000

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.