 |
libwebsockets
Lightweight C library for HTML5 websockets
|
|
libwebsockets
Lightweight C library for HTML5 websockets
|
Data Structures | |
| struct | lws_ssl_info |
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 <lib/libwebsockets.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 <lib/libwebsockets.h>
enum lws_callback_reasons - reason you're getting a protocol callback
| Enumerator | |
|---|---|
| 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. |
| 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 a handshake with the remote server |
| LWS_CALLBACK_CLOSED | when the websocket session ends |
| LWS_CALLBACK_CLOSED_HTTP | when a HTTP (non-websocket) session ends |
| 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_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_SERVER_WRITEABLE | See LWS_CALLBACK_CLIENT_WRITEABLE |
| 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_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. 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_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_SERVER_NEW_CLIENT_INSTANTIATED | A new client just had been connected, accepted, and instantiated into the pool. 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_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_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* |
| 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_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;
if (len < 100)
return 1;
*p += sprintf(*p, "Cookie: a=b\x0d\x0a");
return 0;
Notice if you add anything, you just have to take care about the CRLF on the line you added. Obviously this callback is optional, if you don't handle it everything is fine. Notice the callback is coming to protocols[0] all the time, because there is no specific protocol negotiated yet. |
| 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_CONFIRM_EXTENSION_SUPPORTED | When a 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_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_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_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_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_WS_EXT_DEFAULTS | Gives client connections an opportunity to adjust negotiated extension defaults. |
| 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_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 | This simply indicates data was received on the HTTP client connection. It does NOT drain or provide the data. This exists to neatly allow a proxying type situation, where this incoming data will go out on another connection. If the outgoing connection stalls, we should stall processing the incoming data. So a handler for this in that case should simply set a flag to indicate there is incoming data ready and ask for a writeable callback on the outgoing connection. In the writable callback he can check the flag and then get and drain the waiting incoming data using lws_http_client_read(). This will use callbacks to LWS_CALLBACK_RECEIVE_CLIENT_HTTP_READ to get and drain the incoming data, where it should be sent back out on the outgoing connection. |
| 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_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_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_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_ADD_HEADERS | This gives your user code a chance to add headers to a transaction bound to your protocol. 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_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_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_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_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_ADOPT_FILE | RAW mode file was adopted (equivalent to 'wsi created') |
| LWS_CALLBACK_RAW_RX_FILE | RAW mode file has something to read |
| 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_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_CHILD_WRITE_VIA_PARENT | Child has been marked with parent_carries_io attribute, so lws_write directs the to this callback at the parent, in is a struct lws_write_passthru containing the args the lws_write() was called with. |
| LWS_CALLBACK_CHILD_CLOSING | Sent to parent to notify them a child is closing / being destroyed. in is the child wsi. |
| 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_USER | user code can use any including above without fear of clashes |
1.8.14