Project homepage Mailing List  Warmcat.com  API Docs  Github Mirror 
{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1764777938, "reponame":"libwebsockets", "desc":"libwebsockets lightweight C networking library", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://libwebsockets.org/repo/libwebsockets", "f":3, "items": [ { "schema":"libjg2-1", "oid":{ "oid": "55dda9d9f5eb722c55dbb338c9e29681ac75b82b", "alias": [ "refs/heads/main"]},"tree": [ { "name": ".github","mode": "16384", "size":0}, { "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": "minimal-examples-lowlevel","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":802}, { "name": ".mailmap","mode": "33188", "size":103}, { "name": ".sai.json","mode": "33188", "size":14472}, { "name": "CMakeLists-implied-options.txt","mode": "33188", "size":11526}, { "name": "CMakeLists.txt","mode": "33188", "size":50435}, { "name": "Kconfig","mode": "33188", "size":857}, { "name": "LICENSE","mode": "33188", "size":19205}, { "name": "Makefile.projbuild","mode": "33188", "size":54}, { "name": "README.md","mode": "33188", "size":9236}, { "name": "SECURITY.md","mode": "33188", "size":287}, { "name": "bug_report.md","mode": "33188", "size":2120}, { "name": "changelog","mode": "33188", "size":35363}, { "name": "component.mk","mode": "33188", "size":1659}, { "name": "lgtm.yml","mode": "33188", "size":76}, { "name": "libwebsockets.dox","mode": "33188", "size":115067}],"s":{"c":1764750399,"u": 4106}} ,{"schema":"libjg2-1", "cid":"43f9c09c5a7824a6002f5e4eefef020b", "oid":{ "oid": "55dda9d9f5eb722c55dbb338c9e29681ac75b82b", "alias": [ "refs/heads/main"]},"blobname": "README.md", "blob": "[![CI status](https://libwebsockets.org/sai/status/libwebsockets)](https://libwebsockets.org/git/libwebsockets) [![Coverity Scan Build Status](https://scan.coverity.com/projects/3576/badge.svg)](https://scan.coverity.com/projects/3576) [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/2266/badge)](https://bestpractices.coreinfrastructure.org/projects/2266) \n\n# Libwebsockets\n\n** v4.5 is released, you can follow it on v4.5-stable **\n\nLibwebsockets is a simple-to-use, MIT-license, pure C library providing client and server\nfor **http/1**, **http/2**, **websockets**, **MQTT** 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\nIt supports a lot of lightweight ancilliary implementations for things like JSON,\nCBOR, JOSE, COSE, and supports OpenSSL and MbedTLS v2 and v3 out of the box for everything.\nIt's very gregarious when it comes to event loop sharing, supporting libuv, libevent, libev,\nsdevent, glib and uloop, as well as custom event libs.\n\n[100+ independent minimal examples](https://libwebsockets.org/git/libwebsockets/tree/minimal-examples) for various scenarios, CC0-licensed\n(public domain) for cut-and-paste, allow you to get started quickly.\n\n[There are a lot of READMEs](https://libwebsockets.org/git/libwebsockets/tree/READMEs) on a variety of topics.\n\n[We do a huge amount of CI testing per push](https://libwebsockets.org/sai/), currently 582 builds on 30 platforms.\n[You can see the lws CI rack and read about how lws-based Sai is used to coordinate all the testing](https://warmcat.com/2021/08/21/Sai-CI.html).\n\n![overview](./doc-assets/lws-overview.png)\n\nNews\n----\n\n## HTML + CSS + JPEG + PNG display stack in lws\n\nWant to drive your EPD or TFT / OLED display using HTML + CSS? Only got an ESP32?\n\nWant remote JPEGs, PNGs, HTML, RGBA composition, gamma, error diffusion if needed?\n\nRealtime render into a line buffer because you don't have enough heap for a framebuffer?\n\n[Take a look here...](https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.html-parser.md)\n\n## Perl binding for lws available\n\nThanks to Felipe Gasper, there's now a [perl binding for lws available at metacpan](https://metacpan.org/pod/Net::Libwebsockets),\nthis uses the recent generic event loop support in lws to have lws as a guest on an existing perl event loop.\n\n## Lws examples switching to Secure Streams\n\n![Secure Streams direct](./doc-assets/ss-api1.png)\n\n**Secure Streams** support in lws was introduced a couple of years ago, it's a\nhigher-level interface to lws `wsi`-level apis that simplifies connectivity by\nsegregating connection policy like protocol and endpoint information into a\nseparate [JSON policy file](./minimal-examples/client/hello_world/example-policy.json), and just having the [code deal with payloads](./minimal-examples/clients/hello_world/hello_world-ss.c); as many\ndetails of the wire protocol as possible are hidden or moved to the policy, so\nuser code is almost identical even if the wire protocol changes.\n\nThe user code just asks to create a SS by \u0022streamtype name\u0022, it is created\naccording to the details (protocol, endpoint, etc) under the same name in the\npolicy.\n\nKey policy entries like endpoint can contain `${metadata-name}` string\nsubstitutions to handle runtime adaptations via metadata. h1, h2, ws and mqtt\nare supported.\n\nAs a layer on top of the `wsi` apis, SS provides a higher-level way to access\nthe existing wsi-level capabilities, both kinds of API will remain supported.\nSecure Streams are longer-lived than a single wsi, so an SS can coordinate\nretries by itself. SS-based user code is typically significantly smaller and\nmore maintainable than wsi layer.\n\nIn main branch I have moved the older examples into `./minimal-examples-lowlevel`\nand am starting to port more cases from there into SS-based examples.\n\n### Comparison between wsi and SS level lws usage\n\n|Feature|\u0022low-level\u0022 wsi way|Secure Streams way|\n|---|---|---|\n|Create context|code|same|\n|Loop support, sul scheduler|default, event libs|same|\n|Supports comms mode|Client, Server, Raw|same|\n|Supports protocols|h1, h2, ws, mqtt (client)|same|\n|TLS support|mbedtls (including v3), openssl (including v3), wolfssl, boringssl, aws-lc, libressl|same|\n|Serializable, proxiable, muxable, transportable|No|Yes|\n|Auto-allocated per-connection user object|pss specified in lws_protocols|Specified in ss info struct|\n|Connection User API|Protocol-specific lws_protocols cbs (\u003e 100)|SS API (rx, tx, state callbacks only)|\n|Sending adaptation|lws_callback_on_writeable() + WRITEABLE|lws_ss_request_write() + tx() cb|\n|Sending buffer|User-chosen + malloc'd partial handling|SS-provided, no partials|\n|Create vhosts|code|**JSON policy**|\n|TLS validation|cert bundle or code|**JSON policy**, or cert bundle|\n|Connection retry / backoff|code|**JSON policy**, Auto|\n|Nailing up|code|**JSON policy**, Auto|\n|Endpoint and protocol details|spread around the code|**JSON policy**|\n|Protocol selection, pipeline / stream sharing|code|**JSON policy**|\n|ws subprotocol selection|code|**JSON policy**|\n|ws binary / text|code|**JSON policy**|\n|Protocol-specific metadata|Protocol-specific apis in code (eg, lws_hdr)|**JSON policy**, generic metadata apis in code|\n|Connection validity rules|struct|**JSON policy**, Auto|\n|Stream as Long Poll|code|**JSON policy**|\n|Auth|code|**JSON policy** + automatic rotation if provider supported, else code|\n\n### Serialized Secure Streams\n\n![Secure Streams direct](./doc-assets/ss-api2.png)\n\nSecure Streams APIs are also **serializable**, the exact same client code can\nfulfil the connection directly in the same process as you would expect, or\nforward the actions, metadata and payloads to an [SS Proxy](./minimal-examples/ssproxy/ssproxy-socket) that owns the policy\nover a Unix Domain or TCP socket connection to be fulfilled centrally. This\nallows, eg, h2 streams from different processes sharing a single connection.\n\n![Secure Streams direct](./doc-assets/ss-api3.png)\n\nThe serialized SS can also travel over generic transports like UART, an [example\nis provided implementing the Binance example on an RPi Pico](./minimal-examples/embedded/pico/pico-sspc-binance) with a UART transport\nto a [UART transport SS proxy](./minimal-examples/ssproxy/ssproxy-custom-transport-uart), where the pico itself has no network stack, tls, compression or\nwss stack, but can send and receive to and from the endpoint as if it did.\n\nThe optional `lws_trasport_mux` is used to interpose between the UART transport\nand the SSPC layer, allowing a single pipe to carry many separate SS connections.\n\nThe user SS code is identical however it is transported, muxed and fulfilled.\n\n\n## v4.3 is released\n\nSee the [changelog](https://libwebsockets.org/git/libwebsockets/tree/changelog)\n\n\n## Support\n\nThis is the libwebsockets C library for lightweight websocket clients and\nservers. For support, visit\n\n https://libwebsockets.org\n\nYou can get the latest version of the library from git:\n\n- https://libwebsockets.org/git\n\nDoxygen API docs for development: https://libwebsockets.org/lws-api-doc-main/html/index.html\n\n### Patching with AI\n\nIn 2025, writing actual code with AI is quite scary while at the same time offering a way\nforward for the thankless and lonely task of maintaining FOSS code. I have been using Google's\nGemini 2.5 and now 3.0, while it's very good at looking at the code and what I am asking\nand producing something sane (much better than a year ago or self-hosted generic models),\nit falls down badly on being able to complete the scope of the patch that it figured out it\nwants to do, and simply stops too early and drops the rest on the floor.\n\nIt deserves praise for being able to work with quite complicated apis in lws like `lws_struct`\nwith both JSON and sqlite3 serializations and deserializations, well, mostly.\n\nIt is much more interested in making new structures and messages for whatever today's problem\nis and much less interested in looking at what's already there and thinking about how that\ncould be adapted or unified. In short it doesn't care at all about mantainability.\n\nIt's also suffering from being strong with its mental model of what's going on and what the\nchange does, but very weak when it has to be told that its patch doesn't do what it expected.\nWhere a human would 'trap' the difference between its mental model and reality so they can\nsee where the model broke, they will often avoid adding logging and instead go down very\nunlikely rabbit holes for hours.\n\nAt the same time, it knows that maintainability and security are supposed to be desirable\ntraits. But it knows it in the same way it knows layered patches are desirable, it can't\ntake care of these considerations properly yet, although it can talk about the concepts.\n\nIn short in 2025, although I will continue to use it for some tasks, it's not at the state\nwhere someone who was unable to do the work carefully themselves can use it for lws. It's\ntoo easy to wave through code that is not understood perhaps by anybody and then deal with\nsecurity problems and other breakage for the rest of your life.\n","s":{"c":1764750399,"u": 4835}} ],"g": 1477,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 0, "si": 0, "db":0, "di":0, "sat":0, "lfc": "7d0a"}