This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. For example: <pre> var conn = new WebSocket("ws://non-a-websocket-server:80"); // Let's assume HTTP 400 is replied. // This would print "400": console.log(conn.httpStatusCode); </pre>
Should that not be left to the developer console?
Well, the browser console already shows the HTTP status code of the non 101 response, but the JavaScript application can not get it. 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"). It might be useful, but at the same time, it means that a malicious script can attack an arbitrary HTTP page using HTTP auth by using WebSocket. From the viewpoint of security, I believe that we should not expose HTTP response code to JavaScript.
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.