[Libwebsockets] Connection Error Code

sonal gupta sonal6226 at gmail.com
Wed Dec 17 10:24:54 CET 2014


Thanks Andy for replying.

Support for close status will be very much needed in my case so I will
appreciate if this patch can be added to the library .



And My suggestion is to provide this status as short value instead of enum
so that we can use value of  status code ( in a range  as mentioned by
standard ) .

I’m planning  to use codes in the range 4000-4999 are reserved for private
use  .


I assume that status code will be provieded in first 2 bytes of *"**void **
*in" *of API "*int* callback (*struct libwebsocket_context ** context, *struct
libwebsocket ** wsi, *enum libwebsocket_callback_reasons* reason, *void **
user, *void ** in, *size_t* len)". Please verify my assumtions.


7.4.2. Status Code Ranges


   0-999


      Status codes in the range 0-999 are not used.


   1000-2999


      Status codes in the range 1000-2999 are reserved for definition by

      this protocol, its future revisions, and extensions specified in a

      permanent and readily available public specification.


   3000-3999


      Status codes in the range 3000-3999 are reserved for use by

      libraries, frameworks, and applications.  These status codes are

      registered directly with IANA.  The interpretation of these codes

      is undefined by this protocol.


   4000-4999


      Status codes in the range 4000-4999 are reserved for private use

      and thus can't be registered.  Such codes can be used by prior

      agreements between WebSocket applications.  The interpretation of

      these codes is undefined by this protocol.


Regards,

Sonal


On Tue, Dec 16, 2014 at 6:29 AM, Andy Green <andy at warmcat.com> wrote:
>
>
>
> On 15 December 2014 20:54:26 GMT+08:00, sonal gupta <sonal6226 at gmail.com>
> wrote:
> >Hi Andy,
> >
> >How do extract various error condition codes which may occur in case of
> >connection faliure ?
> >
> >As per standrad, follwoing error code occurs in Libwebsockets. But
> >which
> >api or callback is used to handle them on upper layer.
>
> Right now there is no way.  You closed and that's it.
>
> In many cases there's no information anyway, eg, it was not or did not
> make it to an established websocket connection, or he closed in an
> uncontrolled way outside ws control.
>
> But it's true if it was a ws connection, and it was closed inside ws
> control, there is more info we could provide.
>
> Would you like to make a patch for this functionality?
>
> -Andy
>
> >enum lws_close_status {
> >LWS_CLOSE_STATUS_NOSTATUS = 0,
> >LWS_CLOSE_STATUS_NORMAL = 1000,
> >LWS_CLOSE_STATUS_GOINGAWAY = 1001,
> >LWS_CLOSE_STATUS_PROTOCOL_ERR = 1002,
> >LWS_CLOSE_STATUS_UNACCEPTABLE_OPCODE = 1003,
> >LWS_CLOSE_STATUS_RESERVED = 1004,
> >LWS_CLOSE_STATUS_NO_STATUS = 1005,
> >LWS_CLOSE_STATUS_ABNORMAL_CLOSE = 1006,
> >LWS_CLOSE_STATUS_INVALID_PAYLOAD = 1007,
> >LWS_CLOSE_STATUS_POLICY_VIOLATION = 1008,
> >LWS_CLOSE_STATUS_MESSAGE_TOO_LARGE = 1009,
> >LWS_CLOSE_STATUS_EXTENSION_REQUIRED = 1010,
> >LWS_CLOSE_STATUS_UNEXPECTED_CONDITION = 1011,
> >LWS_CLOSE_STATUS_TLS_FAILURE = 1015,
> >};
> >
> >Please provide your valuable feedback.
> >Thanks for giving helplful replies for previous query.
> >
> >Regards,
> >Sonal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20141217/d2d3645a/attachment-0001.html>


More information about the Libwebsockets mailing list