If the WebSocket connection fails due to a non 101 HTTP response code from the server, there is no way to know the exact HTTP code. This could be useful.
var conn = new WebSocket("ws://non-a-websocket-server:80");
// Let's assume HTTP 400 is replied.
// This would print "400":
Should that not be left to the developer console?
What I consider useful is that the JS code can get the HTTP status code to inform the user (for example 403 could mean "You are not authorized to connect to this WebSocket server").
(In reply to comment #2)
> What I consider useful is that the JS code can get the HTTP status code to
> inform the user (for example 403 could mean "You are not authorized to
> connect to this WebSocket server").
How could a malicious script attack an arbitrary HTTP page using HTTP auth by using WebSocket? The script cannot add the required Authorization or Proxy-Authorization header at all.
(In reply to comment #4)
> The script cannot add the required Authorization or
> Proxy-Authorization header at all.
I missed the point. You are right.
I can imagine the following usecase:
- A website offers to visitors WebSocket access to a thirdy party provider (i.e. via the inclusion of JS code provided by the WS service).
- But the website has not payed to the WS provider during last months so its "LICENSE_KEY" is not valid anymore.
- The visitor tries to use the WS service. The JS code attempts a WS connection to "ws://service-provider.net?LICENSE_KEY=qwuyt87qghe" and gets a 403 "Not Authorized".
- The JS code then shows it to the web user in a friendly way.
That would be a bad way of doing things. If it's a WebSocket connection, use the WebSocket protocol to send back the error, not HTTP. WebSocket isn't really anything to de with HTTP, it just happens to be compatible for legacy reasons (to make it easier to use one port with both protocols).
We can't expose stuff from arbitrary cross-origin HTTP servers. It would let you do all kinds of things like intranet inspection, etc.