weblite
| Crates.io | weblite |
| lib.rs | weblite |
| version | 0.0.1 |
| created_at | 2025-12-06 21:32:53.267717+00 |
| updated_at | 2025-12-06 21:32:53.267717+00 |
| description | A very simple `no_std` implementation of the HTTP and WebSocket protocols aimed at embedded use cases |
| homepage | https://github.com/ChrisPortman/weblite |
| repository | https://github.com/ChrisPortman/weblite |
| max_upload_size | |
| id | 1970798 |
| size | 88,700 |
(ChrisPortman)
documentation
README
WebLite
weblite is a very basic implementation of the HTTP protocol predominantly aimed at
no_std and no_alloc use cases such as embedded development.
This crate provides:
- encoding and decoding of HTTP requests and responses on the "wire" respectively.
- encoding and decoding of websocket frames on the "wire".
This crate does not provide:
- any mechanism for routing requests to specific handlers.
- any higher level functionality for extracting data from paths, or request bodies.
Example Pattern
My own usage pattern, for an embedded project has been to create a single HTML artefact (index.html)
inlines all required javascript (<script>...</script>) and CSS <head><style>...</style></head>)
as well as SVG images. The HTML is then embedded in the built binary as a const &[u8] with include_bytes!("html/index.html");.
The handler weblite::server::RequestHandler implementation then only handles:
/- responds with the HTML/ws- starts a websocket- other - responds with 404.
The client requests / and gets the single page back. The javascript starts a websocket with
/ws. All further interaction is done via the websocket, with the javascript manipulating the DOM
in response to events and commands received on the socket.
There's no reason you can't have a more complicated URL landscape, but this works for me.