 |
libwebsockets
Lightweight C library for HTML5 websockets
|
|
libwebsockets
Lightweight C library for HTML5 websockets
|
Data Structures | |
| struct | lws_ssl_info |
| struct | lws_acme_cert_aging_args |
| struct | lws_filter_network_conn_args |
Typedefs | |
| typedef int | lws_callback_function(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len) |
The protocol callback is the primary way lws interacts with user code. For one of a list of a few dozen reasons the callback gets called at some event to be handled.
All of the events can be ignored, returning 0 is taken as "OK" and returning nonzero in most cases indicates that the connection should be closed.
| typedef int lws_callback_function(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len) |
#include <include/libwebsockets/lws-callbacks.h>
typedef lws_callback_function() - User server actions
| wsi | Opaque websocket instance pointer |
| reason | The reason for the call |
| user | Pointer to per-session user data allocated by library |
| in | Pointer used for some callback reasons |
| len | Length set for some callback reasons This callback is the way the user controls what is served. All the protocol detail is hidden and handled by the library. For each connection / session there is user data allocated that is pointed to by "user". You set the size of this user data area when the library is initialized with lws_create_server. |
| enum lws_callback_reasons |
#include <include/libwebsockets/lws-callbacks.h>
enum lws_callback_reasons - reason you're getting a protocol callback
| Enumerator | |
|---|---|
| LWS_CALLBACK_PROTOCOL_INIT | One-time call per protocol, per-vhost using it, so it can do initial setup / allocations etc |
| LWS_CALLBACK_PROTOCOL_DESTROY | One-time call per protocol, per-vhost using it, indicating this protocol won't get used at all after this callback, the vhost is getting destroyed. Take the opportunity to deallocate everything that was allocated by the protocol. |
| LWS_CALLBACK_WSI_CREATE | outermost (earliest) wsi create notification to protocols[0] |
| LWS_CALLBACK_WSI_DESTROY | outermost (latest) wsi destroy notification to protocols[0] |
| LWS_CALLBACK_WSI_TX_CREDIT_GET | manually-managed connection received TX credit (len is int32) |
| LWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS | if configured for including OpenSSL support, this callback allows your user code to perform extra SSL_CTX_load_verify_locations() or similar calls to direct OpenSSL where to find certificates the client can use to confirm the remote server identity. user is the OpenSSL SSL_CTX* |
| LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS | if configured for including OpenSSL support, this callback allows your user code to load extra certificates into the server which allow it to verify the validity of certificates returned by clients. user is the server's OpenSSL SSL_CTX* and in is the lws_vhost |
| LWS_CALLBACK_OPENSSL_PERFORM_CLIENT_CERT_VERIFICATION | if the libwebsockets vhost was created with the option LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT, then this callback is generated during OpenSSL verification of the cert sent from the client. It is sent to protocol[0] callback as no protocol has been negotiated on the connection yet. Notice that the libwebsockets context and wsi are both NULL during this callback. See http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html to understand more detail about the OpenSSL callback that generates this libwebsockets callback and the meanings of the arguments passed. In this callback, user is the x509_ctx, in is the ssl pointer and len is preverify_ok Notice that this callback maintains libwebsocket return conventions, return 0 to mean the cert is OK or 1 to fail it. This also means that if you don't handle this callback then the default callback action of returning 0 allows the client certificates. |
| LWS_CALLBACK_OPENSSL_CONTEXT_REQUIRES_PRIVATE_KEY | if configured for including OpenSSL support but no private key file has been specified (ssl_private_key_filepath is NULL), this is called to allow the user to set the private key directly via libopenssl and perform further operations if required; this might be useful in situations where the private key is not directly accessible by the OS, for example if it is stored on a smartcard. user is the server's OpenSSL SSL_CTX* |
| LWS_CALLBACK_SSL_INFO | SSL connections only. An event you registered an interest in at the vhost has occurred on a connection using the vhost. in is a pointer to a struct lws_ssl_info containing information about the event |
| LWS_CALLBACK_OPENSSL_PERFORM_SERVER_CERT_VERIFICATION | Similar to LWS_CALLBACK_OPENSSL_PERFORM_CLIENT_CERT_VERIFICATION this callback is called during OpenSSL verification of the cert sent from the server to the client. It is sent to protocol[0] callback as no protocol has been negotiated on the connection yet. Notice that the wsi is set because lws_client_connect_via_info was successful. See http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html to understand more detail about the OpenSSL callback that generates this libwebsockets callback and the meanings of the arguments passed. In this callback, user is the x509_ctx, in is the ssl pointer and len is preverify_ok. THIS IS NOT RECOMMENDED BUT if a cert validation error shall be overruled and cert shall be accepted as ok, X509_STORE_CTX_set_error((X509_STORE_CTX*)user, X509_V_OK); must be called and return value must be 0 to mean the cert is OK; returning 1 will fail the cert in any case. This also means that if you don't handle this callback then the default callback action of returning 0 will not accept the certificate in case of a validation error decided by the SSL lib. This is expected and secure behaviour when validating certificates. Note: LCCSCF_ALLOW_SELFSIGNED and LCCSCF_SKIP_SERVER_CERT_HOSTNAME_CHECK still work without this callback being implemented. |
| LWS_CALLBACK_SERVER_NEW_CLIENT_INSTANTIATED | A new client has been accepted by the ws server. This callback allows setting any relevant property to it. Because this happens immediately after the instantiation of a new client, there's no websocket protocol selected yet so this callback is issued only to protocol 0. Only wsi is defined, pointing to the new client, and the return value is ignored. |
| LWS_CALLBACK_HTTP | an http request has come from a client that is not asking to upgrade the connection to a websocket one. This is a chance to serve http content, for example, to send a script to the client which will then open the websockets connection. in points to the URI path requested and lws_serve_http_file() makes it very simple to send back a file to the client. Normally after sending the file you are done with the http connection, since the rest of the activity will come by websockets from the script that was delivered by http, so you will want to return 1; to close and free up the connection. |
| LWS_CALLBACK_HTTP_BODY | the next len bytes data from the http request body HTTP connection is now available in in. |
| LWS_CALLBACK_HTTP_BODY_COMPLETION | the expected amount of http request body has been delivered |
| LWS_CALLBACK_HTTP_FILE_COMPLETION | a file requested to be sent down http link has completed. |
| LWS_CALLBACK_HTTP_WRITEABLE | you can write more down the http protocol link now. |
| LWS_CALLBACK_CLOSED_HTTP | when a HTTP (non-websocket) session ends |
| LWS_CALLBACK_FILTER_HTTP_CONNECTION | called when the request has been received and parsed from the client, but the response is not sent yet. Return non-zero to disallow the connection. user is a pointer to the connection user space allocation, in is the URI, eg, "/" In your handler you can use the public APIs lws_hdr_total_length() / lws_hdr_copy() to access all of the headers using the header enums lws_token_indexes from libwebsockets.h to check for and read the supported header presence and content before deciding to allow the http connection to proceed or to kill the connection. |
| LWS_CALLBACK_ADD_HEADERS | This gives your user code a chance to add headers to a server transaction bound to your protocol. (see LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER to add headers to a client transaction) Only case LWS_CALLBACK_ADD_HEADERS:
struct lws_process_html_args *args =
(struct lws_process_html_args *)in;
if (lws_add_http_header_by_name(wsi,
(unsigned char *)"set-cookie:",
(unsigned char *)cookie, cookie_len,
(unsigned char **)&args->p,
(unsigned char *)args->p + args->max_len))
return 1;
break;
|
| LWS_CALLBACK_VERIFY_BASIC_AUTHORIZATION | This gives the user code a chance to accept or reject credentials provided HTTP to basic authorization. It will only be called if the http mount's authentication_mode is set to LWSAUTHM_BASIC_AUTH_CALLBACK |
| LWS_CALLBACK_CHECK_ACCESS_RIGHTS | This gives the user code a chance to forbid an http access. |
| LWS_CALLBACK_PROCESS_HTML | This gives your user code a chance to mangle outgoing HTML. |
| LWS_CALLBACK_HTTP_BIND_PROTOCOL | By default, all HTTP handling is done in protocols[0]. However you can bind different protocols (by name) to different parts of the URL space using callback mounts. This callback occurs in the new protocol when a wsi is bound to that protocol. Any protocol allocation related to the http transaction processing should be created then. These specific callbacks are necessary because with HTTP/1.1, a single connection may perform at series of different transactions at different URLs, thus the lifetime of the protocol bind is just for one transaction, not connection. |
| LWS_CALLBACK_HTTP_DROP_PROTOCOL | This is called when a transaction is unbound from a protocol. It indicates the connection completed its transaction and may do something different now. Any protocol allocation related to the http transaction processing should be destroyed. |
| LWS_CALLBACK_HTTP_CONFIRM_UPGRADE | This is your chance to reject an HTTP upgrade action. The name of the protocol being upgraded to is in 'in', and the ah is still bound to the wsi, so you can look at the headers. The default of returning 0 (ie, also if not handled) means the upgrade may proceed. Return <0 to just hang up the connection, or >0 if you have rejected the connection by returning http headers and response code yourself. There is no need for you to call transaction_completed() as the caller will take care of it when it sees you returned >0. |
| LWS_CALLBACK_ESTABLISHED_CLIENT_HTTP | The HTTP client connection has succeeded, and is now connected to the server |
| LWS_CALLBACK_CLOSED_CLIENT_HTTP | The HTTP client connection is closing |
| LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ | This is generated by lws_http_client_read() used to drain incoming data. In the case the incoming data was chunked, it will be split into multiple smaller callbacks for each chunk block, removing the chunk headers. If not chunked, it will appear all in one callback. |
| LWS_CALLBACK_RECEIVE_CLIENT_HTTP | This indicates data was received on the HTTP client connection. It does NOT actually drain or provide the data, so if you are doing http client, you MUST handle this and call lws_http_client_read(). Failure to deal with it as in the minimal examples may cause spinning around the event loop as it's continuously signalled the same data is available for read. The related minimal examples show how to handle it. It's possible to defer calling lws_http_client_read() if you use rx flow control to stop further rx handling on the connection until you did deal with it. But normally you would call it in the handler. lws_http_client_read() strips any chunked framing and calls back with only payload data to LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ. The chunking is the reason this is not just all done in one callback for http. |
| LWS_CALLBACK_COMPLETED_CLIENT_HTTP | The client transaction completed... at the moment this is the same as closing since transaction pipelining on client side is not yet supported. |
| LWS_CALLBACK_CLIENT_HTTP_WRITEABLE | when doing an HTTP type client connection, you can call lws_client_http_body_pending(wsi, 1) from LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER to get these callbacks sending the HTTP headers. From this callback, when you have sent everything, you should let lws know by calling lws_client_http_body_pending(wsi, 0) |
| LWS_CALLBACK_CLIENT_HTTP_REDIRECT | we're handling a 3xx redirect... return nonzero to hang up |
| LWS_CALLBACK_ESTABLISHED | (VH) after the server completes a handshake with an incoming client. If you built the library with ssl support, in is a pointer to the ssl struct associated with the connection or NULL. b0 of len is set if the connection was made using ws-over-h2 |
| LWS_CALLBACK_CLOSED | when the websocket session ends |
| LWS_CALLBACK_SERVER_WRITEABLE | See LWS_CALLBACK_CLIENT_WRITEABLE |
| LWS_CALLBACK_RECEIVE | data has appeared for this server endpoint from a remote client, it can be found at *in and is len bytes long |
| LWS_CALLBACK_RECEIVE_PONG | servers receive PONG packets with this callback reason |
| LWS_CALLBACK_WS_PEER_INITIATED_CLOSE | The peer has sent an unsolicited Close WS packet. in and len are the optional close code (first 2 bytes, network order) and the optional additional information which is not defined in the standard, and may be a string or non human-readable data. If you return 0 lws will echo the close and then close the connection. If you return nonzero lws will just close the connection. |
| LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION | called when the handshake has been received and parsed from the client, but the response is not sent yet. Return non-zero to disallow the connection. user is a pointer to the connection user space allocation, in is the requested protocol name In your handler you can use the public APIs lws_hdr_total_length() / lws_hdr_copy() to access all of the headers using the header enums lws_token_indexes from libwebsockets.h to check for and read the supported header presence and content before deciding to allow the handshake to proceed or to kill the connection. |
| LWS_CALLBACK_CONFIRM_EXTENSION_OKAY | When the server handshake code sees that it does support a requested extension, before accepting the extension by additing to the list sent back to the client it gives this callback just to check that it's okay to use that extension. It calls back to the requested protocol and with in being the extension name, len is 0 and user is valid. Note though at this time the ESTABLISHED callback hasn't happened yet so if you initialize user content there, user content during this callback might not be useful for anything. |
| LWS_CALLBACK_CLIENT_CONNECTION_ERROR | the request client connection has been unable to complete a handshake with the remote server. If in is non-NULL, you can find an error string of length len where it points to Diagnostic strings that may be returned include "getaddrinfo (ipv6) failed"
"unknown address family"
"getaddrinfo (ipv4) failed"
"set socket opts failed"
"insert wsi failed"
"lws_ssl_client_connect1 failed"
"lws_ssl_client_connect2 failed"
"Peer hung up"
"read failed"
"HS: URI missing"
"HS: Redirect code but no Location"
"HS: URI did not parse"
"HS: Redirect failed"
"HS: Server did not return 200"
"HS: OOM"
"HS: disallowed by client filter"
"HS: disallowed at ESTABLISHED"
"HS: ACCEPT missing"
"HS: ws upgrade response not 101"
"HS: UPGRADE missing"
"HS: Upgrade to something other than websocket"
"HS: CONNECTION missing"
"HS: UPGRADE malformed"
"HS: PROTOCOL malformed"
"HS: Cannot match protocol"
"HS: EXT: list too big"
"HS: EXT: failed setting defaults"
"HS: EXT: failed parsing defaults"
"HS: EXT: failed parsing options"
"HS: EXT: Rejects server options"
"HS: EXT: unknown ext"
"HS: Accept hash wrong"
"HS: Rejected by filter cb"
"HS: OOM"
"HS: SO_SNDBUF failed"
"HS: Rejected at CLIENT_ESTABLISHED"
|
| LWS_CALLBACK_CLIENT_FILTER_PRE_ESTABLISH | this is the last chance for the client user code to examine the http headers and decide to reject the connection. If the content in the headers is interesting to the client (url, etc) it needs to copy it out at this point since it will be destroyed before the CLIENT_ESTABLISHED call |
| LWS_CALLBACK_CLIENT_ESTABLISHED | after your client connection completed the websocket upgrade handshake with the remote server |
| LWS_CALLBACK_CLIENT_CLOSED | when a client websocket session ends |
| LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER | this callback happens when a client handshake is being compiled. user is NULL, in is a char **, it's pointing to a char * which holds the next location in the header buffer where you can add headers, and len is the remaining space in the header buffer, which is typically some hundreds of bytes. So, to add a canned cookie, your handler code might look similar to: char **p = (char **)in, *end = (*p) + len;
if (lws_add_http_header_by_token(wsi, WSI_TOKEN_HTTP_COOKIE,
(unsigned char)"a=b", 3, p, end))
return -1;
See LWS_CALLBACK_ADD_HEADERS for adding headers to server transactions. |
| LWS_CALLBACK_CLIENT_RECEIVE | data has appeared from the server for the client connection, it can be found at *in and is len bytes long |
| LWS_CALLBACK_CLIENT_RECEIVE_PONG | clients receive PONG packets with this callback reason |
| LWS_CALLBACK_CLIENT_WRITEABLE | If you call lws_callback_on_writable() on a connection, you will get one of these callbacks coming when the connection socket is able to accept another write packet without blocking. If it already was able to take another packet without blocking, you'll get this callback at the next call to the service loop function. Notice that CLIENTs get LWS_CALLBACK_CLIENT_WRITEABLE and servers get LWS_CALLBACK_SERVER_WRITEABLE. |
| LWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED | When a ws client connection is being prepared to start a handshake to a server, each supported extension is checked with protocols[0] callback with this reason, giving the user code a chance to suppress the claim to support that extension by returning non-zero. If unhandled, by default 0 will be returned and the extension support included in the header to the server. Notice this callback comes to protocols[0]. |
| LWS_CALLBACK_WS_EXT_DEFAULTS | Gives client connections an opportunity to adjust negotiated extension defaults. |
| LWS_CALLBACK_FILTER_NETWORK_CONNECTION | called when a client connects to the server at network level; the connection is accepted but then passed to this callback to decide whether to hang up immediately or not, based on the client IP. user_data in the callback points to a struct lws_filter_network_conn_args that is prepared with the sockfd, and the peer's address information. in contains the connection socket's descriptor. Since the client connection information is not available yet, wsi still pointing to the main server socket. Return non-zero to terminate the connection before sending or receiving anything. Because this happens immediately after the network connection from the client, there's no websocket protocol selected yet so this callback is issued only to protocol 0. |
| LWS_CALLBACK_GET_THREAD_ID | lws can accept callback when writable requests from other threads, if you implement this callback and return an opaque current thread ID integer. |
| LWS_CALLBACK_ADD_POLL_FD | lws normally deals with its poll() or other event loop internally, but in the case you are integrating with another server you will need to have lws sockets share a polling array with the other server. This and the other POLL_FD related callbacks let you put your specialized poll array interface code in the callback for protocol 0, the first protocol you support, usually the HTTP protocol in the serving case. This callback happens when a socket needs to be added to the polling loop: in points to a struct lws_pollargs; the fd member of the struct is the file descriptor, and events contains the active events If you are using the internal lws polling / event loop you can just ignore these callbacks. |
| LWS_CALLBACK_DEL_POLL_FD | This callback happens when a socket descriptor needs to be removed from an external polling array. in is again the struct lws_pollargs containing the fd member to be removed. If you are using the internal polling loop, you can just ignore it. |
| LWS_CALLBACK_CHANGE_MODE_POLL_FD | This callback happens when lws wants to modify the events for a connection. in is the struct lws_pollargs with the fd to change. The new event mask is in events member and the old mask is in the prev_events member. If you are using the internal polling loop, you can just ignore it. |
| LWS_CALLBACK_LOCK_POLL | These allow the external poll changes driven by lws to participate in an external thread locking scheme around the changes, so the whole thing is threadsafe. These are called around three activities in the library,
|
| LWS_CALLBACK_UNLOCK_POLL | See LWS_CALLBACK_LOCK_POLL, ignore if using lws internal poll |
| LWS_CALLBACK_CGI | CGI: CGI IO events on stdin / out / err are sent here on protocols[0]. The provided |
| LWS_CALLBACK_CGI_TERMINATED | CGI: The related CGI process ended, this is called before the wsi is closed. Used to, eg, terminate chunking. The provided |
| LWS_CALLBACK_CGI_STDIN_DATA | CGI: Data is, to be sent to the CGI process stdin, eg from a POST body. The provided |
| LWS_CALLBACK_CGI_STDIN_COMPLETED | CGI: no more stdin is coming. The provided |
| LWS_CALLBACK_CGI_PROCESS_ATTACH | CGI: Sent when the CGI process is spawned for the wsi. The len parameter is the PID of the child process |
| LWS_CALLBACK_SESSION_INFO | This is only generated by user code using generic sessions. It's used to get a |
| LWS_CALLBACK_GS_EVENT | Indicates an event happened to the Generic Sessions session. |
| LWS_CALLBACK_HTTP_PMO | per-mount options for this connection, called before the normal LWS_CALLBACK_HTTP when the mount has per-mount options. |
| LWS_CALLBACK_RAW_PROXY_CLI_RX | RAW mode client (outgoing) RX |
| LWS_CALLBACK_RAW_PROXY_SRV_RX | RAW mode server (listening) RX |
| LWS_CALLBACK_RAW_PROXY_CLI_CLOSE | RAW mode client (outgoing) is closing |
| LWS_CALLBACK_RAW_PROXY_SRV_CLOSE | RAW mode server (listening) is closing |
| LWS_CALLBACK_RAW_PROXY_CLI_WRITEABLE | RAW mode client (outgoing) may be written |
| LWS_CALLBACK_RAW_PROXY_SRV_WRITEABLE | RAW mode server (listening) may be written |
| LWS_CALLBACK_RAW_PROXY_CLI_ADOPT | RAW mode client (onward) accepted socket was adopted (equivalent to 'wsi created') |
| LWS_CALLBACK_RAW_PROXY_SRV_ADOPT | RAW mode server (listening) accepted socket was adopted (equivalent to 'wsi created') |
| LWS_CALLBACK_RAW_RX | RAW mode connection RX |
| LWS_CALLBACK_RAW_CLOSE | RAW mode connection is closing |
| LWS_CALLBACK_RAW_WRITEABLE | RAW mode connection may be written |
| LWS_CALLBACK_RAW_ADOPT | RAW mode connection was adopted (equivalent to 'wsi created') |
| LWS_CALLBACK_RAW_CONNECTED | outgoing client RAW mode connection was connected |
| LWS_CALLBACK_RAW_ADOPT_FILE | RAW mode file was adopted (equivalent to 'wsi created') |
| LWS_CALLBACK_RAW_RX_FILE | This is the indication the RAW mode file has something to read. This doesn't actually do the read of the file and len is always 0... your code should do the read having been informed there is something to read now. |
| LWS_CALLBACK_RAW_WRITEABLE_FILE | RAW mode file is writeable |
| LWS_CALLBACK_RAW_CLOSE_FILE | RAW mode wsi that adopted a file is closing |
| LWS_CALLBACK_TIMER | When the time elapsed after a call to lws_set_timer_usecs(wsi, usecs) is up, the wsi will get one of these callbacks. The deadline can be continuously extended into the future by later calls to lws_set_timer_usecs() before the deadline expires, or cancelled by lws_set_timer_usecs(wsi, -1); |
| LWS_CALLBACK_EVENT_WAIT_CANCELLED | This is sent to every protocol of every vhost in response to lws_cancel_service() or lws_cancel_service_pt(). This callback is serialized in the lws event loop normally, even if the lws_cancel_service[_pt]() call was from a different thread. |
| LWS_CALLBACK_CHILD_CLOSING | Sent to parent to notify them a child is closing / being destroyed. in is the child wsi. |
| LWS_CALLBACK_CONNECTING | Called before a socketfd is about to connect(). In is the socketfd, cast to a (void *), if on a platform where the socketfd is an int, recover portably using (lws_sockfd_type)(intptr_t)in. It's also called in SOCKS5 or http_proxy cases where the socketfd is going to try to connect to its proxy. |
| LWS_CALLBACK_VHOST_CERT_AGING | When a vhost TLS cert has its expiry checked, this callback is broadcast to every protocol of every vhost in case the protocol wants to take some action with this information. |
| LWS_CALLBACK_VHOST_CERT_UPDATE | When a vhost TLS cert is being updated, progress is reported to the vhost in question here, including completion and failure. in points to optional JSON, and len represents the connection state using enum lws_cert_update_state |
| LWS_CALLBACK_MQTT_ACK | When a message is fully sent, if QoS0 this callback is generated to locally "acknowledge" it. For QoS1, this callback is only generated when the matching PUBACK is received. Return nonzero to close the wsi. |
| LWS_CALLBACK_MQTT_RESEND | In QoS1 or QoS2, this callback is generated instead of the _ACK one if we timed out waiting for a PUBACK or a PUBREC, and we must resend the message. Return nonzero to close the wsi. |
| LWS_CALLBACK_MQTT_UNSUBSCRIBE_TIMEOUT | When a UNSUBSCRIBE is sent, this callback is generated instead of the _UNSUBSCRIBED one if we timed out waiting for a UNSUBACK. Return nonzero to close the wsi. |
| LWS_CALLBACK_USER | user code can use any including above without fear of clashes |
1.9.1