While the examples in this post are in Dylan and are using code from our HTTP server, these issues exist in HTTP frameworks in other languages. The code should be clear enough that little to no Dylan knowledge is required to understand the points being made here.
What does this have to do with HTTP? There are several pain points in our HTTP stack as it is currently written:
- Requests are read in their entirety into memory, so a large request (such as a file upload) takes a significant amount of memory.
- Responses often buffer their entire output in memory as well.
- Because of the use of the existing streams library, we don't handle non-blocking sockets and require a thread per socket.
- We don't have a good model for handling long-lasting connections such as might be used with Server Sent Events or WebSockets without tying up a thread for the duration of the socket being open.
We don't know yet what the new streams API will look like, but we can look at our ...read more »
There are comments.