RFC 6455, "The WebSocket Protocol", December 2011

Note: This RFC has been updated by RFC 7936, RFC 8307, RFC 8441

Errata ID: 4398
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike West
Date Reported: 2015-06-24
Held for Document Update by: Barry Leiba
Date Held: 2015-06-24

Section 4.1 says:

1. The components of the WebSocket URI passed into this algorithm
   (/host/, /port/, /resource name/, and /secure/ flag) MUST be
   valid according to the specification of WebSocket URIs specified
   in Section 3.  If any of the components are invalid, the client
   MUST _Fail the WebSocket Connection_ and abort these steps.

It should say:

1. The components of the WebSocket URI passed into this algorithm
   (/host/, /port/, /resource name/, and /secure/ flag) MUST be
   valid according to the specification of WebSocket URIs specified
   in Section 3.  If any of the components are invalid, the client
   MUST _Fail the WebSocket Connection_ and abort these steps.

2. If secure is false, and the algorithm in Mixed Content's "§5.1
   Does settings object restrict mixed content?" returns Restricts
   Mixed Content when applied to client's entry script's relevant
   settings object's, then the client MUST fail the WebSocket
   connection and abort the connection.

Notes:

This change is suggested by the W3C's "Mixed Content" document (https://w3c.github.io/webappsec/specs/mixedcontent/#websockets-integration), and will bring WebSockets' behaviors into line with XMLHttpRequest, EventSource, and Fetch, all of which act as though there was a network error when blocking a mixed content request, rather than throwing a SecurityError exception.

Report New Errata