{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1713557012, "reponame":"libwebsockets", "desc":"libwebsockets lightweight C networking library", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://libwebsockets.org/repo/libwebsockets", "f":3, "items": [ {"schema":"libjg2-1", "cid":"99741c8a656fff58254afba26c4c0298", "oid":{ "oid": "f28a45246e7ea479718ddba5e80deb355b23f5f3", "alias": [ "refs/heads/main"]},"blobname": "include/libwebsockets/lws-callbacks.h", "blob": "/*\n * libwebsockets - small server side websockets and web server implementation\n *\n * Copyright (C) 2010 - 2019 Andy Green \u003candy@warmcat.com\u003e\n *\n * Permission is hereby granted, free of charge, to any person obtaining a copy\n * of this software and associated documentation files (the \u0022Software\u0022), to\n * deal in the Software without restriction, including without limitation the\n * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or\n * sell copies of the Software, and to permit persons to whom the Software is\n * furnished to do so, subject to the following conditions:\n *\n * The above copyright notice and this permission notice shall be included in\n * all copies or substantial portions of the Software.\n *\n * THE SOFTWARE IS PROVIDED \u0022AS IS\u0022, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS\n * IN THE SOFTWARE.\n */\n\n/*! \u005cdefgroup usercb User Callback\n *\n * ##User protocol callback\n *\n * The protocol callback is the primary way lws interacts with\n * user code. For one of a list of a few dozen reasons the callback gets\n * called at some event to be handled.\n *\n * All of the events can be ignored, returning 0 is taken as \u0022OK\u0022 and returning\n * nonzero in most cases indicates that the connection should be closed.\n */\n///@{\n\nstruct lws_ssl_info {\n\tint where;\n\tint ret;\n};\n\nenum lws_cert_update_state {\n\tLWS_CUS_IDLE,\n\tLWS_CUS_STARTING,\n\tLWS_CUS_SUCCESS,\n\tLWS_CUS_FAILED,\n\n\tLWS_CUS_CREATE_KEYS,\n\tLWS_CUS_REG,\n\tLWS_CUS_AUTH,\n\tLWS_CUS_CHALLENGE,\n\tLWS_CUS_CREATE_REQ,\n\tLWS_CUS_REQ,\n\tLWS_CUS_CONFIRM,\n\tLWS_CUS_ISSUE,\n};\n\nenum {\n\tLWS_TLS_REQ_ELEMENT_COUNTRY,\n\tLWS_TLS_REQ_ELEMENT_STATE,\n\tLWS_TLS_REQ_ELEMENT_LOCALITY,\n\tLWS_TLS_REQ_ELEMENT_ORGANIZATION,\n\tLWS_TLS_REQ_ELEMENT_COMMON_NAME,\n\tLWS_TLS_REQ_ELEMENT_SUBJECT_ALT_NAME,\n\tLWS_TLS_REQ_ELEMENT_EMAIL,\n\n\tLWS_TLS_REQ_ELEMENT_COUNT,\n\n\tLWS_TLS_SET_DIR_URL \u003d LWS_TLS_REQ_ELEMENT_COUNT,\n\tLWS_TLS_SET_AUTH_PATH,\n\tLWS_TLS_SET_CERT_PATH,\n\tLWS_TLS_SET_KEY_PATH,\n\n\tLWS_TLS_TOTAL_COUNT\n};\n\nstruct lws_acme_cert_aging_args {\n\tstruct lws_vhost *vh;\n\tconst char *element_overrides[LWS_TLS_TOTAL_COUNT]; /* NULL \u003d use pvo */\n};\n\n/*\n * With LWS_CALLBACK_FILTER_NETWORK_CONNECTION callback, user_data pointer\n * points to one of these\n */\n\nstruct lws_filter_network_conn_args {\n\tstruct sockaddr_storage\t\tcli_addr;\n\tsocklen_t\t\t\tclilen;\n\tlws_sockfd_type\t\t\taccept_fd;\n};\n\n/*\n * NOTE: These public enums are part of the abi. If you want to add one,\n * add it at where specified so existing users are unaffected.\n */\n/** enum lws_callback_reasons - reason you're getting a protocol callback */\nenum lws_callback_reasons {\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to wsi and protocol binding lifecycle -----\n\t */\n\n\tLWS_CALLBACK_PROTOCOL_INIT\t\t\t\t\u003d 27,\n\t/**\u003c One-time call per protocol, per-vhost using it, so it can\n\t * do initial setup / allocations etc */\n\n\tLWS_CALLBACK_PROTOCOL_DESTROY\t\t\t\t\u003d 28,\n\t/**\u003c One-time call per protocol, per-vhost using it, indicating\n\t * this protocol won't get used at all after this callback, the\n\t * vhost is getting destroyed. Take the opportunity to\n\t * deallocate everything that was allocated by the protocol. */\n\n\tLWS_CALLBACK_WSI_CREATE\t\t\t\t\t\u003d 29,\n\t/**\u003c outermost (earliest) wsi create notification to protocols[0] */\n\n\tLWS_CALLBACK_WSI_DESTROY\t\t\t\t\u003d 30,\n\t/**\u003c outermost (latest) wsi destroy notification to protocols[0] */\n\n\tLWS_CALLBACK_WSI_TX_CREDIT_GET\t\t\t\t\u003d 103,\n\t/**\u003c manually-managed connection received TX credit (len is int32) */\n\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to Server TLS -----\n\t */\n\n\tLWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS\t\u003d 21,\n\t/**\u003c if configured for\n\t * including OpenSSL support, this callback allows your user code\n\t * to perform extra SSL_CTX_load_verify_locations() or similar\n\t * calls to direct OpenSSL where to find certificates the client\n\t * can use to confirm the remote server identity. user is the\n\t * OpenSSL SSL_CTX* */\n\n\tLWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS\t\u003d 22,\n\t/**\u003c if configured for\n\t * including OpenSSL support, this callback allows your user code\n\t * to load extra certificates into the server which allow it to\n\t * verify the validity of certificates returned by clients. user\n\t * is the server's OpenSSL SSL_CTX* and in is the lws_vhost */\n\n\tLWS_CALLBACK_OPENSSL_PERFORM_CLIENT_CERT_VERIFICATION\t\u003d 23,\n\t/**\u003c if the libwebsockets vhost was created with the option\n\t * LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT, then this\n\t * callback is generated during OpenSSL verification of the cert\n\t * sent from the client. It is sent to protocol[0] callback as\n\t * no protocol has been negotiated on the connection yet.\n\t * Notice that the libwebsockets context and wsi are both NULL\n\t * during this callback. See\n\t * http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html\n\t * to understand more detail about the OpenSSL callback that\n\t * generates this libwebsockets callback and the meanings of the\n\t * arguments passed. In this callback, user is the x509_ctx,\n\t * in is the ssl pointer and len is preverify_ok\n\t * Notice that this callback maintains libwebsocket return\n\t * conventions, return 0 to mean the cert is OK or 1 to fail it.\n\t * This also means that if you don't handle this callback then\n\t * the default callback action of returning 0 allows the client\n\t * certificates. */\n\n\tLWS_CALLBACK_SSL_INFO\t\t\t\t\t\u003d 67,\n\t/**\u003c SSL connections only. An event you registered an\n\t * interest in at the vhost has occurred on a connection\n\t * using the vhost. in is a pointer to a\n\t * struct lws_ssl_info containing information about the\n\t * event*/\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to Client TLS -----\n\t */\n\n\tLWS_CALLBACK_OPENSSL_PERFORM_SERVER_CERT_VERIFICATION \u003d 58,\n\t/**\u003c Similar to LWS_CALLBACK_OPENSSL_PERFORM_CLIENT_CERT_VERIFICATION\n\t * this callback is called during OpenSSL verification of the cert\n\t * sent from the server to the client. It is sent to protocol[0]\n\t * callback as no protocol has been negotiated on the connection yet.\n\t * Notice that the wsi is set because lws_client_connect_via_info was\n\t * successful.\n\t *\n\t * See http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html\n\t * to understand more detail about the OpenSSL callback that\n\t * generates this libwebsockets callback and the meanings of the\n\t * arguments passed. In this callback, user is the x509_ctx,\n\t * in is the ssl pointer and len is preverify_ok.\n\t *\n\t * THIS IS NOT RECOMMENDED BUT if a cert validation error shall be\n\t * overruled and cert shall be accepted as ok,\n\t * X509_STORE_CTX_set_error((X509_STORE_CTX*)user, X509_V_OK); must be\n\t * called and return value must be 0 to mean the cert is OK;\n\t * returning 1 will fail the cert in any case.\n\t *\n\t * This also means that if you don't handle this callback then\n\t * the default callback action of returning 0 will not accept the\n\t * certificate in case of a validation error decided by the SSL lib.\n\t *\n\t * This is expected and secure behaviour when validating certificates.\n\t *\n\t * Note: LCCSCF_ALLOW_SELFSIGNED and\n\t * LCCSCF_SKIP_SERVER_CERT_HOSTNAME_CHECK still work without this\n\t * callback being implemented.\n\t */\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to HTTP Server -----\n\t */\n\n\tLWS_CALLBACK_SERVER_NEW_CLIENT_INSTANTIATED\t\t\u003d 19,\n\t/**\u003c A new client has been accepted by the ws server. This\n\t * callback allows setting any relevant property to it. Because this\n\t * happens immediately after the instantiation of a new client,\n\t * there's no websocket protocol selected yet so this callback is\n\t * issued only to protocol 0. Only wsi is defined, pointing to the\n\t * new client, and the return value is ignored. */\n\n\tLWS_CALLBACK_HTTP\t\t\t\t\t\u003d 12,\n\t/**\u003c an http request has come from a client that is not\n\t * asking to upgrade the connection to a websocket\n\t * one. This is a chance to serve http content,\n\t * for example, to send a script to the client\n\t * which will then open the websockets connection.\n\t * in points to the URI path requested and\n\t * lws_serve_http_file() makes it very\n\t * simple to send back a file to the client.\n\t * Normally after sending the file you are done\n\t * with the http connection, since the rest of the\n\t * activity will come by websockets from the script\n\t * that was delivered by http, so you will want to\n\t * return 1; to close and free up the connection. */\n\n\tLWS_CALLBACK_HTTP_BODY\t\t\t\t\t\u003d 13,\n\t/**\u003c the next len bytes data from the http\n\t * request body HTTP connection is now available in in. */\n\n\tLWS_CALLBACK_HTTP_BODY_COMPLETION\t\t\t\u003d 14,\n\t/**\u003c the expected amount of http request body has been delivered */\n\n\tLWS_CALLBACK_HTTP_FILE_COMPLETION\t\t\t\u003d 15,\n\t/**\u003c a file requested to be sent down http link has completed. */\n\n\tLWS_CALLBACK_HTTP_WRITEABLE\t\t\t\t\u003d 16,\n\t/**\u003c you can write more down the http protocol link now. */\n\n\tLWS_CALLBACK_CLOSED_HTTP\t\t\t\t\u003d 5,\n\t/**\u003c when a HTTP (non-websocket) session ends */\n\n\tLWS_CALLBACK_FILTER_HTTP_CONNECTION\t\t\t\u003d 18,\n\t/**\u003c called when the request has\n\t * been received and parsed from the client, but the response is\n\t * not sent yet. Return non-zero to disallow the connection.\n\t * user is a pointer to the connection user space allocation,\n\t * in is the URI, eg, \u0022/\u0022\n\t * In your handler you can use the public APIs\n\t * lws_hdr_total_length() / lws_hdr_copy() to access all of the\n\t * headers using the header enums lws_token_indexes from\n\t * libwebsockets.h to check for and read the supported header\n\t * presence and content before deciding to allow the http\n\t * connection to proceed or to kill the connection. */\n\n\tLWS_CALLBACK_ADD_HEADERS\t\t\t\t\u003d 53,\n\t/**\u003c This gives your user code a chance to add headers to a server\n\t * transaction bound to your protocol. `in` points to a\n\t * `struct lws_process_html_args` describing a buffer and length\n\t * you can add headers into using the normal lws apis.\n\t *\n\t * (see LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER to add headers to\n\t * a client transaction)\n\t *\n\t * Only `args-\u003ep` and `args-\u003elen` are valid, and `args-\u003ep` should\n\t * be moved on by the amount of bytes written, if any. Eg\n\t *\n\t * \tcase LWS_CALLBACK_ADD_HEADERS:\n\t *\n\t * struct lws_process_html_args *args \u003d\n\t * \t\t(struct lws_process_html_args *)in;\n\t *\n\t *\t if (lws_add_http_header_by_name(wsi,\n\t *\t\t\t(unsigned char *)\u0022set-cookie:\u0022,\n\t *\t\t\t(unsigned char *)cookie, cookie_len,\n\t *\t\t\t(unsigned char **)\u0026args-\u003ep,\n\t *\t\t\t(unsigned char *)args-\u003ep + args-\u003emax_len))\n\t *\t\treturn 1;\n\t *\n\t * break;\n\t */\n\n\tLWS_CALLBACK_VERIFY_BASIC_AUTHORIZATION \u003d 102,\n\t/**\u003c This gives the user code a chance to accept or reject credentials\n\t * provided HTTP to basic authorization. It will only be called if the\n\t * http mount's authentication_mode is set to LWSAUTHM_BASIC_AUTH_CALLBACK\n\t * `in` points to a credential string of the form `username:password` If\n\t * the callback returns zero (the default if unhandled), then the\n\t * transaction ends with HTTP_STATUS_UNAUTHORIZED, otherwise the request\n\t * will be processed */\n\n\tLWS_CALLBACK_CHECK_ACCESS_RIGHTS\t\t\t\u003d 51,\n\t/**\u003c This gives the user code a chance to forbid an http access.\n\t * `in` points to a `struct lws_process_html_args`, which\n\t * describes the URL, and a bit mask describing the type of\n\t * authentication required. If the callback returns nonzero,\n\t * the transaction ends with HTTP_STATUS_UNAUTHORIZED. */\n\n\tLWS_CALLBACK_PROCESS_HTML\t\t\t\t\u003d 52,\n\t/**\u003c This gives your user code a chance to mangle outgoing\n\t * HTML. `in` points to a `struct lws_process_html_args`\n\t * which describes the buffer containing outgoing HTML.\n\t * The buffer may grow up to `.max_len` (currently +128\n\t * bytes per buffer).\n\t */\n\n\tLWS_CALLBACK_HTTP_BIND_PROTOCOL\t\t\t\t\u003d 49,\n\t/**\u003c By default, all HTTP handling is done in protocols[0].\n\t * However you can bind different protocols (by name) to\n\t * different parts of the URL space using callback mounts. This\n\t * callback occurs in the new protocol when a wsi is bound\n\t * to that protocol. Any protocol allocation related to the\n\t * http transaction processing should be created then.\n\t * These specific callbacks are necessary because with HTTP/1.1,\n\t * a single connection may perform at series of different\n\t * transactions at different URLs, thus the lifetime of the\n\t * protocol bind is just for one transaction, not connection. */\n\n\tLWS_CALLBACK_HTTP_DROP_PROTOCOL\t\t\t\t\u003d 50,\n\t/**\u003c This is called when a transaction is unbound from a protocol.\n\t * It indicates the connection completed its transaction and may\n\t * do something different now. Any protocol allocation related\n\t * to the http transaction processing should be destroyed. */\n\n\tLWS_CALLBACK_HTTP_CONFIRM_UPGRADE\t\t\t\u003d 86,\n\t/**\u003c This is your chance to reject an HTTP upgrade action. The\n\t * name of the protocol being upgraded to is in 'in', and the ah\n\t * is still bound to the wsi, so you can look at the headers.\n\t *\n\t * The default of returning 0 (ie, also if not handled) means the\n\t * upgrade may proceed. Return \u003c0 to just hang up the connection,\n\t * or \u003e0 if you have rejected the connection by returning http headers\n\t * and response code yourself.\n\t *\n\t * There is no need for you to call transaction_completed() as the\n\t * caller will take care of it when it sees you returned \u003e0.\n\t */\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to HTTP Client -----\n\t */\n\n\tLWS_CALLBACK_ESTABLISHED_CLIENT_HTTP\t\t\t\u003d 44,\n\t/**\u003c The HTTP client connection has succeeded, and is now\n\t * connected to the server */\n\n\tLWS_CALLBACK_CLOSED_CLIENT_HTTP\t\t\t\t\u003d 45,\n\t/**\u003c The HTTP client connection is closing */\n\n\tLWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ\t\t\t\u003d 48,\n\t/**\u003c This is generated by lws_http_client_read() used to drain\n\t * incoming data. In the case the incoming data was chunked, it will\n\t * be split into multiple smaller callbacks for each chunk block,\n\t * removing the chunk headers. If not chunked, it will appear all in\n\t * one callback. */\n\n\tLWS_CALLBACK_RECEIVE_CLIENT_HTTP\t\t\t\u003d 46,\n\t/**\u003c This indicates data was received on the HTTP client connection. It\n\t * does NOT actually drain or provide the data, so if you are doing\n\t * http client, you MUST handle this and call lws_http_client_read().\n\t * Failure to deal with it as in the minimal examples may cause spinning\n\t * around the event loop as it's continuously signalled the same data\n\t * is available for read. The related minimal examples show how to\n\t * handle it.\n\t *\n\t * It's possible to defer calling lws_http_client_read() if you use\n\t * rx flow control to stop further rx handling on the connection until\n\t * you did deal with it. But normally you would call it in the handler.\n\t *\n\t * lws_http_client_read() strips any chunked framing and calls back\n\t * with only payload data to LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ. The\n\t * chunking is the reason this is not just all done in one callback for\n\t * http.\n\t */\n\tLWS_CALLBACK_COMPLETED_CLIENT_HTTP\t\t\t\u003d 47,\n\t/**\u003c The client transaction completed... at the moment this\n\t * is the same as closing since transaction pipelining on\n\t * client side is not yet supported. */\n\n\tLWS_CALLBACK_CLIENT_HTTP_WRITEABLE\t\t\t\u003d 57,\n\t/**\u003c when doing an HTTP type client connection, you can call\n\t * lws_client_http_body_pending(wsi, 1) from\n\t * LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER to get these callbacks\n\t * sending the HTTP headers.\n\t *\n\t * From this callback, when you have sent everything, you should let\n\t * lws know by calling lws_client_http_body_pending(wsi, 0)\n\t */\n\n\tLWS_CALLBACK_CLIENT_HTTP_REDIRECT\t\t\t\u003d 104,\n\t/**\u003c we're handling a 3xx redirect... return nonzero to hang up */\n\n\tLWS_CALLBACK_CLIENT_HTTP_BIND_PROTOCOL\t\t\t\u003d 85,\n\tLWS_CALLBACK_CLIENT_HTTP_DROP_PROTOCOL\t\t\t\u003d 76,\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to Websocket Server -----\n\t */\n\n\tLWS_CALLBACK_ESTABLISHED\t\t\t\t\u003d 0,\n\t/**\u003c (VH) after the server completes a handshake with an incoming\n\t * client. If you built the library with ssl support, in is a\n\t * pointer to the ssl struct associated with the connection or NULL.\n\t *\n\t * b0 of len is set if the connection was made using ws-over-h2\n\t */\n\n\tLWS_CALLBACK_CLOSED\t\t\t\t\t\u003d 4,\n\t/**\u003c when the websocket session ends */\n\n\tLWS_CALLBACK_SERVER_WRITEABLE\t\t\t\t\u003d 11,\n\t/**\u003c See LWS_CALLBACK_CLIENT_WRITEABLE */\n\n\tLWS_CALLBACK_RECEIVE\t\t\t\t\t\u003d 6,\n\t/**\u003c data has appeared for this server endpoint from a\n\t * remote client, it can be found at *in and is\n\t * len bytes long */\n\n\tLWS_CALLBACK_RECEIVE_PONG\t\t\t\t\u003d 7,\n\t/**\u003c servers receive PONG packets with this callback reason */\n\n\tLWS_CALLBACK_WS_PEER_INITIATED_CLOSE\t\t\t\u003d 38,\n\t/**\u003c The peer has sent an unsolicited Close WS packet. in and\n\t * len are the optional close code (first 2 bytes, network\n\t * order) and the optional additional information which is not\n\t * defined in the standard, and may be a string or non human-readable\n\t * data.\n\t * If you return 0 lws will echo the close and then close the\n\t * connection. If you return nonzero lws will just close the\n\t * connection. */\n\n\tLWS_CALLBACK_FILTER_PROTOCOL_CONNECTION\t\t\t\u003d 20,\n\t/**\u003c called when the handshake has\n\t * been received and parsed from the client, but the response is\n\t * not sent yet. Return non-zero to disallow the connection.\n\t * user is a pointer to the connection user space allocation,\n\t * in is the requested protocol name\n\t * In your handler you can use the public APIs\n\t * lws_hdr_total_length() / lws_hdr_copy() to access all of the\n\t * headers using the header enums lws_token_indexes from\n\t * libwebsockets.h to check for and read the supported header\n\t * presence and content before deciding to allow the handshake\n\t * to proceed or to kill the connection. */\n\n\tLWS_CALLBACK_CONFIRM_EXTENSION_OKAY\t\t\t\u003d 25,\n\t/**\u003c When the server handshake code\n\t * sees that it does support a requested extension, before\n\t * accepting the extension by additing to the list sent back to\n\t * the client it gives this callback just to check that it's okay\n\t * to use that extension. It calls back to the requested protocol\n\t * and with in being the extension name, len is 0 and user is\n\t * valid. Note though at this time the ESTABLISHED callback hasn't\n\t * happened yet so if you initialize user content there, user\n\t * content during this callback might not be useful for anything. */\n\n\tLWS_CALLBACK_WS_SERVER_BIND_PROTOCOL\t\t\t\u003d 77,\n\tLWS_CALLBACK_WS_SERVER_DROP_PROTOCOL\t\t\t\u003d 78,\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to Websocket Client -----\n\t */\n\n\tLWS_CALLBACK_CLIENT_CONNECTION_ERROR\t\t\t\u003d 1,\n\t/**\u003c the request client connection has been unable to complete a\n\t * handshake with the remote server. If in is non-NULL, you can\n\t * find an error string of length len where it points to\n\t *\n\t * Diagnostic strings that may be returned include\n\t *\n\t * \t\u0022getaddrinfo (ipv6) failed\u0022\n\t * \t\u0022unknown address family\u0022\n\t * \t\u0022getaddrinfo (ipv4) failed\u0022\n\t * \t\u0022set socket opts failed\u0022\n\t * \t\u0022insert wsi failed\u0022\n\t * \t\u0022lws_ssl_client_connect1 failed\u0022\n\t * \t\u0022lws_ssl_client_connect2 failed\u0022\n\t * \t\u0022Peer hung up\u0022\n\t * \t\u0022read failed\u0022\n\t * \t\u0022HS: URI missing\u0022\n\t * \t\u0022HS: Redirect code but no Location\u0022\n\t * \t\u0022HS: URI did not parse\u0022\n\t * \t\u0022HS: Redirect failed\u0022\n\t * \t\u0022HS: Server did not return 200\u0022\n\t * \t\u0022HS: OOM\u0022\n\t * \t\u0022HS: disallowed by client filter\u0022\n\t * \t\u0022HS: disallowed at ESTABLISHED\u0022\n\t * \t\u0022HS: ACCEPT missing\u0022\n\t * \t\u0022HS: ws upgrade response not 101\u0022\n\t * \t\u0022HS: UPGRADE missing\u0022\n\t * \t\u0022HS: Upgrade to something other than websocket\u0022\n\t * \t\u0022HS: CONNECTION missing\u0022\n\t * \t\u0022HS: UPGRADE malformed\u0022\n\t * \t\u0022HS: PROTOCOL malformed\u0022\n\t * \t\u0022HS: Cannot match protocol\u0022\n\t * \t\u0022HS: EXT: list too big\u0022\n\t * \t\u0022HS: EXT: failed setting defaults\u0022\n\t * \t\u0022HS: EXT: failed parsing defaults\u0022\n\t * \t\u0022HS: EXT: failed parsing options\u0022\n\t * \t\u0022HS: EXT: Rejects server options\u0022\n\t * \t\u0022HS: EXT: unknown ext\u0022\n\t * \t\u0022HS: Accept hash wrong\u0022\n\t * \t\u0022HS: Rejected by filter cb\u0022\n\t * \t\u0022HS: OOM\u0022\n\t * \t\u0022HS: SO_SNDBUF failed\u0022\n\t * \t\u0022HS: Rejected at CLIENT_ESTABLISHED\u0022\n\t */\n\n\tLWS_CALLBACK_CLIENT_FILTER_PRE_ESTABLISH\t\t\u003d 2,\n\t/**\u003c this is the last chance for the client user code to examine the\n\t * http headers and decide to reject the connection. If the\n\t * content in the headers is interesting to the\n\t * client (url, etc) it needs to copy it out at\n\t * this point since it will be destroyed before\n\t * the CLIENT_ESTABLISHED call */\n\n\tLWS_CALLBACK_CLIENT_ESTABLISHED\t\t\t\t\u003d 3,\n\t/**\u003c after your client connection completed the websocket upgrade\n\t * handshake with the remote server */\n\n\tLWS_CALLBACK_CLIENT_CLOSED\t\t\t\t\u003d 75,\n\t/**\u003c when a client websocket session ends */\n\n\tLWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER\t\t\u003d 24,\n\t/**\u003c this callback happens\n\t * when a client handshake is being compiled. user is NULL,\n\t * in is a char **, it's pointing to a char * which holds the\n\t * next location in the header buffer where you can add\n\t * headers, and len is the remaining space in the header buffer,\n\t * which is typically some hundreds of bytes. So, to add a canned\n\t * cookie, your handler code might look similar to:\n\t *\n\t *\tchar **p \u003d (char **)in, *end \u003d (*p) + len;\n\t *\n\t *\tif (lws_add_http_header_by_token(wsi, WSI_TOKEN_HTTP_COOKIE,\n\t *\t\t\t(unsigned char)\u0022a\u003db\u0022, 3, p, end))\n\t *\t\treturn -1;\n\t *\n\t * See LWS_CALLBACK_ADD_HEADERS for adding headers to server\n\t * transactions.\n\t */\n\n\tLWS_CALLBACK_CLIENT_RECEIVE\t\t\t\t\u003d 8,\n\t/**\u003c data has appeared from the server for the client connection, it\n\t * can be found at *in and is len bytes long */\n\n\tLWS_CALLBACK_CLIENT_RECEIVE_PONG\t\t\t\u003d 9,\n\t/**\u003c clients receive PONG packets with this callback reason */\n\n\tLWS_CALLBACK_CLIENT_WRITEABLE\t\t\t\t\u003d 10,\n\t/**\u003c If you call lws_callback_on_writable() on a connection, you will\n\t * get one of these callbacks coming when the connection socket\n\t * is able to accept another write packet without blocking.\n\t * If it already was able to take another packet without blocking,\n\t * you'll get this callback at the next call to the service loop\n\t * function. Notice that CLIENTs get LWS_CALLBACK_CLIENT_WRITEABLE\n\t * and servers get LWS_CALLBACK_SERVER_WRITEABLE. */\n\n\tLWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED\t\t\u003d 26,\n\t/**\u003c When a ws client\n\t * connection is being prepared to start a handshake to a server,\n\t * each supported extension is checked with protocols[0] callback\n\t * with this reason, giving the user code a chance to suppress the\n\t * claim to support that extension by returning non-zero. If\n\t * unhandled, by default 0 will be returned and the extension\n\t * support included in the header to the server. Notice this\n\t * callback comes to protocols[0]. */\n\n\tLWS_CALLBACK_WS_EXT_DEFAULTS\t\t\t\t\u003d 39,\n\t/**\u003c Gives client connections an opportunity to adjust negotiated\n\t * extension defaults. `user` is the extension name that was\n\t * negotiated (eg, \u0022permessage-deflate\u0022). `in` points to a\n\t * buffer and `len` is the buffer size. The user callback can\n\t * set the buffer to a string describing options the extension\n\t * should parse. Or just ignore for defaults. */\n\n\n\tLWS_CALLBACK_FILTER_NETWORK_CONNECTION\t\t\t\u003d 17,\n\t/**\u003c called when a client connects to\n\t * the server at network level; the connection is accepted but then\n\t * passed to this callback to decide whether to hang up immediately\n\t * or not, based on the client IP.\n\t *\n\t * user_data in the callback points to a\n\t * struct lws_filter_network_conn_args that is prepared with the\n\t * sockfd, and the peer's address information.\n\t *\n\t * in contains the connection socket's descriptor.\n\t *\n\t * Since the client connection information is not available yet,\n\t * wsi still pointing to the main server socket.\n\t *\n\t * Return non-zero to terminate the connection before sending or\n\t * receiving anything. Because this happens immediately after the\n\t * network connection from the client, there's no websocket protocol\n\t * selected yet so this callback is issued only to protocol 0. */\n\n\tLWS_CALLBACK_WS_CLIENT_BIND_PROTOCOL\t\t\t\u003d 79,\n\tLWS_CALLBACK_WS_CLIENT_DROP_PROTOCOL\t\t\t\u003d 80,\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to external poll loop integration -----\n\t */\n\n\tLWS_CALLBACK_GET_THREAD_ID\t\t\t\t\u003d 31,\n\t/**\u003c lws can accept callback when writable requests from other\n\t * threads, if you implement this callback and return an opaque\n\t * current thread ID integer. */\n\n\t/* external poll() management support */\n\tLWS_CALLBACK_ADD_POLL_FD\t\t\t\t\u003d 32,\n\t/**\u003c lws normally deals with its poll() or other event loop\n\t * internally, but in the case you are integrating with another\n\t * server you will need to have lws sockets share a\n\t * polling array with the other server. This and the other\n\t * POLL_FD related callbacks let you put your specialized\n\t * poll array interface code in the callback for protocol 0, the\n\t * first protocol you support, usually the HTTP protocol in the\n\t * serving case.\n\t * This callback happens when a socket needs to be\n\t * added to the polling loop: in points to a struct\n\t * lws_pollargs; the fd member of the struct is the file\n\t * descriptor, and events contains the active events\n\t *\n\t * If you are using the internal lws polling / event loop\n\t * you can just ignore these callbacks. */\n\n\tLWS_CALLBACK_DEL_POLL_FD\t\t\t\t\u003d 33,\n\t/**\u003c This callback happens when a socket descriptor\n\t * needs to be removed from an external polling array. in is\n\t * again the struct lws_pollargs containing the fd member\n\t * to be removed. If you are using the internal polling\n\t * loop, you can just ignore it. */\n\n\tLWS_CALLBACK_CHANGE_MODE_POLL_FD\t\t\t\u003d 34,\n\t/**\u003c This callback happens when lws wants to modify the events for\n\t * a connection.\n\t * in is the struct lws_pollargs with the fd to change.\n\t * The new event mask is in events member and the old mask is in\n\t * the prev_events member.\n\t * If you are using the internal polling loop, you can just ignore\n\t * it. */\n\n\tLWS_CALLBACK_LOCK_POLL\t\t\t\t\t\u003d 35,\n\t/**\u003c These allow the external poll changes driven\n\t * by lws to participate in an external thread locking\n\t * scheme around the changes, so the whole thing is threadsafe.\n\t * These are called around three activities in the library,\n\t *\t- inserting a new wsi in the wsi / fd table (len\u003d1)\n\t *\t- deleting a wsi from the wsi / fd table (len\u003d1)\n\t *\t- changing a wsi's POLLIN/OUT state (len\u003d0)\n\t * Locking and unlocking external synchronization objects when\n\t * len \u003d\u003d 1 allows external threads to be synchronized against\n\t * wsi lifecycle changes if it acquires the same lock for the\n\t * duration of wsi dereference from the other thread context. */\n\n\tLWS_CALLBACK_UNLOCK_POLL\t\t\t\t\u003d 36,\n\t/**\u003c See LWS_CALLBACK_LOCK_POLL, ignore if using lws internal poll */\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to CGI serving -----\n\t */\n\n\tLWS_CALLBACK_CGI\t\t\t\t\t\u003d 40,\n\t/**\u003c CGI: CGI IO events on stdin / out / err are sent here on\n\t * protocols[0]. The provided `lws_callback_http_dummy()`\n\t * handles this and the callback should be directed there if\n\t * you use CGI. */\n\n\tLWS_CALLBACK_CGI_TERMINATED\t\t\t\t\u003d 41,\n\t/**\u003c CGI: The related CGI process ended, this is called before\n\t * the wsi is closed. Used to, eg, terminate chunking.\n\t * The provided `lws_callback_http_dummy()`\n\t * handles this and the callback should be directed there if\n\t * you use CGI. The child PID that terminated is in len. */\n\n\tLWS_CALLBACK_CGI_STDIN_DATA\t\t\t\t\u003d 42,\n\t/**\u003c CGI: Data is, to be sent to the CGI process stdin, eg from\n\t * a POST body. The provided `lws_callback_http_dummy()`\n\t * handles this and the callback should be directed there if\n\t * you use CGI. */\n\n\tLWS_CALLBACK_CGI_STDIN_COMPLETED\t\t\t\u003d 43,\n\t/**\u003c CGI: no more stdin is coming. The provided\n\t * `lws_callback_http_dummy()` handles this and the callback\n\t * should be directed there if you use CGI. */\n\n\tLWS_CALLBACK_CGI_PROCESS_ATTACH\t\t\t\t\u003d 70,\n\t/**\u003c CGI: Sent when the CGI process is spawned for the wsi. The\n\t * len parameter is the PID of the child process */\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to Generic Sessions -----\n\t */\n\n\tLWS_CALLBACK_SESSION_INFO\t\t\t\t\u003d 54,\n\t/**\u003c This is only generated by user code using generic sessions.\n\t * It's used to get a `struct lws_session_info` filled in by\n\t * generic sessions with information about the logged-in user.\n\t * See the messageboard sample for an example of how to use. */\n\n\tLWS_CALLBACK_GS_EVENT\t\t\t\t\t\u003d 55,\n\t/**\u003c Indicates an event happened to the Generic Sessions session.\n\t * `in` contains a `struct lws_gs_event_args` describing the event. */\n\n\tLWS_CALLBACK_HTTP_PMO\t\t\t\t\t\u003d 56,\n\t/**\u003c per-mount options for this connection, called before\n\t * the normal LWS_CALLBACK_HTTP when the mount has per-mount\n\t * options.\n\t */\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to RAW PROXY -----\n\t */\n\n\tLWS_CALLBACK_RAW_PROXY_CLI_RX\t\t\t\t\u003d 89,\n\t/**\u003c RAW mode client (outgoing) RX */\n\n\tLWS_CALLBACK_RAW_PROXY_SRV_RX\t\t\t\t\u003d 90,\n\t/**\u003c RAW mode server (listening) RX */\n\n\tLWS_CALLBACK_RAW_PROXY_CLI_CLOSE\t\t\t\u003d 91,\n\t/**\u003c RAW mode client (outgoing) is closing */\n\n\tLWS_CALLBACK_RAW_PROXY_SRV_CLOSE\t\t\t\u003d 92,\n\t/**\u003c RAW mode server (listening) is closing */\n\n\tLWS_CALLBACK_RAW_PROXY_CLI_WRITEABLE\t\t\t\u003d 93,\n\t/**\u003c RAW mode client (outgoing) may be written */\n\n\tLWS_CALLBACK_RAW_PROXY_SRV_WRITEABLE\t\t\t\u003d 94,\n\t/**\u003c RAW mode server (listening) may be written */\n\n\tLWS_CALLBACK_RAW_PROXY_CLI_ADOPT\t\t\t\u003d 95,\n\t/**\u003c RAW mode client (onward) accepted socket was adopted\n\t * (equivalent to 'wsi created') */\n\n\tLWS_CALLBACK_RAW_PROXY_SRV_ADOPT\t\t\t\u003d 96,\n\t/**\u003c RAW mode server (listening) accepted socket was adopted\n\t * (equivalent to 'wsi created') */\n\n\tLWS_CALLBACK_RAW_PROXY_CLI_BIND_PROTOCOL\t\t\u003d 97,\n\tLWS_CALLBACK_RAW_PROXY_SRV_BIND_PROTOCOL\t\t\u003d 98,\n\tLWS_CALLBACK_RAW_PROXY_CLI_DROP_PROTOCOL\t\t\u003d 99,\n\tLWS_CALLBACK_RAW_PROXY_SRV_DROP_PROTOCOL\t\t\u003d 100,\n\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to RAW sockets -----\n\t */\n\n\tLWS_CALLBACK_RAW_RX\t\t\t\t\t\u003d 59,\n\t/**\u003c RAW mode connection RX */\n\n\tLWS_CALLBACK_RAW_CLOSE\t\t\t\t\t\u003d 60,\n\t/**\u003c RAW mode connection is closing */\n\n\tLWS_CALLBACK_RAW_WRITEABLE\t\t\t\t\u003d 61,\n\t/**\u003c RAW mode connection may be written */\n\n\tLWS_CALLBACK_RAW_ADOPT\t\t\t\t\t\u003d 62,\n\t/**\u003c RAW mode connection was adopted (equivalent to 'wsi created') */\n\n\tLWS_CALLBACK_RAW_CONNECTED\t\t\t\t\u003d 101,\n\t/**\u003c outgoing client RAW mode connection was connected */\n\n\tLWS_CALLBACK_RAW_SKT_BIND_PROTOCOL\t\t\t\u003d 81,\n\tLWS_CALLBACK_RAW_SKT_DROP_PROTOCOL\t\t\t\u003d 82,\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to RAW file handles -----\n\t */\n\n\tLWS_CALLBACK_RAW_ADOPT_FILE\t\t\t\t\u003d 63,\n\t/**\u003c RAW mode file was adopted (equivalent to 'wsi created') */\n\n\tLWS_CALLBACK_RAW_RX_FILE\t\t\t\t\u003d 64,\n\t/**\u003c This is the indication the RAW mode file has something to read.\n\t * This doesn't actually do the read of the file and len is always\n\t * 0... your code should do the read having been informed there is\n\t * something to read now. */\n\n\tLWS_CALLBACK_RAW_WRITEABLE_FILE\t\t\t\t\u003d 65,\n\t/**\u003c RAW mode file is writeable */\n\n\tLWS_CALLBACK_RAW_CLOSE_FILE\t\t\t\t\u003d 66,\n\t/**\u003c RAW mode wsi that adopted a file is closing */\n\n\tLWS_CALLBACK_RAW_FILE_BIND_PROTOCOL\t\t\t\u003d 83,\n\tLWS_CALLBACK_RAW_FILE_DROP_PROTOCOL\t\t\t\u003d 84,\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to generic wsi events -----\n\t */\n\n\tLWS_CALLBACK_TIMER\t\t\t\t\t\u003d 73,\n\t/**\u003c When the time elapsed after a call to\n\t * lws_set_timer_usecs(wsi, usecs) is up, the wsi will get one of\n\t * these callbacks. The deadline can be continuously extended into the\n\t * future by later calls to lws_set_timer_usecs() before the deadline\n\t * expires, or cancelled by lws_set_timer_usecs(wsi, -1);\n\t */\n\n\tLWS_CALLBACK_EVENT_WAIT_CANCELLED\t\t\t\u003d 71,\n\t/**\u003c This is sent to every protocol of every vhost in response\n\t * to lws_cancel_service() or lws_cancel_service_pt(). This\n\t * callback is serialized in the lws event loop normally, even\n\t * if the lws_cancel_service[_pt]() call was from a different\n\t * thread. */\n\n\tLWS_CALLBACK_CHILD_CLOSING\t\t\t\t\u003d 69,\n\t/**\u003c Sent to parent to notify them a child is closing / being\n\t * destroyed. in is the child wsi.\n\t */\n\n\tLWS_CALLBACK_CONNECTING\t\t\t\t\t\u003d 105,\n\t/**\u003c Called before a socketfd is about to connect(). In is the\n\t * socketfd, cast to a (void *), if on a platform where the socketfd\n\t * is an int, recover portably using (lws_sockfd_type)(intptr_t)in.\n\t *\n\t * It's also called in SOCKS5 or http_proxy cases where the socketfd is\n\t * going to try to connect to its proxy.\n\t */\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to TLS certificate management -----\n\t */\n\n\tLWS_CALLBACK_VHOST_CERT_AGING\t\t\t\t\u003d 72,\n\t/**\u003c When a vhost TLS cert has its expiry checked, this callback\n\t * is broadcast to every protocol of every vhost in case the\n\t * protocol wants to take some action with this information.\n\t * \u005cp in is a pointer to a struct lws_acme_cert_aging_args,\n\t * and \u005cp len is the number of days left before it expires, as\n\t * a (ssize_t). In the struct lws_acme_cert_aging_args, vh\n\t * points to the vhost the cert aging information applies to,\n\t * and element_overrides[] is an optional way to update information\n\t * from the pvos... NULL in an index means use the information from\n\t * from the pvo for the cert renewal, non-NULL in the array index\n\t * means use that pointer instead for the index. */\n\n\tLWS_CALLBACK_VHOST_CERT_UPDATE\t\t\t\t\u003d 74,\n\t/**\u003c When a vhost TLS cert is being updated, progress is\n\t * reported to the vhost in question here, including completion\n\t * and failure. in points to optional JSON, and len represents the\n\t * connection state using enum lws_cert_update_state */\n\n\t/* ---------------------------------------------------------------------\n\t * ----- Callbacks related to MQTT Client -----\n\t */\n\n\tLWS_CALLBACK_MQTT_NEW_CLIENT_INSTANTIATED\t\t\u003d 200,\n\tLWS_CALLBACK_MQTT_IDLE\t\t\t\t\t\u003d 201,\n\tLWS_CALLBACK_MQTT_CLIENT_ESTABLISHED\t\t\t\u003d 202,\n\tLWS_CALLBACK_MQTT_SUBSCRIBED\t\t\t\t\u003d 203,\n\tLWS_CALLBACK_MQTT_CLIENT_WRITEABLE\t\t\t\u003d 204,\n\tLWS_CALLBACK_MQTT_CLIENT_RX\t\t\t\t\u003d 205,\n\tLWS_CALLBACK_MQTT_UNSUBSCRIBED\t\t\t\t\u003d 206,\n\tLWS_CALLBACK_MQTT_DROP_PROTOCOL\t\t\t\t\u003d 207,\n\tLWS_CALLBACK_MQTT_CLIENT_CLOSED\t\t\t\t\u003d 208,\n\tLWS_CALLBACK_MQTT_ACK\t\t\t\t\t\u003d 209,\n\t/**\u003c When a message is fully sent, if QoS0 this callback is generated\n\t * to locally \u0022acknowledge\u0022 it. For QoS1, this callback is only\n\t * generated when the matching PUBACK is received. Return nonzero to\n\t * close the wsi.\n\t */\n\tLWS_CALLBACK_MQTT_RESEND\t\t\t\t\u003d 210,\n\t/**\u003c In QoS1 or QoS2, this callback is generated instead of the _ACK one\n\t * if we timed out waiting for a PUBACK or a PUBREC, and we must resend\n\t * the message. Return nonzero to close the wsi.\n\t */\n\tLWS_CALLBACK_MQTT_UNSUBSCRIBE_TIMEOUT\t\t\t\u003d 211,\n\t/**\u003c When a UNSUBSCRIBE is sent, this callback is generated instead of\n\t * the _UNSUBSCRIBED one if we timed out waiting for a UNSUBACK.\n\t * Return nonzero to close the wsi.\n\t */\n\tLWS_CALLBACK_MQTT_SHADOW_TIMEOUT\t\t\t\u003d 212,\n\t/**\u003c When a Device Shadow is sent, this callback is generated if we\n\t * timed out waiting for a response from AWS IoT.\n\t * Return nonzero to close the wsi.\n\t */\n\n\t/****** add new things just above ---^ ******/\n\n\tLWS_CALLBACK_USER \u003d 1000,\n\t/**\u003c user code can use any including above without fear of clashes */\n};\n\n\n\n/**\n * typedef lws_callback_function() - User server actions\n * \u005cparam wsi:\tOpaque websocket instance pointer\n * \u005cparam reason:\tThe reason for the call\n * \u005cparam user:\tPointer to per-session user data allocated by library\n * \u005cparam in:\t\tPointer used for some callback reasons\n * \u005cparam len:\tLength set for some callback reasons\n *\n *\tThis callback is the way the user controls what is served. All the\n *\tprotocol detail is hidden and handled by the library.\n *\n *\tFor each connection / session there is user data allocated that is\n *\tpointed to by \u0022user\u0022. You set the size of this user data area when\n *\tthe library is initialized with lws_create_server.\n */\ntypedef int\nlws_callback_function(struct lws *wsi, enum lws_callback_reasons reason,\n\t\t void *user, void *in, size_t len);\n\n#define LWS_CB_REASON_AUX_BF__CGI\t\t1\n#define LWS_CB_REASON_AUX_BF__PROXY\t\t2\n#define LWS_CB_REASON_AUX_BF__CGI_CHUNK_END\t4\n#define LWS_CB_REASON_AUX_BF__CGI_HEADERS\t8\n#define LWS_CB_REASON_AUX_BF__PROXY_TRANS_END\t16\n#define LWS_CB_REASON_AUX_BF__PROXY_HEADERS\t32\n///@}\n","s":{"c":1713557012,"u": 2879}} ],"g": 8215,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 1, "si": 0, "db":0, "di":0, "sat":0, "lfc": "0000"}