1 <h2>lws_write - Apply protocol then write data to client</h2>
4 (<i>struct lws *</i> <b>wsi</b>,
5 <i>unsigned char *</i> <b>buf</b>,
6 <i>size_t</i> <b>len</b>,
7 <i>enum lws_write_protocol</i> <b>wp</b>)
11 <dd>Websocket instance (available from user callback)
13 <dd>The data to send. For data being sent on a websocket
14 connection (ie, not default http), this buffer MUST have
15 LWS_PRE bytes valid BEFORE the pointer.
16 This is so the protocol header data can be added in-situ.
18 <dd>Count of the data bytes in the payload starting from buf
22 This function provides the way to issue data back to the client
23 for both http and websocket protocols.
25 In the case of sending using websocket protocol, be sure to allocate
26 valid storage before and after buf as explained above. This scheme
27 allows maximum efficiency of sending data and protocol in a single
28 packet while not burdening the user code with any protocol knowledge.
30 Return may be -1 for a fatal error needing connection close, or a
31 positive number reflecting the amount of bytes actually sent. This
32 can be less than the requested number of bytes due to OS memory
33 pressure at any given time.
36 <h2>lws_http_transaction_completed - wait for new http transaction or close</h2>
38 <b>lws_http_transaction_completed</b>
39 (<i>struct lws *</i> <b>wsi</b>)
43 <dd>websocket connection
47 Returns 1 if the HTTP connection must close now
48 Returns 0 and resets connection to wait for new HTTP header /
49 transaction if possible
52 <h2>lws_serve_http_file - Send a file back to the client using http</h2>
54 <b>lws_serve_http_file</b>
55 (<i>struct lws *</i> <b>wsi</b>,
56 <i>const char *</i> <b>file</b>,
57 <i>const char *</i> <b>content_type</b>,
58 <i>const char *</i> <b>other_headers</b>,
59 <i>int</i> <b>other_headers_len</b>)
63 <dd>Websocket instance (available from user callback)
65 <dd>The file to issue over http
66 <dt><b>content_type</b>
67 <dd>The http content type, eg, text/html
68 <dt><b>other_headers</b>
69 <dd>NULL or pointer to header string
70 <dt><b>other_headers_len</b>
71 <dd>length of the other headers if non-NULL
75 This function is intended to be called from the callback in response
76 to http requests from the client. It allows the callback to issue
77 local files down the http link in a single step.
79 Returning <0 indicates error and the wsi should be closed. Returning
80 >0 indicates the file was completely sent and
81 <b>lws_http_transaction_completed</b> called on the wsi (and close if != 0)
82 ==0 indicates the file transfer is started and needs more service later,
83 the wsi should be left alone.
86 <h2>lws_return_http_status - Return simple http status</h2>
88 <b>lws_return_http_status</b>
89 (<i>struct lws *</i> <b>wsi</b>,
90 <i>unsigned int</i> <b>code</b>,
91 <i>const char *</i> <b>html_body</b>)
95 <dd>Websocket instance (available from user callback)
97 <dd>Status index, eg, 404
99 <dd>User-readable HTML description < 1KB, or NULL
103 Helper to report HTTP errors back to the client cleanly and
107 <h2>lws_client_connect_info - Connect to another websocket server</h2>
109 <b>lws_client_connect_info</b>
110 (<i>struct lws_client_connect_info *</i> <b>i</b>)
116 This function creates a connection to a remote server
119 <h2>lws_client_connect_extended - Connect to another websocket server DEPRECAATED use lws_client_connect_info</h2>
121 <b>lws_client_connect_extended</b>
122 (<i>struct lws_context *</i> <b>context</b>,
123 <i>const char *</i> <b>address</b>,
124 <i>int</i> <b>port</b>,
125 <i>int</i> <b>ssl_connection</b>,
126 <i>const char *</i> <b>path</b>,
127 <i>const char *</i> <b>host</b>,
128 <i>const char *</i> <b>origin</b>,
129 <i>const char *</i> <b>protocol</b>,
130 <i>int</i> <b>ietf_version_or_minus_one</b>,
131 <i>void *</i> <b>userdata</b>)
135 <dd>Websocket context
137 <dd>Remote server address, eg, "myserver.com"
139 <dd>Port to connect to on the remote server, eg, 80
140 <dt><b>ssl_connection</b>
141 <dd>0 = ws://, 1 = wss:// encrypted, 2 = wss:// allow self
144 <dd>Websocket path on server
146 <dd>Hostname on server
148 <dd>Socket origin name
150 <dd>Comma-separated list of protocols being asked for from
151 the server, or just one. The server will pick the one it
153 <dt><b>ietf_version_or_minus_one</b>
154 <dd>-1 to ask to connect using the default, latest
155 protocol supported, or the specific protocol ordinal
157 <dd>Pre-allocated user data
161 This function creates a connection to a remote server
164 <h2>lws_service_fd - Service polled socket with something waiting</h2>
166 <b>lws_service_fd</b>
167 (<i>struct lws_context *</i> <b>context</b>,
168 <i>struct lws_pollfd *</i> <b>pollfd</b>)
172 <dd>Websocket context
174 <dd>The pollfd entry describing the socket fd and which events
179 This function takes a pollfd that has POLLIN or POLLOUT activity and
180 services it according to the state of the associated
183 The one call deals with all "service" that might happen on a socket
184 including listen accepts, http files as well as websocket protocol.
186 If a pollfd says it has something, you can just pass it to
187 <b>lws_service_fd</b> whether it is a socket handled by lws or not.
188 If it sees it is a lws socket, the traffic will be handled and
189 pollfd->revents will be zeroed now.
191 If the socket is foreign to lws, it leaves revents alone. So you can
192 see if you should service yourself by checking the pollfd revents
193 after letting lws try to service it.
196 <h2>lws_service - Service any pending websocket activity</h2>
199 (<i>struct lws_context *</i> <b>context</b>,
200 <i>int</i> <b>timeout_ms</b>)
204 <dd>Websocket context
205 <dt><b>timeout_ms</b>
206 <dd>Timeout for poll; 0 means return immediately if nothing needed
207 service otherwise block and service immediately, returning
208 after the timeout if nothing needed service.
212 This function deals with any pending websocket traffic, for three
213 kinds of event. It handles these events on both server and client
214 types of connection the same.
216 1) Accept new connections to our context's server
218 2) Call the receive callback for incoming frame data received by
219 server or client connections.
221 You need to call this service function periodically to all the above
222 functions to happen; if your application is single-threaded you can
223 just call it in your main event loop.
225 Alternatively you can fork a new process that asynchronously handles
226 calling this service in a loop. In that case you are happy if this
227 call blocks your thread until it needs to take care of something and
228 would call it with a large nonzero timeout. Your loop then takes no
229 CPU while there is nothing happening.
231 If you are calling it in a single-threaded app, you don't want it to
232 wait around blocking other things in your loop from happening, so you
233 would call it with a timeout_ms of 0, so it returns immediately if
234 nothing is pending, or as soon as it services whatever was pending.
237 <h2>lws_hdr_fragment_length - </h2>
239 <b>lws_hdr_fragment_length</b>
240 (<i>struct lws *</i> <b>wsi</b>,
241 <i>enum lws_token_indexes</i> <b>h</b>,
242 <i>int</i> <b>frag_idx</b>)
246 <dd>websocket connection
248 <dd>which header index we are interested in
250 <dd>which fragment of <tt><b>h</b></tt> we want to get the length of
254 The returned length does not include the space for a
258 <h2>lws_hdr_total_length - </h2>
260 <b>lws_hdr_total_length</b>
261 (<i>struct lws *</i> <b>wsi</b>,
262 <i>enum lws_token_indexes</i> <b>h</b>)
266 <dd>websocket connection
268 <dd>which header index we are interested in
272 The returned length does not include the space for a
276 <h2>lws_hdr_copy_fragment - </h2>
278 <b>lws_hdr_copy_fragment</b>
279 (<i>struct lws *</i> <b>wsi</b>,
280 <i>char *</i> <b>dst</b>,
281 <i>int</i> <b>len</b>,
282 <i>enum lws_token_indexes</i> <b>h</b>,
283 <i>int</i> <b>frag_idx</b>)
287 <dd>websocket connection
289 <dd>destination buffer
291 <dd>length of destination buffer
293 <dd>which header index we are interested in
297 The buffer length <tt><b>len</b></tt> must include space for an additional
298 terminating '\0', or it will fail returning -1.
299 If the requested fragment index is not present, it fails
303 <h2>lws_hdr_copy - </h2>
306 (<i>struct lws *</i> <b>wsi</b>,
307 <i>char *</i> <b>dst</b>,
308 <i>int</i> <b>len</b>,
309 <i>enum lws_token_indexes</i> <b>h</b>)
313 <dd>websocket connection
315 <dd>destination buffer
317 <dd>length of destination buffer
319 <dd>which header index we are interested in
323 The buffer length <tt><b>len</b></tt> must include space for an additional
324 terminating '\0', or it will fail returning -1.
327 <h2>lws_frame_is_binary - </h2>
329 <b>lws_frame_is_binary</b>
330 (<i>struct lws *</i> <b>wsi</b>)
334 <dd>the connection we are inquiring about
338 This is intended to be called from the LWS_CALLBACK_RECEIVE callback if
339 it's interested to see if the frame it's dealing with was sent in binary
343 <h2>lws_remaining_packet_payload - Bytes to come before "overall" rx packet is complete</h2>
345 <b>lws_remaining_packet_payload</b>
346 (<i>struct lws *</i> <b>wsi</b>)
350 <dd>Websocket instance (available from user callback)
354 This function is intended to be called from the callback if the
355 user code is interested in "complete packets" from the client.
356 libwebsockets just passes through payload as it comes and issues a buffer
357 additionally when it hits a built-in limit. The LWS_CALLBACK_RECEIVE
358 callback handler can use this API to find out if the buffer it has just
359 been given is the last piece of a "complete packet" from the client --
360 when that is the case <b>lws_remaining_packet_payload</b> will return
363 Many protocols won't care becuse their packets are always small.
366 <h2>lws_get_peer_addresses - Get client address information</h2>
368 <b>lws_get_peer_addresses</b>
369 (<i>struct lws *</i> <b>wsi</b>,
370 <i>lws_sockfd_type</i> <b>fd</b>,
371 <i>char *</i> <b>name</b>,
372 <i>int</i> <b>name_len</b>,
373 <i>char *</i> <b>rip</b>,
374 <i>int</i> <b>rip_len</b>)
378 <dd>Local struct lws associated with
380 <dd>Connection socket descriptor
382 <dd>Buffer to take client address name
384 <dd>Length of client address name buffer
386 <dd>Buffer to take client address IP dotted quad
388 <dd>Length of client address IP buffer
392 This function fills in <tt><b>name</b></tt> and <tt><b>rip</b></tt> with the name and IP of
393 the client connected with socket descriptor <tt><b>fd</b></tt>. Names may be
394 truncated if there is not enough room. If either cannot be
395 determined, they will be returned as valid zero-length strings.
398 <h2>lws_context_user - get the user data associated with the context</h2>
399 <i>LWS_EXTERN void *</i>
400 <b>lws_context_user</b>
401 (<i>struct lws_context *</i> <b>context</b>)
405 <dd>Websocket context
409 This returns the optional user allocation that can be attached to
410 the context the sockets live in at context_create time. It's a way
411 to let all sockets serviced in the same context share data without
412 using globals statics in the user code.
415 <h2>lws_callback_all_protocol - Callback all connections using the given protocol with the given reason</h2>
417 <b>lws_callback_all_protocol</b>
418 (<i>struct lws_context *</i> <b>context</b>,
419 <i>const struct lws_protocols *</i> <b>protocol</b>,
420 <i>int</i> <b>reason</b>)
424 <dd>Protocol whose connections will get callbacks
426 <dd>Callback reason index
429 <h2>lws_set_timeout - marks the wsi as subject to a timeout</h2>
431 <b>lws_set_timeout</b>
432 (<i>struct lws *</i> <b>wsi</b>,
433 <i>enum pending_timeout</i> <b>reason</b>,
434 <i>int</i> <b>secs</b>)
438 <dd>Websocket connection instance
447 You will not need this unless you are doing something special
450 <h2>lws_get_socket_fd - returns the socket file descriptor</h2>
452 <b>lws_get_socket_fd</b>
453 (<i>struct lws *</i> <b>wsi</b>)
457 <dd>Websocket connection instance
462 You will not need this unless you are doing something special
465 <h2>lws_rx_flow_control - Enable and disable socket servicing for received packets.</h2>
467 <b>lws_rx_flow_control</b>
468 (<i>struct lws *</i> <b>wsi</b>,
469 <i>int</i> <b>enable</b>)
473 <dd>Websocket connection instance to get callback for
475 <dd>0 = disable read servicing for this connection, 1 = enable
480 If the output side of a server process becomes choked, this allows flow
481 control for the input side.
484 <h2>lws_rx_flow_allow_all_protocol - Allow all connections with this protocol to receive</h2>
486 <b>lws_rx_flow_allow_all_protocol</b>
487 (<i>const struct lws_context *</i> <b>context</b>,
488 <i>const struct lws_protocols *</i> <b>protocol</b>)
492 <dd>all connections using this protocol will be allowed to receive
497 When the user server code realizes it can accept more input, it can
498 call this to have the RX flow restriction removed from all connections using
502 <h2>lws_canonical_hostname - returns this host's hostname</h2>
504 <b>lws_canonical_hostname</b>
505 (<i>struct lws_context *</i> <b>context</b>)
509 <dd>Websocket context
514 This is typically used by client code to fill in the host parameter
515 when making a client connection. You can only call it after the context
519 <h2>lws_set_proxy - Setups proxy to lws_context.</h2>
522 (<i>struct lws_context *</i> <b>context</b>,
523 <i>const char *</i> <b>proxy</b>)
527 <dd>pointer to struct lws_context you want set proxy to
529 <dd>pointer to c string containing proxy in format address:port
533 Returns 0 if proxy string was parsed and proxy was setup.
534 Returns -1 if <tt><b>proxy</b></tt> is NULL or has incorrect format.
536 This is only required if your OS does not provide the http_proxy
537 environment variable (eg, OSX)
539 IMPORTANT! You should call this function right after creation of the
540 lws_context and before call to connect. If you call this
541 function after connect behavior is undefined.
542 This function will override proxy settings made on lws_context
543 creation with <b>genenv</b> call.
546 <h2>lws_get_protocol - Returns a protocol pointer from a websocket connection.</h2>
547 <i>const struct lws_protocols *</i>
548 <b>lws_get_protocol</b>
549 (<i>struct lws *</i> <b>wsi</b>)
553 <dd>pointer to struct websocket you want to know the protocol of
558 Some apis can act on all live connections of a given protocol,
559 this is how you can get a pointer to the active protocol if needed.
562 <h2>lws_set_log_level - Set the logging bitfield</h2>
564 <b>lws_set_log_level</b>
565 (<i>int</i> <b>level</b>,
566 <i>void (*</i><b>func</b>) <i>(int level, const char *line)</i>)
570 <dd>OR together the LLL_ debug contexts you want output from
574 log level defaults to "err", "warn" and "notice" contexts enabled and
578 <h2>lws_is_ssl - Find out if connection is using SSL</h2>
581 (<i>struct lws *</i> <b>wsi</b>)
585 <dd>websocket connection to check
589 Returns 0 if the connection is not using SSL, 1 if using SSL and
590 using verified cert, and 2 if using SSL but the cert was not
591 checked (appears for client wsi told to skip check on connection)
594 <h2>lws_partial_buffered - find out if lws buffered the last write</h2>
596 <b>lws_partial_buffered</b>
597 (<i>struct lws *</i> <b>wsi</b>)
601 <dd>websocket connection to check
605 Returns 1 if you cannot use lws_write because the last
606 write on this connection is still buffered, and can't be cleared without
607 returning to the service loop and waiting for the connection to be
610 If you will try to do >1 lws_write call inside a single
611 WRITEABLE callback, you must check this after every write and bail if
612 set, ask for a new writeable callback and continue writing from there.
614 This is never set at the start of a writeable callback, but any write
618 <h2>lws_get_library_version - </h2>
620 <b>lws_get_library_version</b>
621 (<i></i> <b>void</b>)
630 returns a const char * to a string like "1.1 178d78c"
631 representing the library version followed by the git head hash it
635 <h2>lws_create_context - Create the websocket handler</h2>
636 <i>struct lws_context *</i>
637 <b>lws_create_context</b>
638 (<i>struct lws_context_creation_info *</i> <b>info</b>)
642 <dd>pointer to struct with parameters
646 This function creates the listening socket (if serving) and takes care
647 of all initialization in one step.
649 After initialization, it returns a struct lws_context * that
650 represents this server. After calling, user code needs to take care
651 of calling <b>lws_service</b> with the context pointer to get the
652 server's sockets serviced. This must be done in the same process
653 context as the initialization call.
655 The protocol callback functions are called for a handful of events
656 including http requests coming in, websocket connections becoming
657 established, and data arriving; it's also called periodically to allow
660 HTTP requests are sent always to the FIRST protocol in <tt><b>protocol</b></tt>, since
661 at that time websocket protocol has not been negotiated. Other
662 protocols after the first one never see any HTTP callack activity.
664 The server created is a simple http server by default; part of the
665 websocket standard is upgrading this http connection to a websocket one.
667 This allows the same server to provide files like scripts and favicon /
668 images or whatever over http and dynamic data over websockets all in
669 one place; they're all handled in the user callback.
672 <h2>lws_context_destroy - Destroy the websocket context</h2>
674 <b>lws_context_destroy</b>
675 (<i>struct lws_context *</i> <b>context</b>)
679 <dd>Websocket context
683 This function closes any active connections and then frees the
684 context. After calling this, any further use of the context is
688 <h2>lws_callback_on_writable - Request a callback when this socket becomes able to be written to without blocking</h2>
690 <b>lws_callback_on_writable</b>
691 (<i>struct lws *</i> <b>wsi</b>)
695 <dd>Websocket connection instance to get callback for
698 <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>
700 <b>lws_callback_on_writable_all_protocol</b>
701 (<i>const struct lws_context *</i> <b>context</b>,
702 <i>const struct lws_protocols *</i> <b>protocol</b>)
708 <dd>Protocol whose connections will get callbacks
711 <h2>lws_cancel_service - Cancel servicing of pending websocket activity</h2>
713 <b>lws_cancel_service</b>
714 (<i>struct lws_context *</i> <b>context</b>)
718 <dd>Websocket context
722 This function let a call to <b>lws_service</b> waiting for a timeout
726 <h2>lws_cancel_service - Cancel servicing of pending websocket activity</h2>
728 <b>lws_cancel_service</b>
729 (<i>struct lws_context *</i> <b>context</b>)
733 <dd>Websocket context
737 This function let a call to <b>lws_service</b> waiting for a timeout
741 <h2>lws_cancel_service - Cancel servicing of pending websocket activity</h2>
743 <b>lws_cancel_service</b>
744 (<i>struct lws_context *</i> <b>context</b>)
748 <dd>Websocket context
752 This function let a call to <b>lws_service</b> waiting for a timeout
755 There is no <b>poll</b> in MBED3, he will fire callbacks when he feels like
759 <h2>struct lws_plat_file_ops - Platform-specific file operations</h2>
760 <b>struct lws_plat_file_ops</b> {<br>
761 <i>lws_filefd_type (*</i><b>open</b>) <i>(struct lws *wsi, const char *filename,unsigned long *filelen, int flags)</i>;<br>
762 <i>int (*</i><b>close</b>) <i>(struct lws *wsi, lws_filefd_type fd)</i>;<br>
763 <i>unsigned long (*</i><b>seek_cur</b>) <i>(struct lws *wsi, lws_filefd_type fd,long offset_from_cur_pos)</i>;<br>
764 <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>
765 <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>
770 <dd>Open file (always binary access if plat supports it)
771 filelen is filled on exit to be the length of the file
772 flags should be set to O_RDONLY or O_RDWR
776 <dd>Seek from current position
778 <dd>Read fron file *amount is set on exit to amount read
780 <dd>Write to file *amount is set on exit as amount written
785 These provide platform-agnostic ways to deal with filesystem access in the
786 library and in the user code.
789 <h2>lws_callback_function - User server actions</h2>
791 <b>lws_callback_function</b>
792 (<i>struct lws *</i> <b>wsi</b>,
793 <i>enum lws_callback_reasons</i> <b>reason</b>,
794 <i>void *</i> <b>user</b>,
795 <i>void *</i> <b>in</b>,
796 <i>size_t</i> <b>len</b>)
800 <dd>Opaque websocket instance pointer
802 <dd>The reason for the call
804 <dd>Pointer to per-session user data allocated by library
806 <dd>Pointer used for some callback reasons
808 <dd>Length set for some callback reasons
812 This callback is the way the user controls what is served. All the
813 protocol detail is hidden and handled by the library.
815 For each connection / session there is user data allocated that is
816 pointed to by "user". You set the size of this user data area when
817 the library is initialized with lws_create_server.
819 You get an opportunity to initialize user data when called back with
820 LWS_CALLBACK_ESTABLISHED reason.
822 <h3>LWS_CALLBACK_ESTABLISHED</h3>
824 after the server completes a handshake with
825 an incoming client. If you built the library
826 with ssl support, <tt><b>in</b></tt> is a pointer to the
827 ssl struct associated with the connection or
830 <h3>LWS_CALLBACK_CLIENT_CONNECTION_ERROR</h3>
832 the request client connection has
833 been unable to complete a handshake with the remote server. If
834 in is non-NULL, you can find an error string of length len where
837 <h3>LWS_CALLBACK_CLIENT_FILTER_PRE_ESTABLISH</h3>
839 this is the last chance for the
840 client user code to examine the http headers
841 and decide to reject the connection. If the
842 content in the headers is interesting to the
843 client (url, etc) it needs to copy it out at
844 this point since it will be destroyed before
845 the CLIENT_ESTABLISHED call
847 <h3>LWS_CALLBACK_CLIENT_ESTABLISHED</h3>
849 after your client connection completed
850 a handshake with the remote server
852 <h3>LWS_CALLBACK_CLOSED</h3>
854 when the websocket session ends
856 <h3>LWS_CALLBACK_CLOSED_HTTP</h3>
858 when a HTTP (non-websocket) session ends
860 <h3>LWS_CALLBACK_RECEIVE</h3>
862 data has appeared for this server endpoint from a
863 remote client, it can be found at *in and is
866 <h3>LWS_CALLBACK_CLIENT_RECEIVE_PONG</h3>
868 if you elected to see PONG packets,
869 they appear with this callback reason. PONG
870 packets only exist in 04+ protocol
872 <h3>LWS_CALLBACK_CLIENT_RECEIVE</h3>
874 data has appeared from the server for the
875 client connection, it can be found at *in and
878 <h3>LWS_CALLBACK_HTTP</h3>
880 an http request has come from a client that is not
881 asking to upgrade the connection to a websocket
882 one. This is a chance to serve http content,
883 for example, to send a script to the client
884 which will then open the websockets connection.
885 <tt><b>in</b></tt> points to the URI path requested and
886 <b>lws_serve_http_file</b> makes it very
887 simple to send back a file to the client.
888 Normally after sending the file you are done
889 with the http connection, since the rest of the
890 activity will come by websockets from the script
891 that was delivered by http, so you will want to
892 return 1; to close and free up the connection.
893 That's important because it uses a slot in the
894 total number of client connections allowed set
897 <h3>LWS_CALLBACK_HTTP_BODY</h3>
899 the next <tt><b>len</b></tt> bytes data from the http
900 request body HTTP connection is now available in <tt><b>in</b></tt>.
902 <h3>LWS_CALLBACK_HTTP_BODY_COMPLETION</h3>
904 the expected amount of http request
905 body has been delivered
907 <h3>LWS_CALLBACK_HTTP_WRITEABLE</h3>
909 you can write more down the http protocol
912 <h3>LWS_CALLBACK_HTTP_FILE_COMPLETION</h3>
914 a file requested to be send down
915 http link has completed.
917 <h3>LWS_CALLBACK_SERVER_WRITEABLE</h3>
920 <b>lws_callback_on_writable</b> on a connection, you will
921 get one of these callbacks coming when the connection socket
922 is able to accept another write packet without blocking.
923 If it already was able to take another packet without blocking,
924 you'll get this callback at the next call to the service loop
925 function. Notice that CLIENTs get LWS_CALLBACK_CLIENT_WRITEABLE
926 and servers get LWS_CALLBACK_SERVER_WRITEABLE.
928 <h3>LWS_CALLBACK_FILTER_NETWORK_CONNECTION</h3>
930 called when a client connects to
931 the server at network level; the connection is accepted but then
932 passed to this callback to decide whether to hang up immediately
933 or not, based on the client IP. <tt><b>in</b></tt> contains the connection
934 socket's descriptor. Since the client connection information is
935 not available yet, <tt><b>wsi</b></tt> still pointing to the main server socket.
936 Return non-zero to terminate the connection before sending or
937 receiving anything. Because this happens immediately after the
938 network connection from the client, there's no websocket protocol
939 selected yet so this callback is issued only to protocol 0.
941 <h3>LWS_CALLBACK_SERVER_NEW_CLIENT_INSTANTIATED</h3>
943 A new client just had
944 been connected, accepted, and instantiated into the pool. This
945 callback allows setting any relevant property to it. Because this
946 happens immediately after the instantiation of a new client,
947 there's no websocket protocol selected yet so this callback is
948 issued only to protocol 0. Only <tt><b>wsi</b></tt> is defined, pointing to the
949 new client, and the return value is ignored.
951 <h3>LWS_CALLBACK_FILTER_HTTP_CONNECTION</h3>
953 called when the request has
954 been received and parsed from the client, but the response is
955 not sent yet. Return non-zero to disallow the connection.
956 <tt><b>user</b></tt> is a pointer to the connection user space allocation,
957 <tt><b>in</b></tt> is the URI, eg, "/"
958 In your handler you can use the public APIs
959 <b>lws_hdr_total_length</b> / <b>lws_hdr_copy</b> to access all of the
960 headers using the header enums lws_token_indexes from
961 libwebsockets.h to check for and read the supported header
962 presence and content before deciding to allow the http
963 connection to proceed or to kill the connection.
965 <h3>LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION</h3>
967 called when the handshake has
968 been received and parsed from the client, but the response is
969 not sent yet. Return non-zero to disallow the connection.
970 <tt><b>user</b></tt> is a pointer to the connection user space allocation,
971 <tt><b>in</b></tt> is the requested protocol name
972 In your handler you can use the public APIs
973 <b>lws_hdr_total_length</b> / <b>lws_hdr_copy</b> to access all of the
974 headers using the header enums lws_token_indexes from
975 libwebsockets.h to check for and read the supported header
976 presence and content before deciding to allow the handshake
977 to proceed or to kill the connection.
979 <h3>LWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS</h3>
982 including OpenSSL support, this callback allows your user code
983 to perform extra <b>SSL_CTX_load_verify_locations</b> or similar
984 calls to direct OpenSSL where to find certificates the client
985 can use to confirm the remote server identity. <tt><b>user</b></tt> is the
988 <h3>LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS</h3>
991 including OpenSSL support, this callback allows your user code
992 to load extra certifcates into the server which allow it to
993 verify the validity of certificates returned by clients. <tt><b>user</b></tt>
994 is the server's OpenSSL SSL_CTX*
996 <h3>LWS_CALLBACK_OPENSSL_CONTEXT_REQUIRES_PRIVATE_KEY</h3>
999 including OpenSSL support but no private key file has been
1000 specified (ssl_private_key_filepath is NULL), this is called to
1001 allow the user to set the private key directly via libopenssl
1002 and perform further operations if required; this might be useful
1003 in situations where the private key is not directly accessible
1004 by the OS, for example if it is stored on a smartcard
1005 <tt><b>user</b></tt> is the server's OpenSSL SSL_CTX*
1007 <h3>LWS_CALLBACK_OPENSSL_PERFORM_CLIENT_CERT_VERIFICATION</h3>
1010 libwebsockets context was created with the option
1011 LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT, then this
1012 callback is generated during OpenSSL verification of the cert
1013 sent from the client. It is sent to protocol[0] callback as
1014 no protocol has been negotiated on the connection yet.
1015 Notice that the libwebsockets context and wsi are both NULL
1016 during this callback. See
1020 //www.openssl.org/docs/ssl/SSL_CTX_set_verify.html
1021 to understand more detail about the OpenSSL callback that
1022 generates this libwebsockets callback and the meanings of the
1023 arguments passed. In this callback, <tt><b>user</b></tt> is the x509_ctx,
1024 <tt><b>in</b></tt> is the ssl pointer and <tt><b>len</b></tt> is preverify_ok
1025 Notice that this callback maintains libwebsocket return
1026 conventions, return 0 to mean the cert is OK or 1 to fail it.
1027 This also means that if you don't handle this callback then
1028 the default callback action of returning 0 allows the client
1031 <h3>LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER</h3>
1033 this callback happens
1034 when a client handshake is being compiled. <tt><b>user</b></tt> is NULL,
1035 <tt><b>in</b></tt> is a char **, it's pointing to a char * which holds the
1036 next location in the header buffer where you can add
1037 headers, and <tt><b>len</b></tt> is the remaining space in the header buffer,
1038 which is typically some hundreds of bytes. So, to add a canned
1039 cookie, your handler code might look similar to:
1041 char **p = (char **)in;
1046 *p += sprintf(*p, "Cookie: a=b\x0d\x0a");
1050 Notice if you add anything, you just have to take care about
1051 the CRLF on the line you added. Obviously this callback is
1052 optional, if you don't handle it everything is fine.
1054 Notice the callback is coming to protocols[0] all the time,
1055 because there is no specific protocol handshook yet.
1057 <h3>LWS_CALLBACK_CONFIRM_EXTENSION_OKAY</h3>
1059 When the server handshake code
1060 sees that it does support a requested extension, before
1061 accepting the extension by additing to the list sent back to
1062 the client it gives this callback just to check that it's okay
1063 to use that extension. It calls back to the requested protocol
1064 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
1065 valid. Note though at this time the ESTABLISHED callback hasn't
1066 happened yet so if you initialize <tt><b>user</b></tt> content there, <tt><b>user</b></tt>
1067 content during this callback might not be useful for anything.
1068 Notice this callback comes to protocols[0].
1070 <h3>LWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED</h3>
1073 connection is being prepared to start a handshake to a server,
1074 each supported extension is checked with protocols[0] callback
1075 with this reason, giving the user code a chance to suppress the
1076 claim to support that extension by returning non-zero. If
1077 unhandled, by default 0 will be returned and the extension
1078 support included in the header to the server. Notice this
1079 callback comes to protocols[0].
1081 <h3>LWS_CALLBACK_PROTOCOL_INIT</h3>
1083 One-time call per protocol so it can
1084 do initial setup / allocations etc
1086 <h3>LWS_CALLBACK_PROTOCOL_DESTROY</h3>
1088 One-time call per protocol indicating
1089 this protocol won't get used at all after this callback, the
1090 context is getting destroyed. Take the opportunity to
1091 deallocate everything that was allocated by the protocol.
1093 <h3>LWS_CALLBACK_WSI_CREATE</h3>
1095 outermost (earliest) wsi create notification
1097 <h3>LWS_CALLBACK_WSI_DESTROY</h3>
1099 outermost (latest) wsi destroy notification
1101 The next five reasons are optional and only need taking care of if you
1102 will be integrating libwebsockets sockets into an external polling
1105 For these calls, <tt><b>in</b></tt> points to a struct lws_pollargs that
1106 contains <tt><b>fd</b></tt>, <tt><b>events</b></tt> and <tt><b>prev_events</b></tt> members
1108 <h3>LWS_CALLBACK_ADD_POLL_FD</h3>
1110 libwebsocket deals with its <b>poll</b> loop
1111 internally, but in the case you are integrating with another
1112 server you will need to have libwebsocket sockets share a
1113 polling array with the other server. This and the other
1114 POLL_FD related callbacks let you put your specialized
1115 poll array interface code in the callback for protocol 0, the
1116 first protocol you support, usually the HTTP protocol in the
1118 This callback happens when a socket needs to be
1120 <h3>added to the polling loop</h3>
1122 <tt><b>in</b></tt> points to a struct
1123 lws_pollargs; the <tt><b>fd</b></tt> member of the struct is the file
1124 descriptor, and <tt><b>events</b></tt> contains the active events.
1126 If you are using the internal polling loop (the "service"
1127 callback), you can just ignore these callbacks.
1129 <h3>LWS_CALLBACK_DEL_POLL_FD</h3>
1131 This callback happens when a socket descriptor
1132 needs to be removed from an external polling array. <tt><b>in</b></tt> is
1133 again the struct lws_pollargs containing the <tt><b>fd</b></tt> member
1134 to be removed. If you are using the internal polling
1135 loop, you can just ignore it.
1137 <h3>LWS_CALLBACK_CHANGE_MODE_POLL_FD</h3>
1139 This callback happens when
1140 libwebsockets wants to modify the events for a connectiion.
1141 <tt><b>in</b></tt> is the struct lws_pollargs with the <tt><b>fd</b></tt> to change.
1142 The new event mask is in <tt><b>events</b></tt> member and the old mask is in
1143 the <tt><b>prev_events</b></tt> member.
1144 If you are using the internal polling loop, you can just ignore
1147 <h3>LWS_CALLBACK_UNLOCK_POLL</h3>
1149 These allow the external poll changes driven
1150 by libwebsockets to participate in an external thread locking
1151 scheme around the changes, so the whole thing is threadsafe.
1152 These are called around three activities in the library,
1153 - inserting a new wsi in the wsi / fd table (len=1)
1154 - deleting a wsi from the wsi / fd table (len=1)
1155 - changing a wsi's POLLIN/OUT state (len=0)
1156 Locking and unlocking external synchronization objects when
1157 len == 1 allows external threads to be synchronized against
1158 wsi lifecycle changes if it acquires the same lock for the
1159 duration of wsi dereference from the other thread context.
1161 <h3>LWS_CALLBACK_WS_PEER_INITIATED_CLOSE</h3>
1163 The peer has sent an unsolicited Close WS packet. <tt><b>in</b></tt> and
1164 <tt><b>len</b></tt> are the optional close code (first 2 bytes, network
1165 order) and the optional additional information which is not
1166 defined in the standard, and may be a string or non-human-
1168 If you return 0 lws will echo the close and then close the
1169 connection. If you return nonzero lws will just close the
1173 <h2>lws_extension_callback_function - Hooks to allow extensions to operate</h2>
1175 <b>lws_extension_callback_function</b>
1176 (<i>struct lws_context *</i> <b>context</b>,
1177 <i>const struct lws_extension *</i> <b>ext</b>,
1178 <i>struct lws *</i> <b>wsi</b>,
1179 <i>enum lws_extension_callback_reasons</i> <b>reason</b>,
1180 <i>void *</i> <b>user</b>,
1181 <i>void *</i> <b>in</b>,
1182 <i>size_t</i> <b>len</b>)
1186 <dd>Websockets context
1190 <dd>Opaque websocket instance pointer
1192 <dd>The reason for the call
1194 <dd>Pointer to ptr to per-session user data allocated by library
1196 <dd>Pointer used for some callback reasons
1198 <dd>Length set for some callback reasons
1200 <h3>Description</h3>
1202 Each extension that is active on a particular connection receives
1203 callbacks during the connection lifetime to allow the extension to
1204 operate on websocket data and manage itself.
1206 Libwebsockets takes care of allocating and freeing "user" memory for
1207 each active extension on each connection. That is what is pointed to
1208 by the <tt><b>user</b></tt> parameter.
1210 <h3>LWS_EXT_CB_CONSTRUCT</h3>
1212 called when the server has decided to
1213 select this extension from the list provided by the client,
1214 just before the server will send back the handshake accepting
1215 the connection with this extension active. This gives the
1216 extension a chance to initialize its connection context found
1217 in <tt><b>user</b></tt>.
1219 <h3>LWS_EXT_CB_CLIENT_CONSTRUCT</h3>
1221 same as LWS_EXT_CB_CONSTRUCT
1222 but called when client is instantiating this extension. Some
1223 extensions will work the same on client and server side and then
1224 you can just merge handlers for both CONSTRUCTS.
1226 <h3>LWS_EXT_CB_DESTROY</h3>
1228 called when the connection the extension was
1229 being used on is about to be closed and deallocated. It's the
1230 last chance for the extension to deallocate anything it has
1231 allocated in the user data (pointed to by <tt><b>user</b></tt>) before the
1232 user data is deleted. This same callback is used whether you
1233 are in client or server instantiation context.
1235 <h3>LWS_EXT_CB_PACKET_RX_PREPARSE</h3>
1237 when this extension was active on
1238 a connection, and a packet of data arrived at the connection,
1239 it is passed to this callback to give the extension a chance to
1240 change the data, eg, decompress it. <tt><b>user</b></tt> is pointing to the
1241 extension's private connection context data, <tt><b>in</b></tt> is pointing
1242 to an lws_tokens struct, it consists of a char * pointer called
1243 token, and an int called token_len. At entry, these are
1244 set to point to the received buffer and set to the content
1245 length. If the extension will grow the content, it should use
1246 a new buffer allocated in its private user context data and
1247 set the pointed-to lws_tokens members to point to its buffer.
1249 <h3>LWS_EXT_CB_PACKET_TX_PRESEND</h3>
1251 this works the same way as
1252 LWS_EXT_CB_PACKET_RX_PREPARSE above, except it gives the
1253 extension a chance to change websocket data just before it will
1254 be sent out. Using the same lws_token pointer scheme in <tt><b>in</b></tt>,
1255 the extension can change the buffer and the length to be
1256 transmitted how it likes. Again if it wants to grow the
1257 buffer safely, it should copy the data into its own buffer and
1258 set the lws_tokens token pointer to it.
1261 <h2>struct lws_protocols - List of protocols and handlers server supports.</h2>
1262 <b>struct lws_protocols</b> {<br>
1263 <i>const char *</i> <b>name</b>;<br>
1264 <i>lws_callback_function *</i> <b>callback</b>;<br>
1265 <i>size_t</i> <b>per_session_data_size</b>;<br>
1266 <i>size_t</i> <b>rx_buffer_size</b>;<br>
1267 <i>unsigned int</i> <b>id</b>;<br>
1268 <i>void *</i> <b>user</b>;<br>
1273 <dd>Protocol name that must match the one given in the client
1274 Javascript new WebSocket(url, 'protocol') name.
1276 <dd>The service callback used for this protocol. It allows the
1277 service action for an entire protocol to be encapsulated in
1278 the protocol-specific callback
1279 <dt><b>per_session_data_size</b>
1280 <dd>Each new connection using this protocol gets
1281 this much memory allocated on connection establishment and
1282 freed on connection takedown. A pointer to this per-connection
1283 allocation is passed into the callback in the 'user' parameter
1284 <dt><b>rx_buffer_size</b>
1285 <dd>if you want atomic frames delivered to the callback, you
1286 should set this to the size of the biggest legal frame that
1287 you support. If the frame size is exceeded, there is no
1288 error, but the buffer will spill to the user callback when
1289 full, which you can detect by using
1290 <b>lws_remaining_packet_payload</b>. Notice that you
1291 just talk about frame size here, the LWS_PRE
1292 and post-padding are automatically also allocated on top.
1294 <dd>ignored by lws, but useful to contain user information bound
1295 to the selected protocol. For example if this protocol was
1296 called "myprotocol-v2", you might set id to 2, and the user
1297 code that acts differently according to the version can do so by
1298 switch (wsi->protocol->id), user code might use some bits as
1299 capability flags based on selected protocol version, etc.
1301 <dd>User provided context data at the protocol level.
1302 Accessible via lws_get_protocol(wsi)->user
1303 This should not be confused with wsi->user, it is not the same.
1304 The library completely ignores any value in here.
1306 <h3>Description</h3>
1308 This structure represents one protocol supported by the server. An
1309 array of these structures is passed to <b>lws_create_server</b>
1310 allows as many protocols as you like to be handled by one server.
1312 The first protocol given has its callback used for user callbacks when
1313 there is no agreed protocol name, that's true during HTTP part of the
1315 <h3>connection and true if the client did not send a Protocol</h3>
1320 <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>
1321 <b>struct lws_ext_options</b> {<br>
1322 <i>const char *</i> <b>name</b>;<br>
1323 <i>enum lws_ext_options_types</i> <b>type</b>;<br>
1328 <dd>Option name, eg, "server_no_context_takeover"
1330 <dd>What kind of args the option can take
1333 <h2>struct lws_extension - An extension we know how to cope with</h2>
1334 <b>struct lws_extension</b> {<br>
1335 <i>const char *</i> <b>name</b>;<br>
1336 <i>lws_extension_callback_function *</i> <b>callback</b>;<br>
1337 <i>const char *</i> <b>client_offer</b>;<br>
1342 <dd>Formal extension name, eg, "permessage-deflate"
1344 <dd>Service callback
1345 <dt><b>client_offer</b>
1346 <dd>String containing exts and options client offers
1349 <h2>struct lws_context_creation_info - parameters to create context with</h2>
1350 <b>struct lws_context_creation_info</b> {<br>
1351 <i>int</i> <b>port</b>;<br>
1352 <i>const char *</i> <b>iface</b>;<br>
1353 <i>const struct lws_protocols *</i> <b>protocols</b>;<br>
1354 <i>const struct lws_extension *</i> <b>extensions</b>;<br>
1355 <i>const struct lws_token_limits *</i> <b>token_limits</b>;<br>
1356 <i>const char *</i> <b>ssl_cert_filepath</b>;<br>
1357 <i>const char *</i> <b>ssl_private_key_filepath</b>;<br>
1358 <i>const char *</i> <b>ssl_ca_filepath</b>;<br>
1359 <i>const char *</i> <b>ssl_cipher_list</b>;<br>
1360 <i>const char *</i> <b>http_proxy_address</b>;<br>
1361 <i>unsigned int</i> <b>http_proxy_port</b>;<br>
1362 <i>int</i> <b>gid</b>;<br>
1363 <i>int</i> <b>uid</b>;<br>
1364 <i>unsigned int</i> <b>options</b>;<br>
1365 <i>void *</i> <b>user</b>;<br>
1366 <i>int</i> <b>ka_time</b>;<br>
1367 <i>int</i> <b>ka_probes</b>;<br>
1368 <i>int</i> <b>ka_interval</b>;<br>
1369 #ifdef LWS_OPENSSL_SUPPORT<br>
1370 <i>void *</i> <b>provided_client_ssl_ctx</b>;<br>
1372 <i>void *</i> <b>provided_client_ssl_ctx</b>;<br>
1374 <i>short</i> <b>max_http_header_data</b>;<br>
1375 <i>short</i> <b>max_http_header_pool</b>;<br>
1380 <dd>Port to listen on... you can use CONTEXT_PORT_NO_LISTEN to
1381 suppress listening on any port, that's what you want if you are
1382 not running a websocket server at all but just using it as a
1385 <dd>NULL to bind the listen socket to all interfaces, or the
1386 interface name, eg, "eth2"
1387 <dt><b>protocols</b>
1388 <dd>Array of structures listing supported protocols and a protocol-
1389 specific callback for each one. The list is ended with an
1390 entry that has a NULL callback pointer.
1391 It's not const because we write the owning_server member
1392 <dt><b>extensions</b>
1393 <dd>NULL or array of lws_extension structs listing the
1394 extensions this context supports. If you configured with
1395 --without-extensions, you should give NULL here.
1396 <dt><b>token_limits</b>
1397 <dd>NULL or struct lws_token_limits pointer which is initialized
1398 with a token length limit for each possible WSI_TOKEN_***
1399 <dt><b>ssl_cert_filepath</b>
1400 <dd>If libwebsockets was compiled to use ssl, and you want
1401 to listen using SSL, set to the filepath to fetch the
1402 server cert from, otherwise NULL for unencrypted
1403 <dt><b>ssl_private_key_filepath</b>
1404 <dd>filepath to private key if wanting SSL mode;
1405 if this is set to NULL but sll_cert_filepath is set, the
1406 OPENSSL_CONTEXT_REQUIRES_PRIVATE_KEY callback is called
1407 to allow setting of the private key directly via openSSL
1409 <dt><b>ssl_ca_filepath</b>
1410 <dd>CA certificate filepath or NULL
1411 <dt><b>ssl_cipher_list</b>
1412 <dd>List of valid ciphers to use (eg,
1413 "RC4-MD5:RC4-SHA:AES128-SHA:AES256-SHA:HIGH:!DSS:!aNULL"
1414 or you can leave it as NULL to get "DEFAULT"
1415 <dt><b>http_proxy_address</b>
1416 <dd>If non-NULL, attempts to proxy via the given address.
1417 If proxy auth is required, use format
1418 "username:password<tt><b>server</b></tt>:port"
1419 <dt><b>http_proxy_port</b>
1420 <dd>If http_proxy_address was non-NULL, uses this port at
1423 <dd>group id to change to after setting listen socket, or -1.
1425 <dd>user id to change to after setting listen socket, or -1.
1427 <dd>0, or LWS_SERVER_OPTION_... bitfields
1429 <dd>optional user pointer that can be recovered via the context
1430 pointer using lws_context_user
1432 <dd>0 for no keepalive, otherwise apply this keepalive timeout to
1433 all libwebsocket sockets, client or server
1434 <dt><b>ka_probes</b>
1435 <dd>if ka_time was nonzero, after the timeout expires how many
1436 times to try to get a response from the peer before giving up
1437 and killing the connection
1438 <dt><b>ka_interval</b>
1439 <dd>if ka_time was nonzero, how long to wait before each ka_probes
1441 <dt><b>provided_client_ssl_ctx</b>
1442 <dd>If non-null, swap out libwebsockets ssl
1443 implementation for the one provided by provided_ssl_ctx.
1444 Libwebsockets no longer is responsible for freeing the context
1445 if this option is selected.
1446 <dt><b>provided_client_ssl_ctx</b>
1447 <dd>If non-null, swap out libwebsockets ssl
1448 implementation for the one provided by provided_ssl_ctx.
1449 Libwebsockets no longer is responsible for freeing the context
1450 if this option is selected.
1451 <dt><b>max_http_header_data</b>
1452 <dd>The max amount of header payload that can be handled
1453 in an http request (unrecognized header payload is dropped)
1454 <dt><b>max_http_header_pool</b>
1455 <dd>The max number of connections with http headers that
1456 can be processed simultaneously (the corresponding memory is
1457 allocated for the lifetime of the context). If the pool is
1458 busy new incoming connections must wait for accept until one
1462 <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>
1463 <i>LWS_EXTERN void</i>
1464 <b>lws_close_reason</b>
1465 (<i>struct lws *</i> <b>wsi</b>,
1466 <i>enum lws_close_status</i> <b>status</b>,
1467 <i>unsigned char *</i> <b>buf</b>,
1468 <i>size_t</i> <b>len</b>)
1472 <dd>The websocket connection to set the close reason on
1474 <dd>A valid close status from websocket standard
1476 <dd>NULL or buffer containing up to 124 bytes of auxiliary data
1478 <dd>Length of data in <tt><b>buf</b></tt> to send
projects / platform / upstream / libwebsockets.git / blob