Support WebSocket in WebRequest API.

chrome/common/extensions/docs/templates/intros/webRequest.html

 <h2 id="manifest">Manifest</h2>
 <p>You must declare the "webRequest" permission in the <a
   href="manifest">extension manifest</a> to use the web request
 API, along with <a href="declare_permissions">host permissions</a>
 for any hosts whose network requests you want to access. If you want to
 use the web request API in a blocking fashion, you need to request
 the "webRequestBlocking" permission in addition.
 For example:</p>
 <pre data-filename="manifest.json">
 {
@@ skipping 106 matching lines @@
 </p>
 
 <p>
 The webRequest API only exposes requests that the extension has
 permission to see, given its
 <a href="declare_permissions">host permissions</a>.
 Moreover, only the following schemes are accessible:
 <code>http://</code>,
 <code>https://</code>,
 <code>ftp://</code>,
-<code>file://</code>, or
+<code>file://</code>,
+<code>ws://</code> (<span class="availability">since Chrome 58</span>),
+<code>wss://</code> (<span class="availability">since Chrome 58</span>), or
 <code>chrome-extension://</code>.
 In addition, even certain requests with URLs using one of the above schemes
 are hidden, e.g.,
 <code>chrome-extension://other_extension_id</code> where
 <code>other_extension_id</code> is not the ID of the extension to handle
 the request,
 <code>https://www.google.com/chrome</code>,
 and others (this list is not complete). Also synchronous XMLHttpRequests from
 your extension are hidden from blocking event handlers in order to prevent
 deadlocks.
 Note that for some of the supported schemes the set of available events might be
 limited due to the nature of the corresponding protocol.
 For example, for the <q>file:</q> scheme, only <code>onBeforeRequest</code>,
 <code>onResponseStarted</code>, <code>onCompleted</code>, and
 <code>onErrorOccurred</code> may be dispatched.
 </p>
 
+<p>
+<span class="availability">Starting from Chrome 58</span>, webRequest API

[Devlin, 2017/02/21 16:10:44]

nit: *the* webRequest API

[pkalinnikov, 2017/02/21 19:18:16]

Done.

+supports intercepting the WebSocket handshake request. Since the handshake is
+done by means of an HTTP upgrade request, its flow fits into HTTP-oriented
+webRequest model. Note that the API does <b>not intercept</b>:
+<ul>
+  <li>Individual messages sent over an established WebSocket connection.</li>
+  <li>WebSocket closing connection.</li>
+</ul>
+</p>

[Devlin, 2017/02/21 16:10:44]

should we also mention that redirects are not supported?

edit: I see that we do this on the method, so that's probably sufficient.  It
might still be worth calling out explicitly here, but I don't feel strongly, so
up to you.

[pkalinnikov, 2017/02/21 19:18:16]

Done.

+
 <h2 id="concepts">Concepts</h2>
 
 <p>As the following sections explain, events in the web request API use request
 IDs, and you can optionally specify filters and extra information when you
 register event listeners.</p>
 
 <h3 id="Request IDs">Request IDs</h3>
 
 <p>Each request is identified by a request ID. This ID is unique within a
 browser session and the context of an extension. It remains constant during the
@@ skipping 150 matching lines @@
       }
     }
     return {requestHeaders: details.requestHeaders};
   },
   {urls: ["&lt;all_urls&gt;"]},
   ["blocking", "requestHeaders"]);
 </pre>
 
 <p> For more example code, see the <a href="samples#search:webrequest">web request
 samples</a>.</p>