lua-http: an HTTP client and server for Lua, including HTTP/2

Both sides of the connection, and three protocol versions

The feature list is short and each item is a real piece of work. The library is optionally asynchronous, and the parenthesis matters, since the asynchrony extends to DNS lookups and to the TLS handshake rather than stopping at the request. It supports HTTP and HTTPS in versions 1.0, 1.1 and 2, which is the part that sets it apart from most Lua HTTP libraries, since HTTP/2 is a different framing model and not a version bump. There is functionality for both the client and the server side, which is unusual for a scripting language library and means you can write a service in Lua without leaving the language. Cookie management is included, and websockets are supported. The compatibility statement is broad, covering Lua 5.1, 5.2, 5.3, 5.4 and LuaJIT, which is a wide range for a library with a C dependency. The examples directory in the repository shows the shapes the library is meant for, with a simple request, an HTTP/2 streaming example, a static file server, a hello world server, a server sent events server and a websocket client.

Installing through luarocks, and why the rock name is not the repo name

The recommended installation route is luarocks, and the reason given is that it installs the run-time Lua dependencies for you as well:

$ luarocks install http

Note that the rock is called http rather than lua-http, which is a common Lua convention where the rock name is the library name inside the module namespace. The package also ships a rockspec for a development install, and the development flow in the readme is worth reading because it is unusually complete. You clone the repository, install just the dependencies with the only-deps flag against the development rockspec, lint the code with luacheck, run the tests and view the coverage report with busted and luacov, and then install your local copy with luarocks make against the same rockspec:

$ luarocks make http-scm-0.rockspec

The scm suffix in the rockspec name is the LuaRocks convention for a rockspec that tracks a source repository rather than a tagged release, and it is the same file used for the dependency-only install. The presence of luacheck, busted and luacov in the test tooling list says the project treats linting and coverage as part of the loop rather than as an afterthought, and the repository carries the configuration files for both, a busted configuration and a luacov configuration.

The dependency list is where the real constraints are

Seven dependencies are listed, and two of them shape the whole design. cqueues is the first, at a version of 20161214 or newer, and the note is that cqueues currently does not support Microsoft Windows operating systems, which is a hard platform limit on the asynchronous mode. luaossl is the second, also at a dated minimum version, and it is the TLS provider, which is why the library can do HTTPS without implementing cryptography. The rest are support libraries. basexx handles base encoding, lpeg and a companion patterns module provide pattern matching, and a binary heap and a first-in first-out queue are there for the scheduling that an asynchronous client needs. The optional dependencies are separated out and they tell you what is genuinely optional. For gzip compression you need one of two compression libraries. For checking cookies against a public suffix list there is a separate module. Those two are the features most likely to be wanted and most likely to be absent by default, and both are listed as things you opt into rather than things that come along. The version floors on the base libraries are also old, which is consistent with a project whose last tagged release was in 2021.

Version-specific shims for older Lua

The compatibility section is where a Lua project earns its keep, because the differences between Lua versions are not cosmetic. If you are using a version before 5.3 you need a compatibility module at a minimum of 0.3, and if you are on 5.1 you need a bit operation library, either the one that comes with LuaJIT or a backported bit32 package, with a link to the LuaRocks listing of the latter. The reason for the 5.1 rule is that bitwise operations were added to the language in 5.3, and the network and parsing code in an HTTP library wants them. The cqueues dependency covers the operating system support for the asynchronous side, and its lack of Windows support is called out directly rather than left to be discovered. Taken together, these four lines tell you the practical matrix: Windows is out for the asynchronous features, Lua 5.1 works but needs an extra library, and versions before 5.3 need a shim for the standard library changes. The compatibility claim of supporting 5.1 through 5.4 and LuaJIT is therefore accurate, but the price of the older versions is a small set of additional modules.

Documentation generated through pandoc, and a project still being touched

The documentation is written in markdown and intended to be consumed by pandoc, with more detail in the doc directory, and the published site is generated from that. The choice of a document tool rather than a wiki is worth noting for a library with a large API surface, since a markdown source tree can be reviewed in pull requests alongside the code. The readme is a short index and the site is the reference, and the project also carries a NEWS file for the change log, a contributing document, a licence file and a coveralls badge for coverage, plus a CII Best Practices badge. The maintenance picture needs care. The three most recent tags are v0.4 from 2021-02-05, v0.3 from 2019 and v0.2 from 2017, so the released versions are old, while the last push was on 2026-10-06, which says the code is being worked on but the tags are not keeping pace. The repository publishes no GitHub releases beyond those tags, and the default branch is master. The licence file indicates the MIT licence, and the copyright and the code of conduct are in the same directory.

Editorial conclusion

lua-http is a good fit for a Lua project that needs a real HTTP stack on both sides, in particular if you need HTTP/2 or websockets, since the feature list covers both, and if you are on a pure Lua runtime where a C library would be a deployment problem. It is the wrong choice if you need only to fetch a URL, since the dependency list is long and several of the modules have their own dependencies, and it is the wrong choice on Windows, because the cqueues dependency is explicitly noted as not supporting that platform. It is also the wrong choice if you need a maintained release stream, because the most recent tag is v0.4 from 2021 even though the last push was on 2026-10-06. Before adopting it, check the dependency list against what you actually use, since gzip compression and public suffix checking are optional and pull in extra modules, and note the Lua version rules, where versions before 5.3 need a compatibility shim and 5.1 needs a bit operation library. The project is MIT licensed.

Frequently asked questions

Official sources

1. daurnimator/lua-http on GitHub
2. License: MIT
3. Project website
4. README
5. Releases