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

[Jamie Lokier <[e-mail]>]

Ian Hickson wrote:
> 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).

I'm thinking of when the people writing the server have no
relationship with the people writing applications (so they can't fix
applications), and need to handle client implemention issues (not
application issues).

For example suppose Yahoo provided a WebSocket-based access to their
public YQL query system, and suppose ten thousand authors wrote client
applications to run in the major browsers, and most of those
applications were cut-and-pasted by other authors who used them
without understanding how they work.

Then suppose it was discovered that certain rare byte sequences or
other low-level thing triggered a fault in Firefox 4.2.1, due to a
Firefox implementation bug, fixed in 4.2.2.  (That's the sort of ugly
thing which HTTP User-Agent is used to work around).  And suppose
4.2.1 was widely distributed and despite 4.2.2's availability,
millions of users continued to use 4.2.1 for some years.

If that happened, it would be in Yahoo's interest to avoid the
problematic byte sequences somehow, as transparently as possible.
They couldn't alter the client applications to send the browser
version; issuing advice to authors would be slow to have effect, and
anyway many deployed clients would have been cut-and-pasted, so even
authors updating their code would be slow to have an effect.

So in the absence of anything like User-Agent, Yahoo would have to
implement some kind of dirty low-level workaround affecting all
clients, despite only being needed for Firefox 4.2.1.

I agree there's plenty of issues with User-Agent in the HTTP world;
it's no panacea.  But it has been pragmatically useful for working
around HTTP low-level issues, such as breaking at certain response
lengths, or when claiming to support a negotiated feature but actually
being broken so the offer has to be ignored.

I've no correct answer for this, only the observation that User-Agent
has been pragmatically helpful in HTTP, despite the "everything
pretends to be Mozzilla" .  However I think it's more relevant if the
handshake acquires feature negotiation, specifically to ignore feature
offers from WebSocket implementations that are found to have buggy
implementations of features.

-- Jamie