Crystal 1.21.1 stops its HTTP server from decompressing request bodies
Serguey Asael Shinder2 min readCrystal 1.21.1 was released on 26 September. It is a patch release, but three of its entries are tagged as security fixes, and all three sit in the standard library's HTTP server - the code that runs when a Crystal application listens for requests without a framework in front of it.
The first stops the server from automatically decompressing HTTP request bodies (#17476). The second makes HTTP::Request::Processor stop resuming a keep-alive connection when the previous request's body was never consumed (#17434). The third makes HTTP::Server::RequestProcessor consume the request body before a connection is upgraded, for example to a WebSocket (#17466). The release notes do not describe attack scenarios; the pull requests are linked from the notes.
The rest is ordinary maintenance: Channel#tap(&) is overridden to restore its original behaviour after a regression, non-blocking Socket#connect on Unix is fixed, XML::Node#namespace handles node types without a namespace, and YAML::Any#hash no longer fails on self-referencing containers.
What it means
The three fixes share a theme that shows up in HTTP servers of every language: what happens to the bytes of a request that the application did not read. If a handler returns early, the leftover body is still on the connection, and a server that simply carries on reading may interpret those bytes as the start of the next request. Upgrading a connection has the same problem in a different place. Draining or discarding the body before continuing is the defensive answer, and it is what these changes do.
Automatic decompression is the other half. A server that inflates request bodies on its own spends memory and CPU on data the application may never ask for, and a small compressed body can expand into a very large one. Making decompression something the application chooses puts that decision back where the limits are known. Anyone running Crystal's built-in server directly should take the patch; applications that relied on transparent decompression will need to handle compressed bodies themselves.