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

[Ian Hickson <[e-mail]>]

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.


> My concern is that if these headers are not explicitly mentioned in the 
> draft spec that they won't be sent by all implementations, and that will 
> make life more difficult for webmasters.

I've clarified the spec to make it clearer that these headers are not 
included.


On Sat, 8 May 2010, Greg Wilkins wrote:
> 
> the 76 pre draft actually exclude header other than those mentioned with 
> phrase:
> 
>   The only options available in this version are the ...
> 
> While I don't think this text is very clear, I did ask the editor if it 
> was meant to exclude headers not mentioned and he indicated that this 
> was the case.

The text above is non-normative, but the requirements are pretty explicit 
and do indeed not include any provision for including other fields.


On Sun, 9 May 2010, Doug Simpkinson wrote:
>
> Do you know what's the reasoning behind omitting any HTTP headers?
> What advantage is there to not sending User-Agent and Accept-Language?

That's the wrong question -- the question is, what's the advantage to 
sending them? The more we omit, the simpler the protocol is. The default 
should be to omit.

In the case of User-Agent, for instance, one could put forward analytics 
as a use case. However, for that use case it seems best for the 
application-layer protocol to opt into sending the information. That way 
the author is in complete control as to what is logged.


> It is quite common for different browsers to have different behavior, so 
> omitting User-Agent removes some flexibility in dealing with browser 
> quirks.

Having the spec be trivial to implement makes it less likely that there 
will be differences, making this moot.

In practice, browser sniffing has been as much of a problem as a help -- 
people sniff for a browser, then rely on that browser's behaviour, and 
when the browser vendor tries to fix the underlying problems, or tries to 
converge with other browsers, they find they cannot because pages send 
them different content than other browsers. This is why, for instance, 
every successful browser in the world claims to be "Mozilla".


On Mon, 10 May 2010, Maciej Stachowiak wrote:
> 
> Likewise for Accept-Language. I would be tempted say that language 
> selection could just be handled as part of subprotocol negotiation, but 
> at least currently JS in the browser does not have easy access to the 
> user's set of preferred languages.

Nor does the user, in many cases...

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