may_minihttp: a mini HTTP server on the may runtime, ported from tokio_minihttp

A port of tokio_minihttp onto the may runtime

may_minihttp is described in one line as a mini HTTP server that is implemented on top of may, and the README is explicit about its lineage: the crate is ported from tokio_minihttp. What the port changes is stated just as plainly. The README says it comes with much ease of use, and that you can call MAY block APIs directly in your service.

That is the whole value proposition, and it is a runtime-level one rather than an HTTP-level one. may_minihttp keeps the small surface that tokio_minihttp established, where a service is a type implementing a call method that receives a request and writes into a response, and moves it onto may, the coroutine based async runtime the same author maintains. A handler that needs to do blocking work, such as a database call or a file operation, can reach may's block APIs from inside the handler instead of pushing that work onto a separate thread pool.

The crate is written in Rust, edition 2021, and the Cargo.toml records version 0.1.11 with the author as Xudong Huang. The repository carries no published GitHub releases, so the crate version in the manifest is the version you get, and the docs are on docs.rs under the same name. The description field still points at the may repository, and the keyword list is http, server and may, which is a fair summary of a small focused crate.

The service trait: call, request, response

The API is small enough to read in one sitting. A service is a type that implements HttpService, and the trait method takes a request by value and a mutable response reference, returning an io::Result. The handler writes into the response and returns Ok. The server is then constructed from the service and started on an address, after which join blocks on it.

The core of the example in the README looks like this:

extern crate may_minihttp;

use std::io;
use may_minihttp::{HttpServer, HttpService, Request, Response};

#[derive(Clone)]
struct HelloWorld;

impl HttpService for HelloWorld {
    fn call(&mut self, _req: Request, res: &mut Response) -> io::Result<()> {
        res.body("Hello, world!");
        Ok(())
    }
}

Two details are worth naming. The service type is Clone, and the derive is on the example, which suggests the framework requires a cloneable service value. And the handler takes the request by value but does not have to read it, so the underscore on the parameter is not a style choice but a way of saying this particular handler ignores the request entirely.

Because the trait has a single method, the surface a user has to learn is small. That is the point of a mini server, and it is also its limit: there is no routing layer, no middleware chain and no extractors in the shape the larger Rust web frameworks provide. A service here is a flat switch on whatever the request contains.

Adding the crate and starting a server that binds a port

Usage is two steps. The dependency goes into Cargo.toml:

[dependencies]
may_minihttp = "0.1"

And the service is implemented and started. The README's example finishes with the server construction and the join that keeps the process alive:

    let server = HttpServer(HelloWorld).start("0.0.0.0:8080").unwrap();
    server.join().unwrap();

The address is the only configuration the example touches, and it binds all interfaces on port 8080. The start call returns a result that the example unwraps, and join returns a result as well, so a bind failure surfaces as a panic rather than as a graceful message. That is the shape of a minimal example rather than a policy, but it does mean a reader copying it verbatim will get a panic instead of a diagnostic when the port is taken.

The repository has a docker/ directory and a templates/ directory alongside src/, examples/, tests/ and a .dockerignore, so there is a container path and a template mechanism in the tree. The example files are named for what they exercise: headers.rs, hello-world.rs, hello.rs, json.rs, post.rs, status.rs, techempower.rs and techempower_no_db.rs.

The performance section compares against the crate it was ported from

The README's performance numbers are framed as a comparison between the original and the port, and the framing matters when you read them. The setup is stated first: tested with only one working thread on the author's laptop, with the server started by a single command.

$ cargo run --example=hello-world --release

The load is generated with wrk against the same address, one thread and 200 connections over a ten second window:

$ wrk http://127.0.0.1:8080 -d 10 -t 1 -c 200

The README reports that the tokio_minihttp run produced 100650.94 requests per second with a 1.98ms average latency, while the may_minihttp run produced 116181.73 requests per second with a 1.70ms average latency. Read those as the author's own comparison on one laptop with one thread, not as a general ranking. The output shown is a wrk transcript rather than a controlled benchmark harness, the hardware is not identified beyond being a laptop, and no attempt is made to isolate which change produced the difference.

The Benchmarks section makes a separate claim, that the project is one of the fastest web frameworks available according to the TechEmpower Framework Benchmark. That is a reference to an external results page rather than a measurement made here, and the crate's own examples directory includes techempower.rs and techempower_no_db.rs, so the project carries the benchmark workloads itself. The Cargo.toml also pulls in goose and testcontainers as dev dependencies for load testing and integration testing.

Where may_minihttp is the wrong tool

The scope is a mini server, and several common needs sit outside it. There is no router, so path dispatch is your problem, and there is no extractor or middleware mechanism, so anything you build on top is code you own and maintain. If your service has a dozen endpoints, you will end up writing the dispatch layer yourself and the dependency is doing less for you than its name suggests.

There is also no TLS termination in the crate and no HTTP/2 support, which means it cannot serve a public endpoint on its own. For a service behind a reverse proxy that terminates TLS, that is fine and is presumably the intended shape. For anything internet facing, something else has to be in front.

The version line is the other limit. The crate sits at 0.1.11 with no GitHub releases published, and the dependency line in the README is may_minihttp = "0.1", which is a caret requirement that allows any 0.1.x. A crate with no tagged releases and a 0.1 version gives you no compatibility promise between upgrades. The Cargo.toml also pins the may runtime to version 0.3.46 with default-features = false, and the crate's own default feature is may/default, so the feature set you get depends on which of those two you rely on.

Finally, the comparison in the README is against tokio_minihttp, a project with a different runtime underneath. The difference the author is selling is convenience inside a may service, not raw speed, and if you are not already on may that convenience is not available to you.

Dual licensing, an active repository and a single author

The licence setup is the more permissive of the two options in the file, and the README states it as a choice. The project is licensed under either of the Apache License, Version 2.0, referenced through the LICENSE-APACHE file, or the MIT license, referenced through LICENSE-MIT, at your option. The Cargo.toml records the same pair as license = "MIT/Apache-2.0". For a company with a policy that prefers one licence over the other, the choice is available at adoption time, which is a small convenience worth noting.

On maintenance, the last push was on 2026-10-15, so the repository is receiving commits, and it is not archived. The release history section is the weak point: there are no GitHub releases at all, so there is no tag to pin, no release notes to read before an upgrade, and no changelog in the top level entries beyond the CHANGELOG that is not present. The Cargo.toml has a commented out patch section pointing at a local path for the may dependency, which is the sort of thing a single author leaves in place to work across two checkouts.

Everything here points to a well maintained but very small project. The author maintains the may runtime as well, the examples cover the cases a new user will hit first, and the dev dependencies include a real load testing stack. The risk you carry is not that the project stops, it is that the API moves while you are still on 0.1.

Editorial conclusion

may_minihttp suits Rust developers who want the tiny, predictable shape of the tokio_minihttp API but need to run inside a may based service and call may's block APIs without crossing an await boundary. It is a poor fit if you need TLS termination, HTTP/2, a router, or an API that will not change under you, because the crate is at version 0.1.11 with no published releases and no compatibility promise. Verify first that the tokio_minihttp behaviour you rely on is present in this port, since the README frames it as a port with added ease of use rather than a feature complete rewrite, and check the examples directory, which lists separate files for headers, json, post, status and the techempower benchmarks.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Xudong-Huang/may_minihttp on GitHub