This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For this failure case: if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must close the WebSocket connection. would it be more appropriate for the user agent to fail the WebSocket connection and trigger an error event?
This seems ok to me. Though firing it asynchronously seems like a good idea since we're likely in a low memory situation if this happens.
Failing the WebSocket connection involves sending more data. We can't send more data in this situation, by definition (that's why we're giving up, after all). But we can still fire an 'error' event, sure. Done. Note that both 'error' and 'close' are fired asynchronously (well, they're fired synchronously, but on a task that is queued after the connection is closed).
Checked in as WHATWG revision r6377. Check-in comment: Make the client-side failure mode also fire 'error'. http://html5.org/tools/web-apps-tracker?from=6376&to=6377
Failing the WebSocket connection does not always require more data to be sent based on the SHOULD/MAY language in the IETF draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-7.1.7 If _The WebSocket Connection is Established_ prior to the point where the endpoint is required to _Fail the WebSocket Connection_, the endpoint SHOULD send a Close frame with an appropriate status code Section 7.4 before proceeding to _Close the WebSocket Connection_. An endpoint MAY omit sending a Close frame if it believes the other side is unlikely to be able to receive and process the close frame, due to the nature of the error that led to the WebSocket connection being failed in the first place.