Please don’t use pointers in Rust!

Anyways, my feedback:

Your http module just wraps another inline module, this is unnecessary. Usually inline modules are only useful for tests. Your readline implementation doesn’t account for systems with two-character line endings (Windows and DOS) and I’m also unclear on why you need that for stdin.

Concerning http in the standard library, Rust has learned from the mess in python, which has multiple implementations in the standard library that are all outdated but can’t be updated due to needing to handle backwards compatibility. Rust only has the basic stuff there, and handles other needs by external dependencies, which are managed by a great package manager (again, unlike python) on crates.io.

A few things I noticed:

• In http::request::parse(), do you actually need a BufReader? It would be better to make it generic over something implementing BufRead, that allows what you have but also makes tests and examples easier since you wouldn’t have to open a TCP connection just to do something that is essentially string parsing.
• In http::response::Response::to_string(), that match on lines 78-85 makes me uneasy, because you are silently changing the status code if it isn’t one you recognise. It would be better to signal an error. It would be even better to just check when the status code is set (perhaps with a status code enum to list the ones you support, since what you have isn’t all the defined codes) so that you can’t fail when converting to a string.
• Consider whether you need a special to_string() method at all, or whether you can just implement Display (which gives you to_string() for free via the ToString trait).
• You are using String as an error type pretty much everywhere. The better approach is to create an enum representing all the possible errors, so that a user of your library can match against them. Make the enum implement Error and Display and it will fit fine into the rest of the error handling infrastructure. There are crates like thiserror that can reduce the boilerplate around this.
• You have an io.rs that doesn’t appear to be connected to anything.
• You have a main.rs, which seems off in something that sounds like it should be purely a library crate. You probably want that to be an example or an integration test instead.

That’s all I could see with a quick look. In terms of general advice: remember to look at warnings, run cargo clippy, and look at the API guidelines.

I’m surprised that you’re surprised that there’s not http servers in the standard library

I didn’t look beyond the main parts of the HTTP moduel, but what I’ve noticed basically immediately was that your pub fn start_server(address: &str, request_handler: fn(Request) -> Response) -> io::Result<()> uses a function pointer parameter.

This is overly restrictive. fn a()->b only accepts fns, and closures that do not capture their environment (see the book’s chapter on closures). In order to accept closures that capture their environment, you could make that function generic: pub fn start_server(address: &str, request_handler: F) -> io::Result<()> where F : Fn(Request)->Response + Clone +'static.

• The Clone requirement is necessary, because you need to pass a copy of the handler to each spawned thread.
• The 'static lifetime is needed because you can’t guarantee that the thread doesn’t outlive the call to start_server.

Now, this can be improved further, because Rust offers a tool to guarantee that all threads are joined before run_server returns: Scoped Threads.

• Scoped Threads make the 'static requirement unnecessary, because the function that contains them outlives them by definition.
• In addition, the Clone requirement is not needed either, because due to the limited lifetimes, you can take request_handler by reference, and all references are Copy (which is a subtrait of Clone).

With scoped threads, a version of your function that could be generic over the request_handler could look something like this (I haven’t tried to compile this, it might be utterly wrong):

pub fn start_server(address: &str, request_handler: &F) -> io::Result&<()> where F : Fn(Request) -> Response {
    let listener = TcpListener::bind(address)?;
    std::thread::scope(move |s| -> io::Result<()>{
        for stream in listener.incoming() {
            let stream = stream?; // I think ? works here too
            s.spawn(move || {
                handle_connection(stream, &request_handler);
            });
        };
        Ok(())
    })
}

Edit: Sorry for the messed up characters. & should of course just be the ampersand character, and < should just be the less-than character.