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

From: Doug Simpkinson <[email-masked]>
Date: Fri, 7 May 2010 11:11:30 -0700

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?

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.

-Doug Simpkinson
Software Engineer, Google

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 08 May 2010 19:03:10 +0200

> Accept-Language?  Shouldn't these also be sent?

doug,

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.

> that will make life more difficult for webmasters.

I've strongly advocated for full HTTP compliance, meaning
that arbitrary headers may be sent (not meaning that every
websocket client/server must implement support for
every header).

User-Agent is a good example of a common HTTP header that
is probably a SHOULD but not MUST have header as can imagine
many webapps using either explicitly or as part of their
statistics.

regards

---

From: Doug Simpkinson <[email-masked]>
Date: Sun, 9 May 2010 21:25:56 -0700

Do you know what's the reasoning behind omitting any HTTP headers?
What advantage is there to not sending User-Agent and Accept-Language?

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

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 10 May 2010 10:15:41 +0200

> What advantage is there to not sending User-Agent and Accept-Language?

Doug,

I'll restate the argument as I understand it.

By restricting the headers to a very specific subset of what is allowed
by HTTP, a websocket implementation can detect if a handshake has
come from a client, intermediary or server is not really support websockets,
but is just a HTTP implementation that has been tricked into pretending to
be a Websocket client or server.

The counter argument is that there are already several layers of
defence against such a spoofing attempt:

  1) The Upgrade header is listed in Connections, so non transparent
     intermediaries should have to explicitly copy the Upgrade header.

  2) The server must send a 101 response.  This can only be achieved if
     the either servers wishes to send a 101 response or the server is
     so incredibly vulnerable to injection, that an entire response
     line can be injected.

  3) There is rough consensus that the handshake should contain a
     mechanism based on a random number generated after the JS
     API has been passed the URL for a websocket.   The server will
     be required to produce a response based on that random number,
     so that even if it was incredibly vulnerable to injection,
     the URL could not be created with the correct injected response,
     because the random number is generated after the URL.

     This mechanism has been uber enhanced to the handshake
     algorithm that is in the -76 draft, which includes space
     counting (as extra protection against injection) and
     bytes after the HTTP request/response as fast fail detection.

  4) Even if the handshake is spoofed, it is probably impossible
     for a tricked JS XHR to sending/receiving any meaningful frames.

  5) Even if the spoof succeeded, any websocket server that will
     accept/provide privileged should be protected by some form
     of authentication.

  6) Any attacker able to execute hostile JS in a client will soon
     be able to use the websocket API to form real websocket
     handshakes and requests etc.

So the objective of the header restriction is indeed a valid
objective.   But I believe it is already met without the need
to restrict headers and thus prevent many established HTTP
features from being used now or in the future.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 10 May 2010 02:42:36 -0700

> so omitting User-Agent removes some flexibility in dealing with

I think sending User-Agent should be either required or forbidden, it  
doesn't seem like a good idea to make it optional. If server  
implementations are going to rely on it, then it's likely to cause  
interop problems if some client implementations elect not to send it.

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.

Regards,
Maciej