- From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Date: Wed, 01 Feb 2012 05:55:26 +0100
- CC: public-webapps@w3.org
On 1.2.2012 5:43, Takashi Toyoshima wrote: > Hi Bronislav, > > On Tue, Jan 31, 2012 at 11:09 PM, Bronislav Klučka > <Bronislav.Klucka@bauglir.com> wrote: >> 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 > To my understanding, these codes are used by browser and server layer. > For example, 1003 may mean the browser doesn't support binary type frames > in its WebSocket protocol stack. > > Meaning of application level binary support will depend on application level > subprotocols. You may want to define application level close code in > the range 3000 to 4999 to notify that client doesn't support some > kinds of features. > Or you can define some feature negotiating frameworks over your subprotocols. > > Application level error code could be useful for server side > application handler. > In this case, it doesn't matter if the server side protocol stack > itself understand > these application level codes. > >> 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 >> Hi, I understand, I actually expected this reasoning, that those codes are for browser level environment. I just wonder, whether is it necessary to be so strict here. It would be nice to have some generic error messages available for web applications. Imagine some widely used data transfer format / communication API (using WS as transport protocol), you have client application in your browser and you want to connect to some server you do not maintain/manage/whatever, all you know is that the server should provide service based on this common format, it would be nice to have generic error messages. And I specifically picked those 3 , because it is very likely, that your application will have define codes withing application range which would have the same exact meaning. Brona
Received on Wednesday, 1 February 2012 04:56:07 UTC