Changelog
---------
-(post-1.3)
-==========
+Fixes
+-----
+
+1) MINOR: d9n't send ext hdr if no exts to discuss
+
+v1.7.3
+======
+
+NB: No API change since v1.7.0
+
+Fixes
+-----
+
+1) MAJOR connections on ah waiting list that closed did not get removed from
+the waiting list...
+
+2) MAJOR since we added the ability to hold an ah across http keepalive
+transactions where more headers had already arrived, we broke the ability
+to tell if more headers had arrived. Result was if the browser didn't
+close the keepalive, we retained ah for the lifetime of the keepalive,
+using up the pool.
+
+3) MAJOR windows-only-POLLHUP was not coming
+
+4) Fix build on NetBSD
+
+
+v1.7.2
+======
+
+NB: No API change since v1.7.0
+
+Fixes
+-----
+
+1) libuv one-per-session valgrind leak fixed
+
+2) MINOR An error about hdr struct in _lws_ws_related is corrected, it's not
+known to affect anything added until after it was fixed
+
+3) MINOR During the close shutdown wait state introduced at v1.7, if something
+requests callback on writeable for the socket it will busywait until the
+socket closes
+
+4) MINOR update URLs in test html for libwebsockets.org https STS changes
+
+Changes
+-------
+
+1) test server html is updated with tabs and a new live server monitoring
+feature. Input sanitization added to the js.
+
+
+v1.7.1
+======
+
+NB: No API change since v1.7.0
+
+Fixes
+-----
+
+1) MAJOR (Windows-only) fix assert firing
+
+2) MAJOR http:/1.1 connections handled by lws_return_http_status() did not
+get sent a content-length resulting in the link hanging until the peer closed
+it. attack.sh updated to add a test for this.
+
+
+Changes
+-------
+
+1) MINOR test-server gained some new switches
+
+ -C <file> use external SSL cert file
+ -K <file> use external SSL key file
+ -A <file> use external SSL CA cert file
+
+ -u <uid> set effective uid
+ -g <gid> set effective gid
+
+together you can use them like this to have the test-server work with the
+usual purchased SSL certs from an official CA.
+
+ --ssl -C your.crt -K your.key -A your.cer -u 99 -g 99
+
+2) MINOR the OpenSSL magic to setup ECDH cipher usage is implemented in the
+library, and the ciphers restricted to use ECDH only.
+Using this, the lws test server can score an A at SSLLABS test
+
+3) MINOR STS (SSL always) header is added to the test server if you use --ssl. With
+that, we score A+ at SSLLABS test
+
+4) MINOR daemonize function (disabled at cmake by default) is updated to work
+with systemd
+
+5) MINOR example systemd .service file now provided for test server
+(not installed by default)
+
+
+v1.7.0
+======
+
+Extension Changes
+-----------------
+
+1) There is now a "permessage-deflate" / RFC7692 implementation. It's very
+similar to "deflate-frame" we have offered for a long while; deflate-frame is
+now provided as an alias of permessage-deflate.
+
+The main differences are that the new permessage-deflate implementation:
+
+ - properly performs streaming respecting input and output buffer limits. The
+ old deflate-frame implementation could only work on complete deflate input
+ and produce complete inflate output for each frame. The new implementation
+ only mallocs buffers at initialization.
+
+ - goes around the event loop after each input package is processed allowing
+ interleaved output processing. The RX flow control api can be used to
+ force compressed input processing to match the rate of compressed output
+ processing (test--echo shows an example of how to do this).
+
+ - when being "deflate-frame" for compatibility he uses the same default zlib
+ settings as the old "deflate-frame", but instead of exponentially increasing
+ malloc allocations until the whole output will fit, he observes the default
+ input and output chunking buffer sizes of "permessage-deflate", that's
+ 1024 in and 1024 out at a time.
+
+2) deflate-stream has been disabled for many versions (for over a year) and is
+now removed. Browsers are now standardizing on "permessage-deflate" / RFC7692
+
+3) struct lws_extension is simplified, and lws extensions now have a public
+api (their callback) for use in user code to compose extensions and options
+the user code wants. lws_get_internal_exts() is deprecated but kept around
+as a NOP. The changes allow one extension implementation to go by different
+names and allows the user client code to control option offers per-ext.
+
+The test client and server are updated to use the new way. If you use
+the old way it should still work, but extensions will be disabled until you
+update your code.
+
+Extensions are now responsible for allocating and per-instance private struct
+at instance construction time and freeing it when the instance is destroyed.
+Not needing to know the size means the extension's struct can be opaque
+to user code.
+
+
+User api additions
+------------------
+
+1) The info struct gained three new members
+
+ - max_http_header_data: 0 for default (1024) or set the maximum amount of known
+ http header payload that lws can deal with. Payload in unknown http
+ headers is dropped silently. If for some reason you need to send huge
+ cookies or other HTTP-level headers, you can now increase this at context-
+ creation time.
+
+ - max_http_header_pool: 0 for default (16) or set the maximum amount of http
+ headers that can be tracked by lws in this context. For the server, if
+ the header pool is completely in use then accepts on the listen socket
+ are disabled until one becomes free. For the client, if you simultaneously
+ have pending connects for more than this number of client connections,
+ additional connects will fail until some of the pending connections timeout
+ or complete.
+
+ - timeout_secs: 0 for default (currently 20s), or set the library's
+ network activity timeout to the given number of seconds
+
+HTTP header processing in lws only exists until just after the first main
+callback after the HTTP handshake... for ws connections that is ESTABLISHED and
+for HTTP connections the HTTP callback.
+
+So these settings are not related to the maximum number of simultaneous
+connections, but the number of HTTP handshakes that may be expected or ongoing,
+or have just completed, at one time. The reason it's useful is it changes the
+memory allocation for header processing to be one-time at context creation
+instead of every time there is a new connection, and gives you control over
+the peak allocation.
+
+Setting max_http_header_pool to 1 is fine it will just queue incoming
+connections before the accept as necessary, you can still have as many
+simultaneous post-header connections as you like. Since the http header
+processing is completed and the allocation released after ESTABLISHED or the
+HTTP callback, even with a pool of 1 many connections can be handled rapidly.
+
+2) There is a new callback that allows the user code to get acccess to the
+optional close code + aux data that may have been sent by the peer.
+
+LWS_CALLBACK_WS_PEER_INITIATED_CLOSE:
+ The peer has sent an unsolicited Close WS packet. @in and
+ @len are the optional close code (first 2 bytes, network
+ order) and the optional additional information which is not
+ defined in the standard, and may be a string or non-human-
+ readble data.
+ If you return 0 lws will echo the close and then close the
+ connection. If you return nonzero lws will just close the
+ connection.
+
+As usual not handling it does the right thing, if you're not interested in it
+just ignore it.
+
+The test server has "open and close" testing buttons at the bottom, if you
+open and close that connection, on close it will send a close code 3000 decimal
+and the string "Bye!" as the aux data.
+
+The test server dumb-increment callback handles this callback reason and prints
+
+lwsts[15714]: LWS_CALLBACK_WS_PEER_INITIATED_CLOSE: len 6
+lwsts[15714]: 0: 0x0B
+lwsts[15714]: 1: 0xB8
+lwsts[15714]: 2: 0x42
+lwsts[15714]: 3: 0x79
+lwsts[15714]: 4: 0x65
+lwsts[15714]: 5: 0x21
+
+3) There is a new API to allow the user code to control the content of the
+close frame sent when about to return nonzero from the user callback to
+indicate the connection should close.
+
+/**
+ * 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.
+ *
+ * @wsi: The websocket connection to set the close reason on
+ * @status: A valid close status from websocket standard
+ * @buf: NULL or buffer containing up to 124 bytes of auxiliary data
+ * @len: Length of data in @buf to send
+ */
+LWS_VISIBLE LWS_EXTERN void
+lws_close_reason(struct lws *wsi, enum lws_close_status status,
+ unsigned char *buf, size_t len);
+
+An extra button is added to the "open and close" test server page that requests
+that the test server close the connection from his end.
+
+The test server code will do so by
+
+ lws_close_reason(wsi, LWS_CLOSE_STATUS_GOINGAWAY,
+ (unsigned char *)"seeya", 5);
+ return -1;
+
+The browser shows the close code and reason he received
+
+websocket connection CLOSED, code: 1001, reason: seeya
+
+4) There's a new context creation time option flag
+
+LWS_SERVER_OPTION_VALIDATE_UTF8
+
+if you set it in info->options, then TEXT and CLOSE frames will get checked to
+confirm that they contain valid UTF-8. If they don't, the connection will get
+closed by lws.
+
+5) ECDH Certs are now supported. Enable the CMake option
+
+cmake .. -DLWS_SSL_SERVER_WITH_ECDH_CERT=1
+
+**and** the info->options flag
+
+LWS_SERVER_OPTION_SSL_ECDH
+
+to build in support and select it at runtime.
+
+6) There's a new api lws_parse_uri() that simplifies chopping up
+https://xxx:yyy/zzz uris into parts nicely. The test client now uses this
+to allow proper uris as well as the old address style.
+
+7) SMP support is integrated into LWS without any internal threading. It's
+very simple to use, libwebsockets-test-server-pthread shows how to do it,
+use -j <n> argument there to control the number of service threads up to 32.
+
+Two new members are added to the info struct
+
+ unsigned int count_threads;
+ unsigned int fd_limit_per_thread;
+
+leave them at the default 0 to get the normal singlethreaded service loop.
+
+Set count_threads to n to tell lws you will have n simultaneous service threads
+operating on the context.
+
+There is still a single listen socket on one port, no matter how many
+service threads.
+
+When a connection is made, it is accepted by the service thread with the least
+connections active to perform load balancing.
+
+The user code is responsible for spawning n threads running the service loop
+associated to a specific tsi (Thread Service Index, 0 .. n - 1). See
+the libwebsockets-test-server-pthread for how to do.
+
+If you leave fd_limit_per_thread at 0, then the process limit of fds is shared
+between the service threads; if you process was allowed 1024 fds overall then
+each thread is limited to 1024 / n.
+
+You can set fd_limit_per_thread to a nonzero number to control this manually, eg
+the overall supported fd limit is less than the process allowance.
+
+You can control the context basic data allocation for multithreading from Cmake
+using -DLWS_MAX_SMP=, if not given it's set to 32. The serv_buf allocation
+for the threads (currently 4096) is made at runtime only for active threads.
+
+Because lws will limit the requested number of actual threads supported
+according to LWS_MAX_SMP, there is an api lws_get_count_threads(context) to
+discover how many threads were actually allowed when the context was created.
+
+It's required to implement locking in the user code in the same way that
+libwebsockets-test-server-pthread does it, for the FD locking callbacks.
+
+If LWS_MAX_SMP=1, then there is no code related to pthreads compiled in the
+library. If more than 1, a small amount of pthread mutex code is built into
+the library.
+
+8) New API
+
+LWS_VISIBLE struct lws *
+lws_adopt_socket(struct lws_context *context, lws_sockfd_type accept_fd)
+
+allows foreign sockets accepted by non-lws code to be adopted by lws as if they
+had just been accepted by lws' own listen socket.
+
+9) X-Real-IP: header has been added as WSI_TOKEN_HTTP_X_REAL_IP
+
+10) Libuv support is added, there are new related user apis
+
+typedef void (lws_uv_signal_cb_t)(uv_loop_t *l, uv_signal_t *w, int revents);
+
+LWS_VISIBLE LWS_EXTERN int
+lws_uv_sigint_cfg(struct lws_context *context, int use_uv_sigint,
+ lws_uv_signal_cb_t *cb);
+
+LWS_VISIBLE LWS_EXTERN int
+lws_uv_initloop(struct lws_context *context, uv_loop_t *loop, int tsi);
+
+LWS_VISIBLE void
+lws_uv_sigint_cb(uv_loop_t *loop, uv_signal_t *watcher, int revents);
+
+and CMAKE option
+
+LWS_WITH_LIBUV
+
+
+User api changes
+----------------
+
+1) LWS_SEND_BUFFER_POST_PADDING is now 0 and deprecated. You can remove it; if
+you still use it, obviously it does nothing. Old binary code with nonzero
+LWS_SEND_BUFFER_POST_PADDING is perfectly compatible, the old code just
+allocated a buffer bigger than the library is going to use.
+
+The example apps no longer use LWS_SEND_BUFFER_POST_PADDING.
+
+The only path who made use of it was sending with LWS_WRITE_CLOSE --->
+
+2) Because of lws_close_reason() formalizing handling close frames,
+LWS_WRITE_CLOSE is removed from libwebsockets.h. It was only of use to send
+close frames...close frame content should be managed using lws_close_reason()
+now.
+
+3) We check for invalid CLOSE codes and complain about protocol violation in
+our close code. But it changes little since we were in the middle of closing
+anyway.
+
+4) zero-length RX frames and zero length TX frames are now allowed.
+
+5) Pings and close used to be limited to 124 bytes, the correct limit is 125
+so that is now also allowed.
+
+6) LWS_PRE is provided as a synonym for LWS_SEND_BUFFER_PRE_PADDING, either is
+valid to use now.
+
+7) There's generic support for RFC7462 style extension options built into the
+library now. As a consequence, a field "options" is added to lws_extension.
+It can be NULL if there are no options on the extension. Extension internal
+info is part of the public abi because extensions may be implemented outside
+the library.
+
+8) WSI_TOKEN_PROXY enum was accidentally defined to collide with another token
+of value 73. That's now corrected and WSI_TOKEN_PROXY moved to his own place at
+77.
+
+9) With the addition of libuv support, libev is not the only event loop
+library in town and his api names must be elaborated with _ev_
+
+ Callback typedef: lws_signal_cb ---> lws_ev_signal_cb_t
+ lws_sigint_cfg --> lws_ev_sigint_cfg
+ lws_initloop --> lws_ev_initloop
+ lws_sigint_cb --> lws_ev_sigint_cb
+
+10) Libev support is made compatible with multithreaded service,
+lws_ev_initloop (was lws_initloop) gets an extra argument for the
+thread service index (use 0 if you will just have 1 service thread).
+
+LWS_VISIBLE LWS_EXTERN int
+lws_ev_initloop(struct lws_context *context, ev_loop_t *loop, int tsi);
+
+
+v1.6.0-chrome48-firefox42
+=======================
+
+Major API improvements
+----------------------
+
+v1.6.0 has many cleanups and improvements in the API. Although at first it
+looks pretty drastic, user code will only need four actions to update it.
+
+ - Do the three search/replaces in your user code, /libwebsocket_/lws_/,
+ /libwebsockets_/lws_/, and /struct\ libwebsocket/struct\ lws/
+
+ - Remove the context parameter from your user callbacks
+
+ - Remove context as the first parameter from the "Eleven APIS" listed in the
+ User Api Changes section
+
+ - Add lws_get_context(wsi) as the first parameter on the "Three APIS" listed
+ in the User Api Changes section, and anywhere else you still need context
+
+That's it... generally only a handful of the 14 affected APIs are actually in
+use in your user code and you can find them quickest by compiling and visiting
+the errors each in turn. And the end results are much cleaner, more
+predictable and maintainable.
+
+
+User api additions
+------------------
+
+1) lws now exposes his internal platform file abstraction in a way that can be
+both used by user code to make it platform-agnostic, and be overridden or
+subclassed by user code. This allows things like handling the URI "directory
+space" as a virtual filesystem that may or may not be backed by a regular
+filesystem. One example use is serving files from inside large compressed
+archive storage without having to unpack anything except the file being
+requested.
+
+The test server shows how to use it, basically the platform-specific part of
+lws prepares a file operations structure that lives in the lws context.
+
+Helpers are provided to also leverage these platform-independent file handling
+apis
+
+static inline lws_filefd_type
+lws_plat_file_open(struct lws *wsi, const char *filename,
+ unsigned long *filelen, int flags)
+static inline int
+lws_plat_file_close(struct lws *wsi, lws_filefd_type fd)
+
+static inline unsigned long
+lws_plat_file_seek_cur(struct lws *wsi, lws_filefd_type fd, long offset)
+
+static inline int
+lws_plat_file_read(struct lws *wsi, lws_filefd_type fd, unsigned long *amount,
+ unsigned char *buf, unsigned long len)
+
+static inline int
+lws_plat_file_write(struct lws *wsi, lws_filefd_type fd, unsigned long *amount,
+ unsigned char *buf, unsigned long len)
+
+The user code can also override or subclass the file operations, to either
+wrap or replace them. An example is shown in test server.
+
+A wsi can be associated with the file activity, allowing per-connection
+authentication and state to be used when interpreting the file request.
+
+2) A new API void * lws_wsi_user(struct lws *wsi) lets you get the pointer to
+the user data associated with the wsi, just from the wsi.
+
+3) URI argument handling. Libwebsockets parses and protects URI arguments
+like test.html?arg1=1&arg2=2, it decodes %xx uriencoding format and reduces
+path attacks like ../.../../etc/passwd so they cannot go behind the web
+server's /. There is a list of confirmed attacks we're proof against in
+./test-server/attack.sh.
+
+There is a new API lws_hdr_copy_fragment that should be used now to access
+the URI arguments (it returns the fragments length)
+
+ while (lws_hdr_copy_fragment(wsi, buf, sizeof(buf),
+ WSI_TOKEN_HTTP_URI_ARGS, n) > 0) {
+ lwsl_info("URI Arg %d: %s\n", ++n, buf);
+ }
+
+For the example above, calling with n=0 will return "arg1=1" and n=1 "arg2=2".
+All legal uriencodings will have been reduced in those strings.
+
+lws_hdr_copy_fragment() returns the length of the x=y fragment, so it's also
+possible to deal with arguments containing %00. If you don't care about that,
+the returned string has '\0' appended to simplify processing.
+
+
+User api changes
+----------------
+
+1) Three APIS
+
+ - lws_callback_on_writable_all_protocol(const struct lws_protocols *protocol)
+ - lws_callback_all_protocol(const struct lws_protocols *protocol)
+ - lws_rx_flow_allow_all_protocol(lws_rx_flow_allow_all_protocol)
+
+Now take an additional pointer to the lws_context in their first argument.
+
+The reason for this change is struct lws_protocols has been changed to remove
+members that lws used for private storage: so the protocols struct in now
+truly const and may be reused serially or simultaneously by different contexts.
+
+2) Eleven APIs
+
+LWS_VISIBLE LWS_EXTERN int
+lws_add_http_header_by_name(struct lws_context *context,
+ struct lws *wsi,
+ const unsigned char *name,
+ const unsigned char *value,
+ int length,
+ unsigned char **p,
+ unsigned char *end);
+LWS_VISIBLE LWS_EXTERN int
+lws_finalize_http_header(struct lws_context *context,
+ struct lws *wsi,
+ unsigned char **p,
+ unsigned char *end);
+LWS_VISIBLE LWS_EXTERN int
+lws_add_http_header_by_token(struct lws_context *context,
+ struct lws *wsi,
+ enum lws_token_indexes token,
+ const unsigned char *value,
+ int length,
+ unsigned char **p,
+ unsigned char *end);
+LWS_VISIBLE LWS_EXTERN int
+lws_add_http_header_content_length(struct lws_context *context,
+ struct lws *wsi,
+ unsigned long content_length,
+ unsigned char **p,
+ unsigned char *end);
+LWS_VISIBLE LWS_EXTERN int
+lws_add_http_header_status(struct lws_context *context, struct lws *wsi,
+ unsigned int code, unsigned char **p,
+ unsigned char *end);
+
+LWS_VISIBLE LWS_EXTERN int
+lws_serve_http_file(struct lws_context *context, struct lws *wsi,
+ const char *file, const char *content_type,
+ const char *other_headers, int other_headers_len);
+LWS_VISIBLE LWS_EXTERN int
+lws_serve_http_file_fragment(struct lws_context *context, struct lws *wsi);
+
+LWS_VISIBLE LWS_EXTERN int
+lws_return_http_status(struct lws_context *context, struct lws *wsi,
+ unsigned int code, const char *html_body);
+
+LWS_VISIBLE LWS_EXTERN int
+lws_callback_on_writable(const struct lws_context *context, struct lws *wsi);
+
+LWS_VISIBLE LWS_EXTERN void
+lws_get_peer_addresses(struct lws_context *context, struct lws *wsi,
+ lws_sockfd_type fd, char *name, int name_len,
+ char *rip, int rip_len);
+
+LWS_VISIBLE LWS_EXTERN int
+lws_read(struct lws_context *context, struct lws *wsi,
+ unsigned char *buf, size_t len);
+
+no longer require their initial struct lws_context * parameter.
+
+3) Several older apis start with libwebsocket_ or libwebsockets_ while newer ones
+all begin lws_. These apis have been changed to all begin with lws_.
+
+To convert, search-replace
+
+ - libwebsockets_/lws_
+ - libwebsocket_/lws_
+ - struct\ libwebsocket/struct\ lws
+
+4) context parameter removed from user callback.
+
+Since almost all apis no longer need the context as a parameter, it's no longer
+provided at the user callback directly.
+
+However if you need it, for ALL callbacks wsi is valid and has a valid context
+pointer you can recover using lws_get_context(wsi).
+
+
+v1.5-chrome47-firefox41
+=======================
+
+User api changes
+----------------
+
+LWS_CALLBACK_CLIENT_CONNECTION_ERROR may provide an error string if in is
+non-NULL. If so, the string has length len.
+
+LWS_SERVER_OPTION_PEER_CERT_NOT_REQUIRED is available to relax the requirement
+for peer certs if you are using the option to require client certs.
+
+LWS_WITHOUT_BUILTIN_SHA1 cmake option forces lws to use SHA1() defined
+externally, eg, byOpenSSL, and disables build of libwebsockets_SHA1()
+
+
+v1.4-chrome43-firefox36
+=======================
User api additions
------------------
writeable callback is called again. If you only do one write per writeable callback,
you can ignore this.
+HTTP2-related: HTTP2 changes how headers are handled, lws now has new version-
+agnositic header creation APIs. These do the right thing depending on each
+connection's HTTP version without the user code having to know or care, except
+to make sure to use the new APIs for headers (test-server is updated to use
+them already, so look there for examples)
+
+The APIs "render" the headers into a user-provided buffer and bump *p as it
+is used. If *p reaches end, then the APIs return nonzero for error.
+
+LWS_VISIBLE LWS_EXTERN int
+lws_add_http_header_status(struct libwebsocket_context *context,
+ struct libwebsocket *wsi,
+ unsigned int code,
+ unsigned char **p,
+ unsigned char *end);
+
+Start a response header reporting status like 200, 500, etc
+
+LWS_VISIBLE LWS_EXTERN int
+lws_add_http_header_by_name(struct libwebsocket_context *context,
+ struct libwebsocket *wsi,
+ const unsigned char *name,
+ const unsigned char *value,
+ int length,
+ unsigned char **p,
+ unsigned char *end);
+
+Add a header like name: value in HTTP1.x
+
+LWS_VISIBLE LWS_EXTERN int
+lws_finalize_http_header(struct libwebsocket_context *context,
+ struct libwebsocket *wsi,
+ unsigned char **p,
+ unsigned char *end);
+
+Finish off the headers, like add the extra \r\n in HTTP1.x
+
+LWS_VISIBLE LWS_EXTERN int
+lws_add_http_header_by_token(struct libwebsocket_context *context,
+ struct libwebsocket *wsi,
+ enum lws_token_indexes token,
+ const unsigned char *value,
+ int length,
+ unsigned char **p,
+ unsigned char *end);
+
+Add a header by using a lws token as the name part. In HTTP2, this can be
+compressed to one or two bytes.
+
User api removal
----------------
protocols struct member no_buffer_all_partial_tx is removed. Under some
-conditions like rewriting extention such as compression in use, the built-in
+conditions like rewriting extension such as compression in use, the built-in
partial send buffering is the only way to deal with the problem, so turning
it off is deprecated.
+User api changes
+----------------
+
+HTTP2-related: API libwebsockets_serve_http_file() takes an extra parameter at
+the end now
+
+int other_headers_len)
+
+If you are providing other headers, they must be generated using the new
+HTTP-version-agnostic APIs, and you must provide the length of them using this
+additional parameter.
+
+struct lws_context_creation_info now has an additional member
+SSL_CTX *provided_client_ssl_ctx you may set to an externally-initialized
+SSL_CTX managed outside lws. Defaulting to zero keeps the existing behaviour of
+lws managing the context, if you memset the struct to 0 or have as a filescope
+initialized struct in bss, no need to change anything.
+
v1.3-chrome37-firefox30
=======================
- if your OS does not support the http_proxy environment variable convention
(eg, reportedly OSX), you can use a new api libwebsocket_set_proxy()
- to set the proxy details inbetween context creation and the connection
+ to set the proxy details in between context creation and the connection
action. For OSes that support http_proxy, that's used automatically.
User api changes
projects / platform / upstream / libwebsockets.git / blobdiff