21147 2013-02-27 16:40:45 +0000 WebSocket API could provide a method to get the HTTP response code when it's not 101 2013-03-04 19:57:45 +0000 1 1 1 Unclassified WebAppsWG WebSocket API (editor: Ian Hickson) unspecified All All RESOLVED WONTFIX P2 minor --- 1 ibc ian annevk art.barstow brian.raymor ian mike public-html-admin public-html-wg-issue-tracking public-webapps toyoshim public-webapps-bugzilla oldest_to_newest 83811 0 ibc 2013-02-27 16:40:45 +0000 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> 83837 1 annevk 2013-02-28 18:45:58 +0000 Should that not be left to the developer console? 83838 2 ibc 2013-02-28 21:03:49 +0000 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"). 83918 3 toyoshim 2013-03-04 06:04:52 +0000 (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. 83922 4 ibc 2013-03-04 08:47:42 +0000 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. 83923 5 toyoshim 2013-03-04 09:08:27 +0000 (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. 83927 6 ibc 2013-03-04 09:54:06 +0000 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. 83957 7 ian 2013-03-04 19:57:45 +0000 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.