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

Jamie Lokier <jamie@shareable.org> Wed, 21 July 2010 23:12 UTC

Return-Path: <jamie@shareable.org>
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 046BC3A68A4 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 16:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.418
X-Spam-Level:
X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 mPdbwBPN1D53 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 16:12:54 -0700 (PDT)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id C97B03A6902 for <hybi@ietf.org>; Wed, 21 Jul 2010 16:12:53 -0700 (PDT)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1ObiTM-0000lM-SG; Thu, 22 Jul 2010 00:13:08 +0100
Date: Thu, 22 Jul 2010 00:13:08 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Willy Tarreau <w@1wt.eu>
Message-ID: <20100721231308.GD14589@shareable.org>
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> <20100721051910.GH26999@1wt.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20100721051910.GH26999@1wt.eu>
User-Agent: Mutt/1.5.13 (2006-08-11)
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 23:12:58 -0000

Willy Tarreau wrote:
> On Wed, Jul 21, 2010 at 02:12:21AM +0100, Jamie Lokier wrote:
> > Ian Hickson wrote:
> > > On Fri, 7 May 2010, Doug Simpkinson wrote:
> > > >
> > > > In draft 76, the upgrade request is said to include cookies that may be 
> > > > relevant, but no mention of other HTTP headers is made.
> > > > 
> > > > What about other relevant HTTP headers such as User-Agent and 
> > > > Accept-Language?  Shouldn't these also be sent?
> > > 
> > > What's the use case?
> > > 
> > > If there are clear and important use cases that are best handled by adding 
> > > new fields to the handshake, then we should add them.
> > 
> > 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.
> 
> And it's used a lot to act differently with smartphones. Maybe that
> could be used on the server side to try to group outgoing data into
> fewer packets in order to improve user experience or reduce communication
> costs.

It would be nicer if the server is told what kind of communication
channel is being used, rather than what kind of device it's
communicating with.  It's not easy, e.g. if your laptop is going via
your phone's 3g, then its a 3g channel but the laptop probably doesn't
know it.  In the scheme of things it would be nice if proxies, such as
at mobile base stations, were permitted to annotate the handshake.
They _can_ do that with HTTP, using Via.  It's informal but that
doesn't stop it being useful - in principle.  I don't know if anyone
mobile system actually does that, or if any server uses the data.

We really don't want to overdesign WebSocket, but ought to be room for
certain particularly simple, maybe optional, things that have proven
pragmatically useful before.  I suspect User-Agent and Via fit into
that category, even though they are messy and unreliable.  But I'm not
really sure.

-- Jamie