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. `._.-(,_..'--(,_..'`-.;.'
- [hybi] Additional HTTP headers on upgrade request? Doug Simpkinson
- Re: [hybi] Additional HTTP headers on upgrade req… Greg Wilkins
- Re: [hybi] Additional HTTP headers on upgrade req… Doug Simpkinson
- Re: [hybi] Additional HTTP headers on upgrade req… Greg Wilkins
- Re: [hybi] Additional HTTP headers on upgrade req… Maciej Stachowiak
- Re: [hybi] Additional HTTP headers on upgrade req… Ian Hickson
- Re: [hybi] Additional HTTP headers on upgrade req… Jamie Lokier
- Re: [hybi] Additional HTTP headers on upgrade req… Greg Wilkins
- Re: [hybi] Additional HTTP headers on upgrade req… Greg Wilkins
- Re: [hybi] Additional HTTP headers on upgrade req… Willy Tarreau
- Re: [hybi] Additional HTTP headers on upgrade req… Willy Tarreau
- Re: [hybi] Additional HTTP headers on upgrade req… Ian Hickson
- Re: [hybi] Additional HTTP headers on upgrade req… Jamie Lokier
- Re: [hybi] Additional HTTP headers on upgrade req… Jamie Lokier
- Re: [hybi] Additional HTTP headers on upgrade req… Ian Hickson
- Re: [hybi] Additional HTTP headers on upgrade req… Willy Tarreau
- Re: [hybi] Additional HTTP headers on upgrade req… John Tamplin
- Re: [hybi] Additional HTTP headers on upgrade req… Simone Bordet
- Re: [hybi] Additional HTTP headers on upgrade req… Greg Wilkins