W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

WebSocket API clise Method

From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Date: Tue, 31 Jan 2012 15:09:05 +0100
Message-ID: <4F27F601.8060507@bauglir.com>
To: public-webapps@w3.org
Hello,
based on this bug
http://code.google.com/p/chromium/issues/detail?id=93609
referencing
http://dev.w3.org/html5/websockets/#dom-websocket-close

Looking in WebSocket protocol close codes definitions
http://tools.ietf.org/html/rfc6455#section-7.4.1

I wonder about codes

1003 indicates that an endpoint is terminating the connection
       because it has received a type of data it cannot accept (e.g., an
       endpoint that understands only text data MAY send this if it
       receives a binary message).

1008 indicates that an endpoint is terminating the connection
       because it has received a message that violates its policy.  This
       is a generic status code that can be returned when there is no
       other more suitable status code (e.g., 1003 or 1009) or if there
       is a need to hide specific details about the policy.

1009 indicates that an endpoint is terminating the connection
       because it has received a message that is too big for it to
       process.


Those are/maybe application level codes (generic one). E.g. your WS 
implementation supports
both text and binary types (in browser), but your application expects 
only text messages (1003).
Client (application) expects first message from server to contain 
specific information, but server fails to provide (1008).
Client (application) have requested certain data, e.g. part of a file, 
but data received from server are bigger than requested.

Application level codes (3000-4999) does not apply here, because in my 
previous examples shows, that server
simply did not understand the application protocol in a first place, so 
it makes no sense for client to send
application level close codes to server - those codes would have no 
meaning there.


Brona
Received on Tuesday, 31 January 2012 14:09:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT