Re: [hybi] Additional HTTP headers on upgrade request?

Ian Hickson <ian@hixie.ch> Wed, 21 July 2010 22:38 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 CBFCD3A680F for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 15:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.433
X-Spam-Level:
X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 O7ZORCeA7c-2 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 15:38:23 -0700 (PDT)
Received: from looneymail-a3.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id BCB3B3A67E7 for <hybi@ietf.org>; Wed, 21 Jul 2010 15:38:22 -0700 (PDT)
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a3.g.dreamhost.com (Postfix) with ESMTP id A176C7CCF6; Wed, 21 Jul 2010 15:38:39 -0700 (PDT)
Date: Wed, 21 Jul 2010 22:38:39 +0000
From: Ian Hickson <ian@hixie.ch>
To: Jamie Lokier <jamie@shareable.org>
In-Reply-To: <20100721011221.GC27243@shareable.org>
Message-ID: <Pine.LNX.4.64.1007212234440.7242@ps20323.dreamhostps.com>
References: <n2s188fcbce1005071111kd19e6f41m861eaeb593d88475@mail.gmail.com> <4BE5994E.4010701@webtide.com> <u2n188fcbce1005092125veaf94306u249a225bdd3925ca@mail.gmail.com> <B8058102-9589-4663-976D-217B939667DD@apple.com> <Pine.LNX.4.64.1007210038520.7242@ps20323.dreamhostps.com> <20100721011221.GC27243@shareable.org>
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] Additional HTTP headers on upgrade request?
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: Wed, 21 Jul 2010 22:38:26 -0000

On Wed, 21 Jul 2010, Jamie Lokier wrote:
>
> The use case for User-Agent, normally determined by the client 
> implementation (not the application running on top of the WebSocket 
> API), is to provide servers with unreliable but pragmatically useful 
> information about what client implementations are using the server.
> 
> It is used for profiling, for general interest, for tracking what 
> clients may need to be supported if there are particular issues to be 
> avoided with some clients (such as a particular message that breaks one 
> of them), for tracking when clients with particular workarounds on the 
> server have fallen into sufficient misuse that the workarounds can be 
> removed, and for implementing specific workarounds for particular 
> recognised clients.
> 
> Hopefully workarounds at the WebSocket framing level are unlikely to be 
> commonly needed (although that might not be true if some clients have a 
> small message size limit and particular server applications have to 
> format their messages to accomodate this); but User-Agent turned out to 
> be quite pragmatic in HTTP for dealing with client-specific issues that 
> nobody had foreseen until they were too widely deployed to ignore or 
> fix.

This seems reasonable, but it also seems like something that we should 
just push to the application layer, and that we can push to the 
application layer with minimal incremental cost -- and indeed with some 
side-benefits, like making the handshake simpler for people who don't need 
this information, like preventing the problems that occured with HTTP's 
User-Agent header (such as everything saying they're Mozilla), and like 
giving authors more control over exactly what they want to check for (e.g. 
some might only care about the rendering engine, others might care only 
about the user's screen size, and by pushing it into the application layer 
we allow the subprotocol designers to decide what is important to them).

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