Project homepage Mailing List  API Docs  Github Mirror 
{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"en-US,en;q\u003d0.5", "gen_ut":1597276396, "reponame":"libwebsockets", "desc":"libwebsockets lightweight C networking library", "owner": { "name": "Andy Green", "email": "", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"", "f":3, "items": [ { "schema":"libjg2-1", "oid":{ "oid": "c744c0934d69912e1cc50ff23d203ad60d535709", "alias": [ "refs/heads/v3.2-stable","refs/tags/v3.2.3"]},"tree": [ { "name": "READMEs","mode": "16384", "size":0}, { "name": "cmake","mode": "16384", "size":0}, { "name": "contrib","mode": "16384", "size":0}, { "name": "doc-assets","mode": "16384", "size":0}, { "name": "include","mode": "16384", "size":0}, { "name": "lib","mode": "16384", "size":0}, { "name": "lwsws","mode": "16384", "size":0}, { "name": "minimal-examples","mode": "16384", "size":0}, { "name": "plugin-standalone","mode": "16384", "size":0}, { "name": "plugins","mode": "16384", "size":0}, { "name": "scripts","mode": "16384", "size":0}, { "name": "test-apps","mode": "16384", "size":0}, { "name": "win32port","mode": "16384", "size":0}, { "name": ".gitignore","mode": "33188", "size":724}, { "name": ".mailmap","mode": "33188", "size":103}, { "name": ".travis.yml","mode": "33188", "size":2593}, { "name": "CMakeLists.txt","mode": "33188", "size":87218}, { "name": "Kconfig","mode": "33188", "size":857}, { "name": "LICENSE","mode": "33188", "size":28754}, { "name": "Makefile.projbuild","mode": "33188", "size":54}, { "name": "","mode": "33188", "size":17904}, { "name": "appveyor.yml","mode": "33188", "size":3075}, { "name": "changelog","mode": "33188", "size":42301}, { "name": "","mode": "33188", "size":1659}, { "name": "libwebsockets.dox","mode": "33188", "size":14177}],"s":{"c":1597276396,"u": 3398}} ,{"schema":"libjg2-1", "cid":"b0d43ea5b92ee8504f0d5fbf51acf26d", "oid":{ "oid": "c744c0934d69912e1cc50ff23d203ad60d535709", "alias": [ "refs/heads/v3.2-stable","refs/tags/v3.2.3"]},"blobname": "", "blob": "[![Travis Build Status](]( [![Appveyor Build status](\u003dtrue)]( [![Coverity Scan Build Status](]( [![CII Best Practices](]( [![Codacy Badge](](\\u0026amp;utm_medium\u003dreferral\u0026amp;utm_content\u003dwarmcat/libwebsockets\u0026amp;utm_campaign\u003dBadge_Grade)\n\n# Libwebsockets\n\nLibwebsockets is a simple-to-use, pure C library providing client and server\nfor **http/1**, **http/2**, **websockets** and other protocols in a security-minded,\nlightweight, configurable, scalable and flexible way. It's easy to build and\ncross-build via cmake and is suitable for tasks from embedded RTOS through mass\ncloud serving.\n\n[50 minimal examples]( for\nvarious scenarios, CC0-licensed (public domain) for cut-and-paste, allow you to get started quickly.\n\n![overview](./doc-assets/lws-overview.png)\n\nNews\n----\n\n## V3.2 relase last planned LGPLv2.1+SLE release\n\nAs foretold the v3.2 release is the last planned release that will have the code\nunder LGPLv2.1+SLE. Master has those parts changed to MIT license; the pieces\nthat were CC0 or another liberal license remain the same.\n\n## License change plan\n\nLws is planning to change the pieces that are currently LGPLv2.1+SLE to MIT\n . Stuff that is already CC0 or another\npermissive license will stay as it is.\n\nThis license change is making an already permissive license (it was already LGPL,\nand the SLE removed most restrictions already) even more permissive.\nSo I expect most contributors either don't much care or are happy about it.\nContributors who object should contact me via:\n\n - the lws mailing list\n - github issue , or\n - email to ``\n\n...before **Aug 11 2019**, and I'll rewrite the related code before the change.\nThere'll be a last release of the currently-licensed stuff (probably v3.2) and\nthen the same code will have the licese grant changed in the sources, become\nmaster and also have an otherwise identical release, probably v4.0. The v3.2\nstuff won't be maintained (by me anyway... it's FOSS though) but the v4.0\nstuff which is the same except the license will get the usual v4.0-stable\ntreatment.\n\nEven after the change I will continue to rely on users to help me with bug\nreports and patches, work together on new features. The license will no\nlonger require it but the practical advantages from staying aligned with\nupstream lws for users remain the same.\n\n## New features on master\n\n - `LWS_WITH_NETWORK` cmake option (default on) allows one-step removal of vhost,\n wsi, roles, event loop and all network-related code from the build. This\n enables use-cases where you actually need unrelated features like JOSE or FTS\n compactly. lws_context still exists and if tls is enabled, the tls-related code\n is still built so the crypto is available, just nothing related to network.\n\n - New Crypto-agile APIs + JOSE / JWS / JWE / JWK support... apis work exactly\n the same with OpenSSL or mbedTLS tls library backends, and allow key cycling\n and crypto algorithm changes while allowing for grace periods\n\n [README.crypto-apis](\n\n - CMake config simplification for crypto: `-DLWS_WITH_GENCRYPTO\u003d1` for all\n generic cipher and hash apis built (which work the same on mbedtls and\n OpenSSL transparently), and `-DLWS_WITH_JOSE\u003d1` for all JOSE, JWK, JWS\n and JWE support built (which use gencrypto and so also work the same\n regardless of tls library backend).\n\n - **`x.509`** - new generic x509 api allows PEM-based certificate and key\n trust relationship verification, and conversion between x.509 keys and\n JWK. Works for EC and RSA keys, and on mbedtls and OpenSSl the same.\n\n [x.509 api](, \n [x.509 minimal example](\n\n - **`JWE`** - JWE (RFC7516) Algorithms with CI tests:\n\n|Key Encryption|Payload authentication + crypt|Enc + Dec Support|\n|---|---|---|\n|`RSAES-PKCS1-v1.5` 2048b \u0026 4096b|`AES_128_CBC_HMAC_SHA_256`|Enc + Dec|\n|`RSAES-PKCS1-v1.5` 2048b|`AES_192_CBC_HMAC_SHA_384`|Enc + Dec|\n|`RSAES-PKCS1-v1.5` 2048b|`AES_256_CBC_HMAC_SHA_512`|Enc + Dec|\n|`RSAES-OAEP`|`AES_256_GCM`|Enc + Dec|\n|`AES128KW`, `AES192KW`, `AES256KW`|`AES_128_CBC_HMAC_SHA_256`|Enc + Dec|\n|`AES128KW`, `AES192KW`, `AES256KW`|`AES_192_CBC_HMAC_SHA_384`|Enc + Dec|\n|`AES128KW`, `AES192KW`, `AES256KW`|`AES_256_CBC_HMAC_SHA_512`|Enc + Dec|\n|`ECDH-ES` (P-256/384/521 key)|`AES_128/192/256_GCM`|Enc + Dec|\n|`ECDH-ES+A128/192/256KW` (P-256/384/521 key)|`AES_128/192/256_GCM`|Enc + Dec|\n\nAll tests pass on both OpenSSL and mbedTLS backends, using keys generated on\nboth OpenSSL and mbedTLS in the tests.\n\nA minimal example tool shows how to encrypt and decrypt compact JWE objects\nfrom the commandline for all supported algorithms.\n\n [jwe api](, \n [jwe unit tests](, \n [jwe minimal example](\n\n - **`lws-genec` ECDSA** - JWS-compatible ECDSA is supported on both OpenSSL and mbedtls.\n\n - **`JWS`** - JWS (RFC7515) is now supported for none, HS256/384/512, RS256/384/512, and ES256/384/512, on both OpenSSL and mbedtls. There's a minimal example tool that signs and verifies compact\n representation JWS from stdin.\n [jws api](, \n [jws unit tests](, \n [jws minimal example](\n\n - **`JWK`** - JWK (RFC7517) now supports oct, RSA and EC keys including JSON key\n arrays on both OpenSSL and mbedtls. A minimal example tool shows how to create\n new JSON JWK keys to specified parameters from the commandline for all supported\n ciphers.\n\n [jwk minimal example](\n\n - **`lws-genrsa` OAEP + PSS support** - in addition to PKCS#1 1.5 padding, OAEP and PSS are\n now supported on both mbedtls and openssl backends.\n\n - **`lws-genaes` Generic AES crypto** - thin api layer works identically with both mbedtls and openssl\n backends. Supports CBC, CFB128, CFB8, CTR, ECB, OFB, XTS and GCM variants. Unit tests in CI.\n [genaes api](,\n [api test](,\n CMake config: `-DLWS_WITH_GENCRYPTO\u003d1`\n\n - **http fallback support** - you can specify a role and protocol to apply if non-http or non-tls\n packets arrive at an http(s) listen port. For example, you can specify that the new `raw proxy`\n role + protocol should be used, to proxy your sshd port over :443 or :80. Without affecting\n normal http(s) serving on those ports but allowing, eg, `ssh -p 443`.\n [http fallback docs](\n\n - **raw tcp proxy role and protocol** - adding raw tcp proxying is now trivial using the built-in lws\n implementation. You can control the onward connection using a pvo in the format \\u0022\n [raw proxy minimal example](,\n [raw proxy docs](,\n Cmake config: `-DLWS_ROLE_RAW_PROXY\u003d1 -DLWS_WITH_PLUGINS\u003d1`\n\n - **deaddrop HTML file upload protocol** - protocol and minimal example for file upload and sharing using\n drag and drop and a file picker. Integrated with basic auth, uploaded files marked with upload user,\n and files owned by the authenticated user may be deleted via the UI. Supports multiple simultaneous\n uploads both by drag-and-drop and from the file picker.\n [deaddrop minimal example](\n\n - **basic auth for ws(s)** - You can apply basic auth credential requirement to ws connections same\n as on mounts now. Just add a pvo \u0022basic-auth\u0022 with the value being the credentials file path when\n enabling the ws protocol for the vhost.\n\n## v3.1 released: new features in v3.1\n\n - **lws threadpool** - lightweight pool of pthreads integrated to lws wsi, with all\n synchronization to event loop handled internally, queue for excess tasks\n [threadpool docs](, \n [threadpool minimal example](, \n Cmake config: `-DLWS_WITH_THREADPOOL\u003d1`\n\n - **libdbus support** integrated on lws event loop\n [lws dbus docs](, \n [lws dbus client minimal examples](, \n [lws dbus server minimal examples](, \n Cmake config: `-DLWS_ROLE_DBUS\u003d1`\n\n - **lws allocated chunks (lwsac)** - helpers for optimized mass allocation of small\n objects inside a few larger malloc chunks... if you need to allocate a lot of\n inter-related structs for a limited time, this removes per-struct allocation\n library overhead completely and removes the need for any destruction handling\n [lwsac docs](, \n [lwsac minimal example](, \n Cmake Config: `-DLWS_WITH_LWSAC\u003d1`\n\n - **lws tokenizer** - helper api for robustly tokenizing your own strings without\n allocating or adding complexity. Configurable by flags for common delimiter\n sets and comma-separated-lists in the tokenizer. Detects and reports syntax\n errors.\n [lws_tokenize docs](, \n [lws_tokenize minimal example / api test](\n\n - **lws full-text search** - optimized trie generation, serialization,\n autocomplete suggestion generation and instant global search support extensible\n to huge corpuses of UTF-8 text while remaining super lightweight on resources.\n [full-text search docs](, \n [full-text search minimal example / api test](, \n [demo](, \n [demo sources](, \n Cmake config: `-DLWS_WITH_FTS\u003d1 -DLWS_WITH_LWSAC\u003d1`\n\n - **gzip + brotli http server-side compression** - h1 and h2 detection of client support\n for server compression, and auto-application to files with mimetypes \u0022text/*\u0022,\n \u0022application/javascript\u0022 and \u0022image/svg.xml\u0022.\n Cmake config: `-DLWS_WITH_HTTP_STREAM_COMPRESSION\u003d1` for gzip, optionally also give\n `-DLWS_WITH_HTTP_BROTLI\u003d1` for preferred `br` brotli compression\n\n - **managed disk cache** - API for managing a directory containing cached files\n with hashed names, and automatic deletion of LRU files once the cache is\n above a given limit.\n [lws diskcache docs](, \n Cmake config: `-DLWS_WITH_DISKCACHE\u003d1`\n\n - **http reverse proxy** - lws mounts support proxying h1 or h2 requests to\n a local or remote IP, or unix domain socket over h1. This allows microservice\n type architectures where parts of the common URL space are actually handled\n by external processes which may be remote or on the same machine.\n [lws gitohashi serving]( is handled this way.\n [unix domain sockets reverse proxy docs](, \n CMake config: `-DLWS_WITH_HTTP_PROXY\u003d1` and `-DLWS_UNIX_SOCK\u003d1` for Unix Domain Sockets\n\n - **update minimal examples for strict Content Security Policy** the minimal\n examples now show the best practices around Content Security Policy and\n disabling inline Javascript. Updated examples that are served with the\n recommended security restrictions show a new \u0022Strict Content Security Policy\u0022\n graphic. [Read how to upgrade your applications to use a strict CSP](\n\n - **release policy docs** - unsure what branch, version or tag to use, or how\n to follow master cleanly? [Read the release policy docs](\n which explain how and why lws is developed, released and maintained.\n\n## v3.0.1 released\n\nSee the git log for the list of fixes.\n\n## v3.0.0 released\n\nSee the changelog for info\u003dv3.0-stable\n\n## Major CI improvements for QA\n\nThe Travis build of lws done on every commit now runs:\n\nTests|Count|Explanation\n---|---|---\nBuild / Linux / gcc|16|-Wall -Werror cmake config variants\nBuild / Mac / Clang|16|-Wall -Werror cmake config variants\nBuild / Windows / MSVC|7|default\nSelftests|openssl:43, mbedtls:43|minimal examples built and run against each other and remote server\|225|Correctness, robustness and security tests for http parser\nAutobahn Server|480|Testing lws ws client, including permessage-deflate\nAutobahn Client|480|Testing lws ws server, including permaessage-deflate\nh2spec|openssl:146, mbedtls:146|Http/2 server compliance suite (in strict mode)\nh2load|openssl:6, mbedtls:6|Http/2 server load tool (checks 10K / 100K in h1 and h2, at 1, 10, 100 concurrency)\nh2load SMP|6|Http/2 and http/1.1 server load checks on SMP server build\n\nThe over 1,500 tests run on every commit take 1hr 15 of compute time to complete.\nIf any problems are found, it breaks the travis build, generating an email.\n\nCodacy also checks every patch and the information used to keep lws at zero issues.\n\nCurrent master is checked by Coverity at least daily and kept at zero issues.\n\nCurrent master passes all the tests and these new CI arrangements will help\nkeep it that way.\n\n## Lws has the first official ws-over-h2 server support\n\n![wss-over-h2](./doc-assets/wss2.png)\n\nThere's a new [RFC]( that enables multiplexing ws connections\nover an http/2 link. Compared to making individual tcp and tls connections for\neach ws link back to the same server, this makes your site start up radically\nfaster, and since all the connections are in one tls tunnel, with considerable memory\nreduction serverside.\n\nTo enable it on master you just need -DLWS_WITH_HTTP2\u003d1 at cmake. No changes to\nexisting code are necessary for either http/2 (if you use the official header creation\napis if you return your own headers, as shown in the test apps for several versions)\nor to take advantage of ws-over-h2. When built with http/2 support, it automatically\nfalls back to http/1 and traditional ws upgrade if that's all the client can handle.\n\nCurrently only Chrome Canary v67 supports this ws-over-h2 encapsulation (chrome\nmust be started with `--enable-websocket-over-http2` switch to enable it currently),\nand patches exist for Firefox. Authors of both browser implementations tested\nagainst the lws server implementation.\n\n## New \u0022minimal examples\u0022\n\n\n\nThese are like the test apps, but focus on doing one thing, the best way, with the\nminimum amount of code. For example the minimal-http-server serves the cwd on\nhttp/1 or http/2 in 50 LOC. Same thing with tls is just three more lines.\n\nThey build standalone, so it's easier to copy them directly to start your own project; they\nare CC0 licensed (public domain) to facilitate that.\n\n## Windows binary builds\n\n32- and 64-bit Windows binary builds are available via Appveyor. Visit\n[lws on Appveyor](,\nclick on a build, the ARTIFACTS, and unzip the zip file at `C:\u005cProgram Files (x86)/libwebsockets`.\n\n## Support\n\nThis is the libwebsockets C library for lightweight websocket clients and\nservers. For support, visit\n\n\n\nand consider joining the project mailing list at\n\n\n\nYou can get the latest version of the library from git:\n\n-\n\nDoxygen API docs for master:\n\n","s":{"c":1597276396,"u": 3990}} ],"g": 9068,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 1, "si": 0, "db":0, "di":1, "sat":0, "lfc": "0000"}