firecracker-microvm / micro-http

A minimal HTTP implementation used by Firecracker

micro-http

This is a minimal implementation of the HTTP/1.0 and HTTP/1.1 protocols. This HTTP implementation is stateless thus it does not support chunking or compression.

The micro-http implementation is used in production by Firecracker.

As micro-http uses std::os::unix this crates only supports Unix-like targets.

Contributing

To contribute to micro-http, checkout the contribution guidelines.

Releases

New micro-http versions are released via the GitHub repository releases page. A history of changes is recorded in our changelog.

Policy for Security Disclosures

If you suspect you have uncovered a vulnerability, contact us privately, as outlined in our security policy document; we will immediately prioritize your disclosure.

micro-http's Issues

Add Continuous Integration

We can start with something simple:

• running the unit tests
• build
• fmt
• clippy
• anything else?

Add license & copyright

error[E0432]: unresolved import vmm_sys_util::sock_ctrl_msg

error[E0432]: unresolved import `vmm_sys_util::sock_ctrl_msg`
  --> /usr/ports/emulators/firecracker/work/micro-http-4b18a043e997da5b5f679e3defc279fec908753e/src/connection.rs:16:19
   |
16 | use vmm_sys_util::sock_ctrl_msg::ScmSocket;
   |                   ^^^^^^^^^^^^^ could not find `sock_ctrl_msg` in `vmm_sys_util`

error[E0432]: unresolved import `vmm_sys_util::sock_ctrl_msg`
  --> /usr/ports/emulators/firecracker/work/micro-http-4b18a043e997da5b5f679e3defc279fec908753e/src/server.rs:15:19
   |
15 | use vmm_sys_util::sock_ctrl_msg::ScmSocket;
   |                   ^^^^^^^^^^^^^ could not find `sock_ctrl_msg` in `vmm_sys_util`

error[E0432]: unresolved import `vmm_sys_util::epoll`
  --> /usr/ports/emulators/firecracker/work/micro-http-4b18a043e997da5b5f679e3defc279fec908753e/src/server.rs:17:5
   |
17 | use vmm_sys_util::epoll;
   |     ^^^^^^^^^^^^^^^^^^^ no `epoll` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `micro_http` due to 3 previous errors

rust-1.66.0

Add integration test to validate we fully support "Connection: keep-alive".

The test should send multiple successful HTTP requests on the same connection and validate the API server does not close connection even for error responses.

The HTTP Delete method is needed to support device hot-removal

The HTTP Delete method is needed to support device hot-removal by using a restful style API, otherwise we need to use PUT to emulate a DELETE operation.

Does mciro-http support Uri query part?

For example,

abc://username:[email protected]:123/path/data?key=value&key2=value2#fragid1
                                                  |-------------------|
                                                            |
                                                          query

I tried to fill URI with query part, but it responded with 404.

HTTP HEAD and POST methods are needed to support RESTful API

In general, we need to use these HTTP methods to support RESTful style API:

GET -> Get Resource
HEAD -> Get Resource Metadata
POST -> Create Resource
PUT -> Update Whole Resource
DELETE -> Delete Resource
PATCH -> Update Part Of Resource

micro-http still lacks POST and HEAD after #13 .

Add status code 503(SERVICE UNAVAILABLE)

Http server is not absolutely capable to fulfill requests all the time. When it can't, it's better to respond code 503 to http client, which is more suggestive.

Publish micro_http to crates.io

@jiangliu and @sameo were asking/suggesting to publish our micro_http implementation to crates.io.
I am opening this issue to discuss if this is something that we want to do. I don't believe that rust-vmm is the appropriate organization for this crate as the micro_http is not really related to VMMs, so we will need to be hosting it in some other place.

CC: @firecracker-microvm/compute-capsule

Receive ancillary data

At the moment, there's no support for any out-of-band mechanism in order to send ancillary data along with an HTTP request. The need for this feature is to be able to send file descriptors over the socket to the VMM process, allowing these file descriptors to be associated with a particular request.

In the Cloud Hypervisor context, we want to let the user provide a list of TAP file descriptors, which could be sent along with the HTTP request add-net, while the VMM might already be running.

The proper way to achieve this would be to rely on the ancillary data mechanism once it is accepted in Rust stable, and leverage it directly from the UnixStream object. This is still a nightly feature, but I wanted to touch base on this topic to anticipate the discussion.

If we can agree it would be nice to have the micro_http support ancillary data, that means that any request could now contains a list of file descriptors associated with it. Do you think this is acceptable for the crate?

HTTP Pipelining

Does micro-http handle HTTP/1.1 pipelining? At a first glance it seems so from the VecDeque of requests and responses, but I could not tell for sure.

Pull changes from Firecracker

We haven't yet switched to micro-http in Firecracker and there are a few commits added to the micro-http in Firecracker since this repository was created. We need to also port the changes here.