So, while the framework part of this might be modern, the server implementation is definitely not. I applaud your enthusiasm for writing a new HTTP server, but I really strongly recommend that you replace your parsing code with a proper server, or at least a proper HTTP parser.

I wouldn't recommend people use this server as-is in production for a few reasons:

1. The server is technically a HTTP/1.0 server. This is despite HTTP/1.1 having been specified in 1999.

2. Because it's a HTTP/1.0 server, it closes the TCP connection after each response. This means that each request incurs the hit of a TCP handshake and, for HTTPS, a TLS handshake. Except...

3. No TLS support, so no HTTPS.

4. The server makes some mistakes about framing, which mean that it can get out of step with the actual request/response cycle. In particular, it assumes that request bodies are only present on POST and PUT requests, even though none of the RFCs forbid them from being present on anything else. This means that an incautious client can confuse the server about where a request ends.

5. No support for line-folding in headers. This is acceptable if the server considers itself a recent HTTP/1.1 server, because line-folding got deprecated in RFC 7230, but in RFC 1945 it's still alive and well. Basically, the server doesn't support this:

    GET / HTTP/1.0
    Header: Part of the field
        Another part of the field
   

6. No support for repeated header fields. For some headers it is entirely allowed to send the same header multiple times, but albatross doesn't support it because it shoves all the headers into a dict (strictly an ImmutableCaselessDict). This is quite odd, given that there's an ImmutableMultiDict defined in the code: all you need is to create an ImmutableCaselessMultiDict and you're fine.

The point of this comment is not to dump on your work: I'm glad you've done it, and more work in this space is always better! The point is simply to highlight that, while HTTP might look simple, it's really not. There are a ton of edge cases. I didn't even get into things like chunked transfer encoding, which the server also doesn't support, because of the claimed HTTP/1.0 support of the server.

I really strongly recommend you investigate either using a complete pre-written server, or that you consider using something like h11 to handle the HTTP parsing. That will let you get great HTTP/1.1 support without needing to worry about all these nasty little edge cases yourself. (And, for what it's worth, using h11 gives you a really easy jump to supporting HTTP/2 as well as HTTP/1.1, using hyper-h2).

I'll open all of these notes as bug reports as well, so that you can keep track of them. Great work!