1 <h2>lws_client_reset - retarget a connected wsi to start over with a new connection (ie, redirect) this only works if still in HTTP, ie, not upgraded yet</h2>
3 <b>lws_client_reset</b>
4 (<i>struct lws *</i> <b>wsi</b>,
6 <i>const char *</i> <b>address</b>,
7 <i>int</i> <b>port</b>,
8 <i>const char *</i> <b>path</b>,
9 <i>const char *</i> <b>host</b>)
19 network address of the new server
27 uri path to connect to on the new server
31 host header to send to the new server
34 <h2>lws_client_connect_via_info - Connect to another websocket server</h2>
36 <b>lws_client_connect_via_info</b>
37 (<i>struct lws_client_connect_info *</i> <b>i</b>)
41 <dd>pointer to lws_client_connect_info struct
45 This function creates a connection to a remote server
48 <h2>lws_client_connect_extended - Connect to another websocket server DEPRECATED use lws_client_connect_via_info</h2>
50 <b>lws_client_connect_extended</b>
51 (<i>struct lws_context *</i> <b>context</b>,
52 <i>const char *</i> <b>address</b>,
53 <i>int</i> <b>port</b>,
54 <i>int</i> <b>ssl_connection</b>,
55 <i>const char *</i> <b>path</b>,
56 <i>const char *</i> <b>host</b>,
57 <i>const char *</i> <b>origin</b>,
58 <i>const char *</i> <b>protocol</b>,
59 <i>int</i> <b>ietf_version_or_minus_one</b>,
60 <i>void *</i> <b>userdata</b>)
66 <dd>Remote server address, eg, "myserver.com"
68 <dd>Port to connect to on the remote server, eg, 80
69 <dt><b>ssl_connection</b>
70 <dd>0 = ws://, 1 = wss:// encrypted, 2 = wss:// allow self
73 <dd>Websocket path on server
75 <dd>Hostname on server
77 <dd>Socket origin name
79 <dd>Comma-separated list of protocols being asked for from
80 the server, or just one. The server will pick the one it
82 <dt><b>ietf_version_or_minus_one</b>
83 <dd>-1 to ask to connect using the default, latest
84 protocol supported, or the specific protocol ordinal
86 <dd>Pre-allocated user data
90 This function creates a connection to a remote server
93 <h2>lws_client_connect - Connect to another websocket server DEPRECATED use lws_client_connect_via_info</h2>
95 <b>lws_client_connect</b>
96 (<i>struct lws_context *</i> <b>context</b>,
97 <i>const char *</i> <b>address</b>,
98 <i>int</i> <b>port</b>,
99 <i>int</i> <b>ssl_connection</b>,
100 <i>const char *</i> <b>path</b>,
101 <i>const char *</i> <b>host</b>,
102 <i>const char *</i> <b>origin</b>,
103 <i>const char *</i> <b>protocol</b>,
104 <i>int</i> <b>ietf_version_or_minus_one</b>)
108 <dd>Websocket context
110 <dd>Remote server address, eg, "myserver.com"
112 <dd>Port to connect to on the remote server, eg, 80
113 <dt><b>ssl_connection</b>
114 <dd>0 = ws://, 1 = wss:// encrypted, 2 = wss:// allow self
117 <dd>Websocket path on server
119 <dd>Hostname on server
121 <dd>Socket origin name
123 <dd>Comma-separated list of protocols being asked for from
124 the server, or just one. The server will pick the one it
125 likes best. If you don't want to specify a protocol, which is
126 legal, use NULL here.
127 <dt><b>ietf_version_or_minus_one</b>
128 <dd>-1 to ask to connect using the default, latest
129 protocol supported, or the specific protocol ordinal
133 This function creates a connection to a remote server
136 <h2>lws_get_library_version - </h2>
138 <b>lws_get_library_version</b>
139 (<i></i> <b>void</b>)
148 returns a const char * to a string like "1.1 178d78c"
149 representing the library version followed by the git head hash it
153 <h2>lws_create_context - Create the websocket handler</h2>
154 <i>struct lws_context *</i>
155 <b>lws_create_context</b>
156 (<i>struct lws_context_creation_info *</i> <b>info</b>)
160 <dd>pointer to struct with parameters
164 This function creates the listening socket (if serving) and takes care
165 of all initialization in one step.
167 After initialization, it returns a struct lws_context * that
168 represents this server. After calling, user code needs to take care
169 of calling <b>lws_service</b> with the context pointer to get the
170 server's sockets serviced. This must be done in the same process
171 context as the initialization call.
173 The protocol callback functions are called for a handful of events
174 including http requests coming in, websocket connections becoming
175 established, and data arriving; it's also called periodically to allow
178 HTTP requests are sent always to the FIRST protocol in <tt><b>protocol</b></tt>, since
179 at that time websocket protocol has not been negotiated. Other
180 protocols after the first one never see any HTTP callack activity.
182 The server created is a simple http server by default; part of the
183 websocket standard is upgrading this http connection to a websocket one.
185 This allows the same server to provide files like scripts and favicon /
186 images or whatever over http and dynamic data over websockets all in
187 one place; they're all handled in the user callback.
190 <h2>lws_context_destroy - Destroy the websocket context</h2>
192 <b>lws_context_destroy</b>
193 (<i>struct lws_context *</i> <b>context</b>)
197 <dd>Websocket context
201 This function closes any active connections and then frees the
202 context. After calling this, any further use of the context is
206 <h2>lws_return_http_status - Return simple http status</h2>
208 <b>lws_return_http_status</b>
209 (<i>struct lws *</i> <b>wsi</b>,
210 <i>unsigned int</i> <b>code</b>,
211 <i>const char *</i> <b>html_body</b>)
215 <dd>Websocket instance (available from user callback)
217 <dd>Status index, eg, 404
219 <dd>User-readable HTML description < 1KB, or NULL
223 Helper to report HTTP errors back to the client cleanly and
227 <h2>lws_set_timeout - marks the wsi as subject to a timeout</h2>
229 <b>lws_set_timeout</b>
230 (<i>struct lws *</i> <b>wsi</b>,
231 <i>enum pending_timeout</i> <b>reason</b>,
232 <i>int</i> <b>secs</b>)
236 <dd>Websocket connection instance
245 You will not need this unless you are doing something special
248 <h2>lws_get_peer_addresses - Get client address information</h2>
250 <b>lws_get_peer_addresses</b>
251 (<i>struct lws *</i> <b>wsi</b>,
252 <i>lws_sockfd_type</i> <b>fd</b>,
253 <i>char *</i> <b>name</b>,
254 <i>int</i> <b>name_len</b>,
255 <i>char *</i> <b>rip</b>,
256 <i>int</i> <b>rip_len</b>)
260 <dd>Local struct lws associated with
262 <dd>Connection socket descriptor
264 <dd>Buffer to take client address name
266 <dd>Length of client address name buffer
268 <dd>Buffer to take client address IP dotted quad
270 <dd>Length of client address IP buffer
274 This function fills in <tt><b>name</b></tt> and <tt><b>rip</b></tt> with the name and IP of
275 the client connected with socket descriptor <tt><b>fd</b></tt>. Names may be
276 truncated if there is not enough room. If either cannot be
277 determined, they will be returned as valid zero-length strings.
280 <h2>lws_context_user - get the user data associated with the context</h2>
281 <i>LWS_EXTERN void *</i>
282 <b>lws_context_user</b>
283 (<i>struct lws_context *</i> <b>context</b>)
287 <dd>Websocket context
291 This returns the optional user allocation that can be attached to
292 the context the sockets live in at context_create time. It's a way
293 to let all sockets serviced in the same context share data without
294 using globals statics in the user code.
297 <h2>lws_callback_all_protocol - Callback all connections using the given protocol with the given reason</h2>
299 <b>lws_callback_all_protocol</b>
300 (<i>struct lws_context *</i> <b>context</b>,
301 <i>const struct lws_protocols *</i> <b>protocol</b>,
302 <i>int</i> <b>reason</b>)
306 <dd>Protocol whose connections will get callbacks
308 <dd>Callback reason index
311 <h2>lws_get_socket_fd - returns the socket file descriptor</h2>
313 <b>lws_get_socket_fd</b>
314 (<i>struct lws *</i> <b>wsi</b>)
318 <dd>Websocket connection instance
323 You will not need this unless you are doing something special
326 <h2>lws_rx_flow_control - Enable and disable socket servicing for received packets.</h2>
328 <b>lws_rx_flow_control</b>
329 (<i>struct lws *</i> <b>wsi</b>,
330 <i>int</i> <b>enable</b>)
334 <dd>Websocket connection instance to get callback for
336 <dd>0 = disable read servicing for this connection, 1 = enable
341 If the output side of a server process becomes choked, this allows flow
342 control for the input side.
345 <h2>lws_rx_flow_allow_all_protocol - Allow all connections with this protocol to receive</h2>
347 <b>lws_rx_flow_allow_all_protocol</b>
348 (<i>const struct lws_context *</i> <b>context</b>,
349 <i>const struct lws_protocols *</i> <b>protocol</b>)
353 <dd>all connections using this protocol will be allowed to receive
358 When the user server code realizes it can accept more input, it can
359 call this to have the RX flow restriction removed from all connections using
363 <h2>lws_canonical_hostname - returns this host's hostname</h2>
365 <b>lws_canonical_hostname</b>
366 (<i>struct lws_context *</i> <b>context</b>)
370 <dd>Websocket context
375 This is typically used by client code to fill in the host parameter
376 when making a client connection. You can only call it after the context
380 <h2>lws_set_proxy - Setups proxy to lws_context.</h2>
383 (<i>struct lws_context *</i> <b>context</b>,
384 <i>const char *</i> <b>proxy</b>)
388 <dd>pointer to struct lws_context you want set proxy to
390 <dd>pointer to c string containing proxy in format address:port
394 Returns 0 if proxy string was parsed and proxy was setup.
395 Returns -1 if <tt><b>proxy</b></tt> is NULL or has incorrect format.
397 This is only required if your OS does not provide the http_proxy
398 environment variable (eg, OSX)
400 IMPORTANT! You should call this function right after creation of the
401 lws_context and before call to connect. If you call this
402 function after connect behavior is undefined.
403 This function will override proxy settings made on lws_context
404 creation with <b>genenv</b> call.
407 <h2>lws_get_protocol - Returns a protocol pointer from a websocket connection.</h2>
408 <i>const struct lws_protocols *</i>
409 <b>lws_get_protocol</b>
410 (<i>struct lws *</i> <b>wsi</b>)
414 <dd>pointer to struct websocket you want to know the protocol of
419 Some apis can act on all live connections of a given protocol,
420 this is how you can get a pointer to the active protocol if needed.
423 <h2>lws_set_log_level - Set the logging bitfield</h2>
425 <b>lws_set_log_level</b>
426 (<i>int</i> <b>level</b>,
427 <i>void (*</i><b>func</b>) <i>(int level, const char *line)</i>)
431 <dd>OR together the LLL_ debug contexts you want output from
435 log level defaults to "err", "warn" and "notice" contexts enabled and
439 <h2>lws_is_ssl - Find out if connection is using SSL</h2>
442 (<i>struct lws *</i> <b>wsi</b>)
446 <dd>websocket connection to check
450 Returns 0 if the connection is not using SSL, 1 if using SSL and
451 using verified cert, and 2 if using SSL but the cert was not
452 checked (appears for client wsi told to skip check on connection)
455 <h2>lws_partial_buffered - find out if lws buffered the last write</h2>
457 <b>lws_partial_buffered</b>
458 (<i>struct lws *</i> <b>wsi</b>)
462 <dd>websocket connection to check
466 Returns 1 if you cannot use lws_write because the last
467 write on this connection is still buffered, and can't be cleared without
468 returning to the service loop and waiting for the connection to be
471 If you will try to do >1 lws_write call inside a single
472 WRITEABLE callback, you must check this after every write and bail if
473 set, ask for a new writeable callback and continue writing from there.
475 This is never set at the start of a writeable callback, but any write
479 <h2>lws_parse_uri - </h2>
480 <i>LWS_EXTERN int</i>
482 (<i>char *</i> <b>p</b>,
483 <i>const char **</i> <b>prot</b>,
484 <i>const char **</i> <b>ads</b>,
485 <i>int *</i> <b>port</b>,
486 <i>const char **</i> <b>path</b>)
490 <dd>incoming uri string.. will get written to
492 <dd>result pointer for protocol part (https://)
494 <dd>result pointer for address part
496 <dd>result pointer for port part
498 <dd>result pointer for path part
502 Notice it does so by dropping '\0' into input string
503 and the leading / on the path is consequently lost
506 <h2>lws_cancel_service - Cancel servicing of pending websocket activity</h2>
508 <b>lws_cancel_service</b>
509 (<i>struct lws_context *</i> <b>context</b>)
513 <dd>Websocket context
517 This function let a call to <b>lws_service</b> waiting for a timeout
520 There is no <b>poll</b> in MBED3, he will fire callbacks when he feels like
524 <h2>lws_cancel_service_pt - Cancel servicing of pending socket activity on one thread</h2>
526 <b>lws_cancel_service_pt</b>
527 (<i>struct lws *</i> <b>wsi</b>)
531 <dd>Cancel service on the thread this wsi is serviced by
535 This function let a call to <b>lws_service</b> waiting for a timeout
539 <h2>lws_cancel_service - Cancel ALL servicing of pending socket activity</h2>
541 <b>lws_cancel_service</b>
542 (<i>struct lws_context *</i> <b>context</b>)
546 <dd>Websocket context
550 This function let a call to <b>lws_service</b> waiting for a timeout
554 <h2>lws_cancel_service - Cancel servicing of pending websocket activity</h2>
556 <b>lws_cancel_service</b>
557 (<i>struct lws_context *</i> <b>context</b>)
561 <dd>Websocket context
565 This function let a call to <b>lws_service</b> waiting for a timeout
569 <h2>lws_write - Apply protocol then write data to client</h2>
572 (<i>struct lws *</i> <b>wsi</b>,
573 <i>unsigned char *</i> <b>buf</b>,
574 <i>size_t</i> <b>len</b>,
575 <i>enum lws_write_protocol</i> <b>wp</b>)
579 <dd>Websocket instance (available from user callback)
581 <dd>The data to send. For data being sent on a websocket
582 connection (ie, not default http), this buffer MUST have
583 LWS_PRE bytes valid BEFORE the pointer.
584 This is so the protocol header data can be added in-situ.
586 <dd>Count of the data bytes in the payload starting from buf
590 This function provides the way to issue data back to the client
591 for both http and websocket protocols.
593 In the case of sending using websocket protocol, be sure to allocate
594 valid storage before and after buf as explained above. This scheme
595 allows maximum efficiency of sending data and protocol in a single
596 packet while not burdening the user code with any protocol knowledge.
598 Return may be -1 for a fatal error needing connection close, or a
599 positive number reflecting the amount of bytes actually sent. This
600 can be less than the requested number of bytes due to OS memory
601 pressure at any given time.
604 <h2>lws_hdr_fragment_length - </h2>
606 <b>lws_hdr_fragment_length</b>
607 (<i>struct lws *</i> <b>wsi</b>,
608 <i>enum lws_token_indexes</i> <b>h</b>,
609 <i>int</i> <b>frag_idx</b>)
613 <dd>websocket connection
615 <dd>which header index we are interested in
617 <dd>which fragment of <tt><b>h</b></tt> we want to get the length of
621 The returned length does not include the space for a
625 <h2>lws_hdr_total_length - </h2>
627 <b>lws_hdr_total_length</b>
628 (<i>struct lws *</i> <b>wsi</b>,
629 <i>enum lws_token_indexes</i> <b>h</b>)
633 <dd>websocket connection
635 <dd>which header index we are interested in
639 The returned length does not include the space for a
643 <h2>lws_hdr_copy_fragment - </h2>
645 <b>lws_hdr_copy_fragment</b>
646 (<i>struct lws *</i> <b>wsi</b>,
647 <i>char *</i> <b>dst</b>,
648 <i>int</i> <b>len</b>,
649 <i>enum lws_token_indexes</i> <b>h</b>,
650 <i>int</i> <b>frag_idx</b>)
654 <dd>websocket connection
656 <dd>destination buffer
658 <dd>length of destination buffer
660 <dd>which header index we are interested in
664 The buffer length <tt><b>len</b></tt> must include space for an additional
665 terminating '\0', or it will fail returning -1.
666 If the requested fragment index is not present, it fails
670 <h2>lws_hdr_copy - </h2>
673 (<i>struct lws *</i> <b>wsi</b>,
674 <i>char *</i> <b>dst</b>,
675 <i>int</i> <b>len</b>,
676 <i>enum lws_token_indexes</i> <b>h</b>)
680 <dd>websocket connection
682 <dd>destination buffer
684 <dd>length of destination buffer
686 <dd>which header index we are interested in
690 The buffer length <tt><b>len</b></tt> must include space for an additional
691 terminating '\0', or it will fail returning -1.
694 <h2>lws_frame_is_binary - </h2>
696 <b>lws_frame_is_binary</b>
697 (<i>struct lws *</i> <b>wsi</b>)
701 <dd>the connection we are inquiring about
705 This is intended to be called from the LWS_CALLBACK_RECEIVE callback if
706 it's interested to see if the frame it's dealing with was sent in binary
710 <h2>lws_remaining_packet_payload - Bytes to come before "overall" rx packet is complete</h2>
712 <b>lws_remaining_packet_payload</b>
713 (<i>struct lws *</i> <b>wsi</b>)
717 <dd>Websocket instance (available from user callback)
721 This function is intended to be called from the callback if the
722 user code is interested in "complete packets" from the client.
723 libwebsockets just passes through payload as it comes and issues a buffer
724 additionally when it hits a built-in limit. The LWS_CALLBACK_RECEIVE
725 callback handler can use this API to find out if the buffer it has just
726 been given is the last piece of a "complete packet" from the client --
727 when that is the case <b>lws_remaining_packet_payload</b> will return
730 Many protocols won't care becuse their packets are always small.
733 <h2>lws_callback_on_writable - Request a callback when this socket becomes able to be written to without blocking</h2>
735 <b>lws_callback_on_writable</b>
736 (<i>struct lws *</i> <b>wsi</b>)
740 <dd>Websocket connection instance to get callback for
743 <h2>lws_callback_on_writable_all_protocol - Request a callback for all connections using the given protocol when it becomes possible to write to each socket without blocking in turn.</h2>
745 <b>lws_callback_on_writable_all_protocol</b>
746 (<i>const struct lws_context *</i> <b>context</b>,
747 <i>const struct lws_protocols *</i> <b>protocol</b>)
753 <dd>Protocol whose connections will get callbacks
756 <h2>lws_http_transaction_completed - wait for new http transaction or close</h2>
757 <i>int LWS_WARN_UNUSED_RESULT</i>
758 <b>lws_http_transaction_completed</b>
759 (<i>struct lws *</i> <b>wsi</b>)
763 <dd>websocket connection
767 Returns 1 if the HTTP connection must close now
768 Returns 0 and resets connection to wait for new HTTP header /
769 transaction if possible
772 <h2>lws_adopt_socket - adopt foreign socket as if listen socket accepted it</h2>
774 <b>lws_adopt_socket</b>
775 (<i>struct lws_context *</i> <b>context</b>,
776 <i>lws_sockfd_type</i> <b>accept_fd</b>)
782 <dd>fd of already-accepted socket to adopt
786 Either returns new wsi bound to accept_fd, or closes accept_fd and
787 returns NULL, having cleaned up any new wsi pieces.
789 LWS adopts the socket in http serving mode, it's ready to accept an upgrade
790 to ws or just serve http.
793 <h2>lws_serve_http_file - Send a file back to the client using http</h2>
795 <b>lws_serve_http_file</b>
796 (<i>struct lws *</i> <b>wsi</b>,
797 <i>const char *</i> <b>file</b>,
798 <i>const char *</i> <b>content_type</b>,
799 <i>const char *</i> <b>other_headers</b>,
800 <i>int</i> <b>other_headers_len</b>)
804 <dd>Websocket instance (available from user callback)
806 <dd>The file to issue over http
807 <dt><b>content_type</b>
808 <dd>The http content type, eg, text/html
809 <dt><b>other_headers</b>
810 <dd>NULL or pointer to header string
811 <dt><b>other_headers_len</b>
812 <dd>length of the other headers if non-NULL
816 This function is intended to be called from the callback in response
817 to http requests from the client. It allows the callback to issue
818 local files down the http link in a single step.
820 Returning <0 indicates error and the wsi should be closed. Returning
821 >0 indicates the file was completely sent and
822 <b>lws_http_transaction_completed</b> called on the wsi (and close if != 0)
823 ==0 indicates the file transfer is started and needs more service later,
824 the wsi should be left alone.
827 <h2>lws_service_fd_tsi - Service polled socket with something waiting</h2>
829 <b>lws_service_fd_tsi</b>
830 (<i>struct lws_context *</i> <b>context</b>,
831 <i>struct lws_pollfd *</i> <b>pollfd</b>,
832 <i>int</i> <b>tsi</b>)
836 <dd>Websocket context
838 <dd>The pollfd entry describing the socket fd and which events
843 This function takes a pollfd that has POLLIN or POLLOUT activity and
844 services it according to the state of the associated
847 The one call deals with all "service" that might happen on a socket
848 including listen accepts, http files as well as websocket protocol.
850 If a pollfd says it has something, you can just pass it to
851 <b>lws_service_fd</b> whether it is a socket handled by lws or not.
852 If it sees it is a lws socket, the traffic will be handled and
853 pollfd->revents will be zeroed now.
855 If the socket is foreign to lws, it leaves revents alone. So you can
856 see if you should service yourself by checking the pollfd revents
857 after letting lws try to service it.
860 <h2>lws_service - Service any pending websocket activity</h2>
863 (<i>struct lws_context *</i> <b>context</b>,
864 <i>int</i> <b>timeout_ms</b>)
868 <dd>Websocket context
869 <dt><b>timeout_ms</b>
870 <dd>Timeout for poll; 0 means return immediately if nothing needed
871 service otherwise block and service immediately, returning
872 after the timeout if nothing needed service.
876 This function deals with any pending websocket traffic, for three
877 kinds of event. It handles these events on both server and client
878 types of connection the same.
880 1) Accept new connections to our context's server
882 2) Call the receive callback for incoming frame data received by
883 server or client connections.
885 You need to call this service function periodically to all the above
886 functions to happen; if your application is single-threaded you can
887 just call it in your main event loop.
889 Alternatively you can fork a new process that asynchronously handles
890 calling this service in a loop. In that case you are happy if this
891 call blocks your thread until it needs to take care of something and
892 would call it with a large nonzero timeout. Your loop then takes no
893 CPU while there is nothing happening.
895 If you are calling it in a single-threaded app, you don't want it to
896 wait around blocking other things in your loop from happening, so you
897 would call it with a timeout_ms of 0, so it returns immediately if
898 nothing is pending, or as soon as it services whatever was pending.
901 <h2>struct lws_plat_file_ops - Platform-specific file operations</h2>
902 <b>struct lws_plat_file_ops</b> {<br>
903 <i>lws_filefd_type (*</i><b>open</b>) <i>(struct lws *wsi, const char *filename,unsigned long *filelen, int flags)</i>;<br>
904 <i>int (*</i><b>close</b>) <i>(struct lws *wsi, lws_filefd_type fd)</i>;<br>
905 <i>unsigned long (*</i><b>seek_cur</b>) <i>(struct lws *wsi, lws_filefd_type fd,long offset_from_cur_pos)</i>;<br>
906 <i>int (*</i><b>read</b>) <i>(struct lws *wsi, lws_filefd_type fd, unsigned long *amount,unsigned char *buf, unsigned long len)</i>;<br>
907 <i>int (*</i><b>write</b>) <i>(struct lws *wsi, lws_filefd_type fd, unsigned long *amount,unsigned char *buf, unsigned long len)</i>;<br>
912 <dd>Open file (always binary access if plat supports it)
913 filelen is filled on exit to be the length of the file
914 flags should be set to O_RDONLY or O_RDWR
918 <dd>Seek from current position
920 <dd>Read fron file *amount is set on exit to amount read
922 <dd>Write to file *amount is set on exit as amount written
927 These provide platform-agnostic ways to deal with filesystem access in the
928 library and in the user code.
931 <h2>lws_callback_function - User server actions</h2>
933 <b>lws_callback_function</b>
934 (<i>struct lws *</i> <b>wsi</b>,
935 <i>enum lws_callback_reasons</i> <b>reason</b>,
936 <i>void *</i> <b>user</b>,
937 <i>void *</i> <b>in</b>,
938 <i>size_t</i> <b>len</b>)
942 <dd>Opaque websocket instance pointer
944 <dd>The reason for the call
946 <dd>Pointer to per-session user data allocated by library
948 <dd>Pointer used for some callback reasons
950 <dd>Length set for some callback reasons
954 This callback is the way the user controls what is served. All the
955 protocol detail is hidden and handled by the library.
957 For each connection / session there is user data allocated that is
958 pointed to by "user". You set the size of this user data area when
959 the library is initialized with lws_create_server.
961 You get an opportunity to initialize user data when called back with
962 LWS_CALLBACK_ESTABLISHED reason.
964 <h3>LWS_CALLBACK_ESTABLISHED</h3>
966 after the server completes a handshake with
967 an incoming client. If you built the library
968 with ssl support, <tt><b>in</b></tt> is a pointer to the
969 ssl struct associated with the connection or
972 <h3>LWS_CALLBACK_CLIENT_CONNECTION_ERROR</h3>
974 the request client connection has
975 been unable to complete a handshake with the remote server. If
976 in is non-NULL, you can find an error string of length len where
979 <h3>LWS_CALLBACK_CLIENT_FILTER_PRE_ESTABLISH</h3>
981 this is the last chance for the
982 client user code to examine the http headers
983 and decide to reject the connection. If the
984 content in the headers is interesting to the
985 client (url, etc) it needs to copy it out at
986 this point since it will be destroyed before
987 the CLIENT_ESTABLISHED call
989 <h3>LWS_CALLBACK_CLIENT_ESTABLISHED</h3>
991 after your client connection completed
992 a handshake with the remote server
994 <h3>LWS_CALLBACK_CLOSED</h3>
996 when the websocket session ends
998 <h3>LWS_CALLBACK_CLOSED_HTTP</h3>
1000 when a HTTP (non-websocket) session ends
1002 <h3>LWS_CALLBACK_RECEIVE</h3>
1004 data has appeared for this server endpoint from a
1005 remote client, it can be found at *in and is
1008 <h3>LWS_CALLBACK_CLIENT_RECEIVE_PONG</h3>
1010 if you elected to see PONG packets,
1011 they appear with this callback reason. PONG
1012 packets only exist in 04+ protocol
1014 <h3>LWS_CALLBACK_CLIENT_RECEIVE</h3>
1016 data has appeared from the server for the
1017 client connection, it can be found at *in and
1020 <h3>LWS_CALLBACK_HTTP</h3>
1022 an http request has come from a client that is not
1023 asking to upgrade the connection to a websocket
1024 one. This is a chance to serve http content,
1025 for example, to send a script to the client
1026 which will then open the websockets connection.
1027 <tt><b>in</b></tt> points to the URI path requested and
1028 <b>lws_serve_http_file</b> makes it very
1029 simple to send back a file to the client.
1030 Normally after sending the file you are done
1031 with the http connection, since the rest of the
1032 activity will come by websockets from the script
1033 that was delivered by http, so you will want to
1034 return 1; to close and free up the connection.
1035 That's important because it uses a slot in the
1036 total number of client connections allowed set
1039 <h3>LWS_CALLBACK_HTTP_BODY</h3>
1041 the next <tt><b>len</b></tt> bytes data from the http
1042 request body HTTP connection is now available in <tt><b>in</b></tt>.
1044 <h3>LWS_CALLBACK_HTTP_BODY_COMPLETION</h3>
1046 the expected amount of http request
1047 body has been delivered
1049 <h3>LWS_CALLBACK_HTTP_WRITEABLE</h3>
1051 you can write more down the http protocol
1054 <h3>LWS_CALLBACK_HTTP_FILE_COMPLETION</h3>
1056 a file requested to be send down
1057 http link has completed.
1059 <h3>LWS_CALLBACK_SERVER_WRITEABLE</h3>
1062 <b>lws_callback_on_writable</b> on a connection, you will
1063 get one of these callbacks coming when the connection socket
1064 is able to accept another write packet without blocking.
1065 If it already was able to take another packet without blocking,
1066 you'll get this callback at the next call to the service loop
1067 function. Notice that CLIENTs get LWS_CALLBACK_CLIENT_WRITEABLE
1068 and servers get LWS_CALLBACK_SERVER_WRITEABLE.
1070 <h3>LWS_CALLBACK_FILTER_NETWORK_CONNECTION</h3>
1072 called when a client connects to
1073 the server at network level; the connection is accepted but then
1074 passed to this callback to decide whether to hang up immediately
1075 or not, based on the client IP. <tt><b>in</b></tt> contains the connection
1076 socket's descriptor. Since the client connection information is
1077 not available yet, <tt><b>wsi</b></tt> still pointing to the main server socket.
1078 Return non-zero to terminate the connection before sending or
1079 receiving anything. Because this happens immediately after the
1080 network connection from the client, there's no websocket protocol
1081 selected yet so this callback is issued only to protocol 0.
1083 <h3>LWS_CALLBACK_SERVER_NEW_CLIENT_INSTANTIATED</h3>
1085 A new client just had
1086 been connected, accepted, and instantiated into the pool. This
1087 callback allows setting any relevant property to it. Because this
1088 happens immediately after the instantiation of a new client,
1089 there's no websocket protocol selected yet so this callback is
1090 issued only to protocol 0. Only <tt><b>wsi</b></tt> is defined, pointing to the
1091 new client, and the return value is ignored.
1093 <h3>LWS_CALLBACK_FILTER_HTTP_CONNECTION</h3>
1095 called when the request has
1096 been received and parsed from the client, but the response is
1097 not sent yet. Return non-zero to disallow the connection.
1098 <tt><b>user</b></tt> is a pointer to the connection user space allocation,
1099 <tt><b>in</b></tt> is the URI, eg, "/"
1100 In your handler you can use the public APIs
1101 <b>lws_hdr_total_length</b> / <b>lws_hdr_copy</b> to access all of the
1102 headers using the header enums lws_token_indexes from
1103 libwebsockets.h to check for and read the supported header
1104 presence and content before deciding to allow the http
1105 connection to proceed or to kill the connection.
1107 <h3>LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION</h3>
1109 called when the handshake has
1110 been received and parsed from the client, but the response is
1111 not sent yet. Return non-zero to disallow the connection.
1112 <tt><b>user</b></tt> is a pointer to the connection user space allocation,
1113 <tt><b>in</b></tt> is the requested protocol name
1114 In your handler you can use the public APIs
1115 <b>lws_hdr_total_length</b> / <b>lws_hdr_copy</b> to access all of the
1116 headers using the header enums lws_token_indexes from
1117 libwebsockets.h to check for and read the supported header
1118 presence and content before deciding to allow the handshake
1119 to proceed or to kill the connection.
1121 <h3>LWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS</h3>
1124 including OpenSSL support, this callback allows your user code
1125 to perform extra <b>SSL_CTX_load_verify_locations</b> or similar
1126 calls to direct OpenSSL where to find certificates the client
1127 can use to confirm the remote server identity. <tt><b>user</b></tt> is the
1130 <h3>LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS</h3>
1133 including OpenSSL support, this callback allows your user code
1134 to load extra certifcates into the server which allow it to
1135 verify the validity of certificates returned by clients. <tt><b>user</b></tt>
1136 is the server's OpenSSL SSL_CTX*
1138 <h3>LWS_CALLBACK_OPENSSL_CONTEXT_REQUIRES_PRIVATE_KEY</h3>
1141 including OpenSSL support but no private key file has been
1142 specified (ssl_private_key_filepath is NULL), this is called to
1143 allow the user to set the private key directly via libopenssl
1144 and perform further operations if required; this might be useful
1145 in situations where the private key is not directly accessible
1146 by the OS, for example if it is stored on a smartcard
1147 <tt><b>user</b></tt> is the server's OpenSSL SSL_CTX*
1149 <h3>LWS_CALLBACK_OPENSSL_PERFORM_CLIENT_CERT_VERIFICATION</h3>
1152 libwebsockets context was created with the option
1153 LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT, then this
1154 callback is generated during OpenSSL verification of the cert
1155 sent from the client. It is sent to protocol[0] callback as
1156 no protocol has been negotiated on the connection yet.
1157 Notice that the libwebsockets context and wsi are both NULL
1158 during this callback. See
1162 //www.openssl.org/docs/ssl/SSL_CTX_set_verify.html
1163 to understand more detail about the OpenSSL callback that
1164 generates this libwebsockets callback and the meanings of the
1165 arguments passed. In this callback, <tt><b>user</b></tt> is the x509_ctx,
1166 <tt><b>in</b></tt> is the ssl pointer and <tt><b>len</b></tt> is preverify_ok
1167 Notice that this callback maintains libwebsocket return
1168 conventions, return 0 to mean the cert is OK or 1 to fail it.
1169 This also means that if you don't handle this callback then
1170 the default callback action of returning 0 allows the client
1173 <h3>LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER</h3>
1175 this callback happens
1176 when a client handshake is being compiled. <tt><b>user</b></tt> is NULL,
1177 <tt><b>in</b></tt> is a char **, it's pointing to a char * which holds the
1178 next location in the header buffer where you can add
1179 headers, and <tt><b>len</b></tt> is the remaining space in the header buffer,
1180 which is typically some hundreds of bytes. So, to add a canned
1181 cookie, your handler code might look similar to:
1183 char **p = (char **)in;
1188 *p += sprintf(*p, "Cookie: a=b\x0d\x0a");
1192 Notice if you add anything, you just have to take care about
1193 the CRLF on the line you added. Obviously this callback is
1194 optional, if you don't handle it everything is fine.
1196 Notice the callback is coming to protocols[0] all the time,
1197 because there is no specific protocol handshook yet.
1199 <h3>LWS_CALLBACK_CONFIRM_EXTENSION_OKAY</h3>
1201 When the server handshake code
1202 sees that it does support a requested extension, before
1203 accepting the extension by additing to the list sent back to
1204 the client it gives this callback just to check that it's okay
1205 to use that extension. It calls back to the requested protocol
1206 and with <tt><b>in</b></tt> being the extension name, <tt><b>len</b></tt> is 0 and <tt><b>user</b></tt> is
1207 valid. Note though at this time the ESTABLISHED callback hasn't
1208 happened yet so if you initialize <tt><b>user</b></tt> content there, <tt><b>user</b></tt>
1209 content during this callback might not be useful for anything.
1210 Notice this callback comes to protocols[0].
1212 <h3>LWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED</h3>
1215 connection is being prepared to start a handshake to a server,
1216 each supported extension is checked with protocols[0] callback
1217 with this reason, giving the user code a chance to suppress the
1218 claim to support that extension by returning non-zero. If
1219 unhandled, by default 0 will be returned and the extension
1220 support included in the header to the server. Notice this
1221 callback comes to protocols[0].
1223 <h3>LWS_CALLBACK_PROTOCOL_INIT</h3>
1225 One-time call per protocol so it can
1226 do initial setup / allocations etc
1228 <h3>LWS_CALLBACK_PROTOCOL_DESTROY</h3>
1230 One-time call per protocol indicating
1231 this protocol won't get used at all after this callback, the
1232 context is getting destroyed. Take the opportunity to
1233 deallocate everything that was allocated by the protocol.
1235 <h3>LWS_CALLBACK_WSI_CREATE</h3>
1237 outermost (earliest) wsi create notification
1239 <h3>LWS_CALLBACK_WSI_DESTROY</h3>
1241 outermost (latest) wsi destroy notification
1243 The next five reasons are optional and only need taking care of if you
1244 will be integrating libwebsockets sockets into an external polling
1247 For these calls, <tt><b>in</b></tt> points to a struct lws_pollargs that
1248 contains <tt><b>fd</b></tt>, <tt><b>events</b></tt> and <tt><b>prev_events</b></tt> members
1250 <h3>LWS_CALLBACK_ADD_POLL_FD</h3>
1252 libwebsocket deals with its <b>poll</b> loop
1253 internally, but in the case you are integrating with another
1254 server you will need to have libwebsocket sockets share a
1255 polling array with the other server. This and the other
1256 POLL_FD related callbacks let you put your specialized
1257 poll array interface code in the callback for protocol 0, the
1258 first protocol you support, usually the HTTP protocol in the
1260 This callback happens when a socket needs to be
1262 <h3>added to the polling loop</h3>
1264 <tt><b>in</b></tt> points to a struct
1265 lws_pollargs; the <tt><b>fd</b></tt> member of the struct is the file
1266 descriptor, and <tt><b>events</b></tt> contains the active events.
1268 If you are using the internal polling loop (the "service"
1269 callback), you can just ignore these callbacks.
1271 <h3>LWS_CALLBACK_DEL_POLL_FD</h3>
1273 This callback happens when a socket descriptor
1274 needs to be removed from an external polling array. <tt><b>in</b></tt> is
1275 again the struct lws_pollargs containing the <tt><b>fd</b></tt> member
1276 to be removed. If you are using the internal polling
1277 loop, you can just ignore it.
1279 <h3>LWS_CALLBACK_CHANGE_MODE_POLL_FD</h3>
1281 This callback happens when
1282 libwebsockets wants to modify the events for a connectiion.
1283 <tt><b>in</b></tt> is the struct lws_pollargs with the <tt><b>fd</b></tt> to change.
1284 The new event mask is in <tt><b>events</b></tt> member and the old mask is in
1285 the <tt><b>prev_events</b></tt> member.
1286 If you are using the internal polling loop, you can just ignore
1289 <h3>LWS_CALLBACK_UNLOCK_POLL</h3>
1291 These allow the external poll changes driven
1292 by libwebsockets to participate in an external thread locking
1293 scheme around the changes, so the whole thing is threadsafe.
1294 These are called around three activities in the library,
1295 - inserting a new wsi in the wsi / fd table (len=1)
1296 - deleting a wsi from the wsi / fd table (len=1)
1297 - changing a wsi's POLLIN/OUT state (len=0)
1298 Locking and unlocking external synchronization objects when
1299 len == 1 allows external threads to be synchronized against
1300 wsi lifecycle changes if it acquires the same lock for the
1301 duration of wsi dereference from the other thread context.
1303 <h3>LWS_CALLBACK_WS_PEER_INITIATED_CLOSE</h3>
1305 The peer has sent an unsolicited Close WS packet. <tt><b>in</b></tt> and
1306 <tt><b>len</b></tt> are the optional close code (first 2 bytes, network
1307 order) and the optional additional information which is not
1308 defined in the standard, and may be a string or non-human-
1310 If you return 0 lws will echo the close and then close the
1311 connection. If you return nonzero lws will just close the
1315 <h2>lws_extension_callback_function - Hooks to allow extensions to operate</h2>
1317 <b>lws_extension_callback_function</b>
1318 (<i>struct lws_context *</i> <b>context</b>,
1319 <i>const struct lws_extension *</i> <b>ext</b>,
1320 <i>struct lws *</i> <b>wsi</b>,
1321 <i>enum lws_extension_callback_reasons</i> <b>reason</b>,
1322 <i>void *</i> <b>user</b>,
1323 <i>void *</i> <b>in</b>,
1324 <i>size_t</i> <b>len</b>)
1328 <dd>Websockets context
1332 <dd>Opaque websocket instance pointer
1334 <dd>The reason for the call
1336 <dd>Pointer to ptr to per-session user data allocated by library
1338 <dd>Pointer used for some callback reasons
1340 <dd>Length set for some callback reasons
1342 <h3>Description</h3>
1344 Each extension that is active on a particular connection receives
1345 callbacks during the connection lifetime to allow the extension to
1346 operate on websocket data and manage itself.
1348 Libwebsockets takes care of allocating and freeing "user" memory for
1349 each active extension on each connection. That is what is pointed to
1350 by the <tt><b>user</b></tt> parameter.
1352 <h3>LWS_EXT_CB_CONSTRUCT</h3>
1354 called when the server has decided to
1355 select this extension from the list provided by the client,
1356 just before the server will send back the handshake accepting
1357 the connection with this extension active. This gives the
1358 extension a chance to initialize its connection context found
1359 in <tt><b>user</b></tt>.
1361 <h3>LWS_EXT_CB_CLIENT_CONSTRUCT</h3>
1363 same as LWS_EXT_CB_CONSTRUCT
1364 but called when client is instantiating this extension. Some
1365 extensions will work the same on client and server side and then
1366 you can just merge handlers for both CONSTRUCTS.
1368 <h3>LWS_EXT_CB_DESTROY</h3>
1370 called when the connection the extension was
1371 being used on is about to be closed and deallocated. It's the
1372 last chance for the extension to deallocate anything it has
1373 allocated in the user data (pointed to by <tt><b>user</b></tt>) before the
1374 user data is deleted. This same callback is used whether you
1375 are in client or server instantiation context.
1377 <h3>LWS_EXT_CB_PACKET_RX_PREPARSE</h3>
1379 when this extension was active on
1380 a connection, and a packet of data arrived at the connection,
1381 it is passed to this callback to give the extension a chance to
1382 change the data, eg, decompress it. <tt><b>user</b></tt> is pointing to the
1383 extension's private connection context data, <tt><b>in</b></tt> is pointing
1384 to an lws_tokens struct, it consists of a char * pointer called
1385 token, and an int called token_len. At entry, these are
1386 set to point to the received buffer and set to the content
1387 length. If the extension will grow the content, it should use
1388 a new buffer allocated in its private user context data and
1389 set the pointed-to lws_tokens members to point to its buffer.
1391 <h3>LWS_EXT_CB_PACKET_TX_PRESEND</h3>
1393 this works the same way as
1394 LWS_EXT_CB_PACKET_RX_PREPARSE above, except it gives the
1395 extension a chance to change websocket data just before it will
1396 be sent out. Using the same lws_token pointer scheme in <tt><b>in</b></tt>,
1397 the extension can change the buffer and the length to be
1398 transmitted how it likes. Again if it wants to grow the
1399 buffer safely, it should copy the data into its own buffer and
1400 set the lws_tokens token pointer to it.
1403 <h2>struct lws_protocols - List of protocols and handlers server supports.</h2>
1404 <b>struct lws_protocols</b> {<br>
1405 <i>const char *</i> <b>name</b>;<br>
1406 <i>lws_callback_function *</i> <b>callback</b>;<br>
1407 <i>size_t</i> <b>per_session_data_size</b>;<br>
1408 <i>size_t</i> <b>rx_buffer_size</b>;<br>
1409 <i>unsigned int</i> <b>id</b>;<br>
1410 <i>void *</i> <b>user</b>;<br>
1415 <dd>Protocol name that must match the one given in the client
1416 Javascript new WebSocket(url, 'protocol') name.
1418 <dd>The service callback used for this protocol. It allows the
1419 service action for an entire protocol to be encapsulated in
1420 the protocol-specific callback
1421 <dt><b>per_session_data_size</b>
1422 <dd>Each new connection using this protocol gets
1423 this much memory allocated on connection establishment and
1424 freed on connection takedown. A pointer to this per-connection
1425 allocation is passed into the callback in the 'user' parameter
1426 <dt><b>rx_buffer_size</b>
1427 <dd>if you want atomic frames delivered to the callback, you
1428 should set this to the size of the biggest legal frame that
1429 you support. If the frame size is exceeded, there is no
1430 error, but the buffer will spill to the user callback when
1431 full, which you can detect by using
1432 <b>lws_remaining_packet_payload</b>. Notice that you
1433 just talk about frame size here, the LWS_PRE
1434 and post-padding are automatically also allocated on top.
1436 <dd>ignored by lws, but useful to contain user information bound
1437 to the selected protocol. For example if this protocol was
1438 called "myprotocol-v2", you might set id to 2, and the user
1439 code that acts differently according to the version can do so by
1440 switch (wsi->protocol->id), user code might use some bits as
1441 capability flags based on selected protocol version, etc.
1443 <dd>User provided context data at the protocol level.
1444 Accessible via lws_get_protocol(wsi)->user
1445 This should not be confused with wsi->user, it is not the same.
1446 The library completely ignores any value in here.
1448 <h3>Description</h3>
1450 This structure represents one protocol supported by the server. An
1451 array of these structures is passed to <b>lws_create_server</b>
1452 allows as many protocols as you like to be handled by one server.
1454 The first protocol given has its callback used for user callbacks when
1455 there is no agreed protocol name, that's true during HTTP part of the
1457 <h3>connection and true if the client did not send a Protocol</h3>
1462 <h2>struct lws_ext_options - Option arguments to the extension. These are used in the negotiation at ws upgrade time. The helper function lws_ext_parse_options() uses these to generate callbacks</h2>
1463 <b>struct lws_ext_options</b> {<br>
1464 <i>const char *</i> <b>name</b>;<br>
1465 <i>enum lws_ext_options_types</i> <b>type</b>;<br>
1470 <dd>Option name, eg, "server_no_context_takeover"
1472 <dd>What kind of args the option can take
1475 <h2>struct lws_extension - An extension we know how to cope with</h2>
1476 <b>struct lws_extension</b> {<br>
1477 <i>const char *</i> <b>name</b>;<br>
1478 <i>lws_extension_callback_function *</i> <b>callback</b>;<br>
1479 <i>const char *</i> <b>client_offer</b>;<br>
1484 <dd>Formal extension name, eg, "permessage-deflate"
1486 <dd>Service callback
1487 <dt><b>client_offer</b>
1488 <dd>String containing exts and options client offers
1491 <h2>struct lws_context_creation_info - parameters to create context with</h2>
1492 <b>struct lws_context_creation_info</b> {<br>
1493 <i>int</i> <b>port</b>;<br>
1494 <i>const char *</i> <b>iface</b>;<br>
1495 <i>const struct lws_protocols *</i> <b>protocols</b>;<br>
1496 <i>const struct lws_extension *</i> <b>extensions</b>;<br>
1497 <i>const struct lws_token_limits *</i> <b>token_limits</b>;<br>
1498 <i>const char *</i> <b>ssl_cert_filepath</b>;<br>
1499 <i>const char *</i> <b>ssl_private_key_filepath</b>;<br>
1500 <i>const char *</i> <b>ssl_ca_filepath</b>;<br>
1501 <i>const char *</i> <b>ssl_cipher_list</b>;<br>
1502 <i>const char *</i> <b>http_proxy_address</b>;<br>
1503 <i>unsigned int</i> <b>http_proxy_port</b>;<br>
1504 <i>int</i> <b>gid</b>;<br>
1505 <i>int</i> <b>uid</b>;<br>
1506 <i>unsigned int</i> <b>options</b>;<br>
1507 <i>void *</i> <b>user</b>;<br>
1508 <i>int</i> <b>ka_time</b>;<br>
1509 <i>int</i> <b>ka_probes</b>;<br>
1510 <i>int</i> <b>ka_interval</b>;<br>
1511 #ifdef LWS_OPENSSL_SUPPORT<br>
1512 <i>void *</i> <b>provided_client_ssl_ctx</b>;<br>
1514 <i>void *</i> <b>provided_client_ssl_ctx</b>;<br>
1516 <i>short</i> <b>max_http_header_data</b>;<br>
1517 <i>short</i> <b>max_http_header_pool</b>;<br>
1518 <i>unsigned int</i> <b>count_threads</b>;<br>
1519 <i>unsigned int</i> <b>fd_limit_per_thread</b>;<br>
1520 <i>unsigned int</i> <b>timeout_secs</b>;<br>
1525 <dd>Port to listen on... you can use CONTEXT_PORT_NO_LISTEN to
1526 suppress listening on any port, that's what you want if you are
1527 not running a websocket server at all but just using it as a
1530 <dd>NULL to bind the listen socket to all interfaces, or the
1531 interface name, eg, "eth2"
1532 <dt><b>protocols</b>
1533 <dd>Array of structures listing supported protocols and a protocol-
1534 specific callback for each one. The list is ended with an
1535 entry that has a NULL callback pointer.
1536 It's not const because we write the owning_server member
1537 <dt><b>extensions</b>
1538 <dd>NULL or array of lws_extension structs listing the
1539 extensions this context supports. If you configured with
1540 --without-extensions, you should give NULL here.
1541 <dt><b>token_limits</b>
1542 <dd>NULL or struct lws_token_limits pointer which is initialized
1543 with a token length limit for each possible WSI_TOKEN_***
1544 <dt><b>ssl_cert_filepath</b>
1545 <dd>If libwebsockets was compiled to use ssl, and you want
1546 to listen using SSL, set to the filepath to fetch the
1547 server cert from, otherwise NULL for unencrypted
1548 <dt><b>ssl_private_key_filepath</b>
1549 <dd>filepath to private key if wanting SSL mode;
1550 if this is set to NULL but sll_cert_filepath is set, the
1551 OPENSSL_CONTEXT_REQUIRES_PRIVATE_KEY callback is called
1552 to allow setting of the private key directly via openSSL
1554 <dt><b>ssl_ca_filepath</b>
1555 <dd>CA certificate filepath or NULL
1556 <dt><b>ssl_cipher_list</b>
1557 <dd>List of valid ciphers to use (eg,
1558 "RC4-MD5:RC4-SHA:AES128-SHA:AES256-SHA:HIGH:!DSS:!aNULL"
1559 or you can leave it as NULL to get "DEFAULT"
1560 <dt><b>http_proxy_address</b>
1561 <dd>If non-NULL, attempts to proxy via the given address.
1562 If proxy auth is required, use format
1563 "username:password<tt><b>server</b></tt>:port"
1564 <dt><b>http_proxy_port</b>
1565 <dd>If http_proxy_address was non-NULL, uses this port at
1568 <dd>group id to change to after setting listen socket, or -1.
1570 <dd>user id to change to after setting listen socket, or -1.
1572 <dd>0, or LWS_SERVER_OPTION_... bitfields
1574 <dd>optional user pointer that can be recovered via the context
1575 pointer using lws_context_user
1577 <dd>0 for no keepalive, otherwise apply this keepalive timeout to
1578 all libwebsocket sockets, client or server
1579 <dt><b>ka_probes</b>
1580 <dd>if ka_time was nonzero, after the timeout expires how many
1581 times to try to get a response from the peer before giving up
1582 and killing the connection
1583 <dt><b>ka_interval</b>
1584 <dd>if ka_time was nonzero, how long to wait before each ka_probes
1586 <dt><b>provided_client_ssl_ctx</b>
1587 <dd>If non-null, swap out libwebsockets ssl
1588 implementation for the one provided by provided_ssl_ctx.
1589 Libwebsockets no longer is responsible for freeing the context
1590 if this option is selected.
1591 <dt><b>provided_client_ssl_ctx</b>
1592 <dd>If non-null, swap out libwebsockets ssl
1593 implementation for the one provided by provided_ssl_ctx.
1594 Libwebsockets no longer is responsible for freeing the context
1595 if this option is selected.
1596 <dt><b>max_http_header_data</b>
1597 <dd>The max amount of header payload that can be handled
1598 in an http request (unrecognized header payload is dropped)
1599 <dt><b>max_http_header_pool</b>
1600 <dd>The max number of connections with http headers that
1601 can be processed simultaneously (the corresponding memory is
1602 allocated for the lifetime of the context). If the pool is
1603 busy new incoming connections must wait for accept until one
1605 <dt><b>count_threads</b>
1606 <dd>how many contexts to create in an array, 0 = 1
1607 <dt><b>fd_limit_per_thread</b>
1608 <dd>nonzero means restrict each service thread to this
1609 many fds, 0 means the default which is divide the process fd
1610 limit by the number of threads.
1611 <dt><b>timeout_secs</b>
1612 <dd>various processes involving network roundtrips in the
1613 library are protected from hanging forever by timeouts. If
1614 nonzero, this member lets you set the timeout used in seconds.
1615 Otherwise a default timeout is used.
1618 <h2>struct lws_client_connect_info - parameters to connect with when using lws_client_connect_via_info()</h2>
1619 <b>struct lws_client_connect_info</b> {<br>
1620 <i>struct lws_context *</i> <b>context</b>;<br>
1621 <i>const char *</i> <b>address</b>;<br>
1622 <i>int</i> <b>port</b>;<br>
1623 <i>int</i> <b>ssl_connection</b>;<br>
1624 <i>const char *</i> <b>path</b>;<br>
1625 <i>const char *</i> <b>host</b>;<br>
1626 <i>const char *</i> <b>origin</b>;<br>
1627 <i>const char *</i> <b>protocol</b>;<br>
1628 <i>int</i> <b>ietf_version_or_minus_one</b>;<br>
1629 <i>void *</i> <b>userdata</b>;<br>
1630 <i>const struct lws_extension *</i> <b>client_exts</b>;<br>
1635 <dd>lws context to create connection in
1637 <dd>remote address to connect to
1639 <dd>remote port to connect to
1640 <dt><b>ssl_connection</b>
1645 <dd>content of host header
1647 <dd>content of origin header
1649 <dd>list of ws protocols
1650 <dt><b>ietf_version_or_minus_one</b>
1651 <dd>currently leave at 0 or -1
1653 <dd>if non-NULL, use this as wsi user_data instead of malloc it
1654 <dt><b>client_exts</b>
1655 <dd>array of extensions that may be used on connection
1658 <h2>lws_close_reason - Set reason and aux data to send with Close packet If you are going to return nonzero from the callback requesting the connection to close, you can optionally call this to set the reason the peer will be told if possible.</h2>
1659 <i>LWS_EXTERN void</i>
1660 <b>lws_close_reason</b>
1661 (<i>struct lws *</i> <b>wsi</b>,
1662 <i>enum lws_close_status</i> <b>status</b>,
1663 <i>unsigned char *</i> <b>buf</b>,
1664 <i>size_t</i> <b>len</b>)
1668 <dd>The websocket connection to set the close reason on
1670 <dd>A valid close status from websocket standard
1672 <dd>NULL or buffer containing up to 124 bytes of auxiliary data
1674 <dd>Length of data in <tt><b>buf</b></tt> to send
1677 <h2>lws_snprintf - </h2>
1678 <i>LWS_EXTERN int</i>
1680 (<i>char *</i> <b>str</b>,
1681 <i>size_t</i> <b>size</b>,
1682 <i>const char *</i> <b>format</b>,
1687 <dd>variable arguments
1689 <h3>Description</h3>
1692 \param str: destination buffer
1693 \param size: bytes left in destination buffer
1694 \param format: format string
1695 \param ...: args for format
1697 This lets you correctly truncate buffers by concatenating lengths, if you
1698 reach the limit the reported length doesn't exceed the limit.
projects / platform / upstream / libwebsockets.git / blob