Re: [hybi] Extensibility mechanisms?

Ian Hickson <> Sun, 18 April 2010 02:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B361C3A68C7 for <>; Sat, 17 Apr 2010 19:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L92eypLq5YIe for <>; Sat, 17 Apr 2010 19:46:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E492E3A677E for <>; Sat, 17 Apr 2010 19:46:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 6453416D42C; Sat, 17 Apr 2010 19:46:35 -0700 (PDT)
Date: Sun, 18 Apr 2010 02:46:34 +0000
From: Ian Hickson <>
To: Justin Erenkrantz <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: Hybi <>
Subject: Re: [hybi] Extensibility mechanisms?
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: Sun, 18 Apr 2010 02:46:45 -0000

On Sat, 17 Apr 2010, Justin Erenkrantz wrote:
> On Fri, Apr 16, 2010 at 1:13 PM, Ian Hickson <> wrote:
> > ideal deployment the connection is wrapped in end-to-end TLS, so the
> > intermediaries can't do anything with it. There were only two reasons for
> It may be appropriate to say it is end-to-end TLS at an organizational
> level (ie user to origin)

Right, that's what I meant (though "origin" may be the wrong word to use 
here, given its meaning in the Web security sphere).

> but my experience is that most reverse proxy deployments perform TLS 
> termination on the edge of the network so that load balancing techniques 
> can be applied inside the network without TLS overhead.  So, I believe 
> it is very unlikely to expect that there will always be end-to-end TLS 
> at scale - the intermediaries will be relied upon to provide critical 
> load-balancing and failover mechanisms even for Web Socket.  -- justin

For all intents and purposes, the server is everything under control of 
the end point authority. It doesn't matter if the "server" conformance 
class is implemented by a 486 PC sitting under a desk using only userland 
Ruby code running on Linux or if it's implemented by a mixture of 
dedicated hardware in a datacenter providing load-balancing to an array of 
high-end servers running a custom clustering OS. The spec explicitly 
states that conformance requirements are essentially "black box" 
conformance requirements. It doesn't require the server to use a single 
processor; the TLS, Web Socket, and subprotocol handshakes could all be 
handled by completely different machines on different coasts, so long as 
the end result is indistinguishable from what the spec requires.

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