Bug 21147 - WebSocket API could provide a method to get the HTTP response code when it's not 101
Summary: WebSocket API could provide a method to get the HTTP response code when it's ...
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebSocket API (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-27 16:40 UTC by Iñaki Baz Castillo
Modified: 2013-03-04 19:57 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Iñaki Baz Castillo 2013-02-27 16:40:45 UTC
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>
Comment 1 Anne 2013-02-28 18:45:58 UTC
Should that not be left to the developer console?
Comment 2 Iñaki Baz Castillo 2013-02-28 21:03:49 UTC
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").
Comment 3 Takashi Toyoshima 2013-03-04 06:04:52 UTC
(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.
Comment 4 Iñaki Baz Castillo 2013-03-04 08:47:42 UTC
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.
Comment 5 Takashi Toyoshima 2013-03-04 09:08:27 UTC
(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.
Comment 6 Iñaki Baz Castillo 2013-03-04 09:54:06 UTC
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.
Comment 7 Ian 'Hixie' Hickson 2013-03-04 19:57:45 UTC
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.