Requests and responses should be stateless #12
Description
Currently, when making a request or sending a response, the objects that represent them are just plain old javascript objects so any function that are given a reference to them will be able to modify their state. This can lead to subtle and difficult to catch foot/gun situations, such as rouge middleware modifying a request object after having called next, thereby bypassing the contract of middleware executing in a particular order. Another example might be a response handler mutating the body of a response long after the response has been sent.
To fix this, request and response objects should be immutable, in the sense that any change to them yields a new object with the changes. This will surely have some impact on memory, but can be made to be efficient. Crucially, it would be worth looking into using something like immutable-js or other space efficient immutable data structures.
More over, using such data structures will enable some improved debugging capabilities (see: #6,) such as inspecting request/response changes along the chain of events.
Immutable data structures alone are not enough however; indeed any value that can be set to such a structure must be immutable. Thus, a response body couldn't be a function, which by definition closes over its environment and therefor will have the ability to mutate state when and where it shouldn't. Somehow, requests and responses should be serialized in a way that such things aren't possible. Less rope to hang oneself with is always a good thing.