client: protect against possible NULL deref path
[platform/upstream/libwebsockets.git] / changelog
index 5e48a24..9a8710e 100644 (file)
--- a/changelog
+++ b/changelog
@@ -1,8 +1,713 @@
 Changelog
 ---------
 
-(post-1.3)
-==========
+v1.7.9
+======
+
+NB: lws_snprintf() added, but only used in library and test apps
+SONAME bump to 7.1
+
+Fixes:
+
+1) Fix leak caused by undestroyed pthread mutex
+
+2) Add CLIENT_CONNECTION_ERROR callbacks for more failure paths
+
+3) Fix for client close to callback on one error path 
+
+4) lws_snprintf() needed in a couple of test apps (1.7.x lib doesn't use it
+for aggregated buffer truncation)
+
+
+v1.7.8
+======
+
+NB: No API change since v1.7.0
+
+Fixes:
+
+1) MINOR: user_space arg was mistakenly NULL on LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER
+
+2) MINOR: treating recv() returning 0 as peer close destroyed throughput on ab
+tests, reverted
+
+3) MINOR: %3d on URL part was always turned to _... this should only happen in
+?na%3dme=x part of the URL
+
+4) MINOR: some malloc escaped check for NULL / OOM
+
+
+v1.7.7
+======
+
+NB: No API change since v1.7.0
+
+Fixes:
+
+1) MINOR: Android add needed include file
+
+2) MINOR: Allow build on GCC < 3.4
+
+3) MINOR: Fix client problems recovering cleanly from SSL negotiation failure
+
+
+v1.7.6
+======
+
+NB: No API change since v1.7.0
+
+Fixes
+-----
+
+1) MINOR: libuv-specific fixes
+
+2) MINOR: urldecode forbids malformed %xx in the library 
+
+3) MINOR: small fixes for Android and Windows
+
+4) MINOR: handle 0 read() as closed connection
+
+
+v1.7.5
+======
+
+NB: No API change since v1.7.0
+
+Fixes
+-----
+
+1) MINOR: fix build with musl C library
+
+2) MINOR: libuv handle signals only if requested
+
+3) MINOR: Fix compile warning if HTTP2 + RELEASE + ALPN-capable SSL
+
+4) MINOR: produce and package
+          %{_libdir}/cmake/libwebsockets/LibwebsocketsTargets.cmake
+
+5) MAJOR: make permessage-deflate enforce protocol rx buffer size requirement
+
+
+v1.7.4
+======
+
+NB: No API change since v1.7.0
+
+Fixes
+-----
+
+1) MINOR: don't send ext hdr if no exts to discuss
+
+2) MINOR: libuv + libev small fixes
+
+3) MINOR: some windows build environments have no snprintf
+
+4) MINOR: cmake adapts better to ecdh.h cmake situation
+
+5) MINOR: client missed WSI_CREATE callback
+
+6) MINOR: base64 decode api worked fine for all ws key handling, however
+it was broken for some general decode if user code wanted to use it.
+
+7) MINOR: add optimized parsing path for bulk incoming ws data
+
+
+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
 ------------------
@@ -81,7 +786,7 @@ 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.
 
@@ -332,7 +1037,7 @@ User api additions
 
  - 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