Re: [hybi] Authentication headers

Ian Hickson <> Wed, 21 July 2010 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C59C3A677C for <>; Wed, 21 Jul 2010 00:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.307
X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S5tKWAX6SkeN for <>; Wed, 21 Jul 2010 00:01:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4AD313A697A for <>; Wed, 21 Jul 2010 00:01:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 8385815D565; Wed, 21 Jul 2010 00:01:31 -0700 (PDT)
Date: Wed, 21 Jul 2010 07:01:31 +0000 (UTC)
From: Ian Hickson <>
To: Wellington Fernando de Macedo <>
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
Subject: Re: [hybi] Authentication headers
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: Wed, 21 Jul 2010 07:01:17 -0000

On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote:
> I'm updating the Mozilla's implementation of the WS protocol to its 
> latest version (v.76). I know that handling the 401 http response was 
> already removed in the v75. But now I've noted that even the http 
> Authorization header has been removed.
> Well, I think that the 401 http status was removed in order to prevent 
> the browser to open unexpected auth dialogs to the user. Actually, I 
> know there is the cookie information, but I think it isn't always 
> enough. So, I would like to ask, why can't a "normal" request include 
> the Authorization header from its page origin?

There's some commented-out text to that effect, but frankly it's not clear 
to me that it would be particularly useful in practice. For example, the 
only authentication scheme that would work and be secure is Basic auth 
over TLS to the same host as served the HTML page. In practice, only very 
few sites use that combination of technologies; the cost of supporting it 
seems higher than the benefit gained from it. It also seems unreliable; it 
relies on the browser remembering the credentials used when loading the 
Web page, for instance. There are also a number of situations where it 
would seem that it should work but where it won't, for example if a page 
on one path uses pushState() to go to another path and then opens a 
WebSocket connection to the same host with the second path, the UA would 
not know the realm of the second path and thus wouldn't know to include 
the authentication information.

Basically, it seemed hacky. I couldn't really find a compelling argument 
to support this rather than having it at the application layer. (You can 
still leverage the basic auth feature that way, just have the server send 
back a unique token that identifies the user's session and then pass that 
back on the WebSocket connection.) Cookies are supported because they are 
_very_ widely used, so there's something to reuse. HTTP auth is used so 
rarely that I'd seriously consider dropping it from HTTP at this point; I 
really don't think it's worth adding to WebSockets.

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