Description
It'd be useful to automatically, by default, compress content for HTTP.Response ; this ticket is the opposite of #256 and complementary to #653 -- gzipping content could be done as part of the rendering process as the send buffer is filled (avoiding a literal copy of the user data). As the content is printed to an IO stream, it can be gzipped, and once the buffer is full, a chunked response could be sent for streams that exceed the buffer length.
One of the challenges here is having a bypass for static content that is already compressed; for example, many resource bundles precompress their output so that you don't have to do it at runtime.
In a WSGI like stack, this is implemented as a Response proxy. Basically, it's a wrapper that, when you print the headers looks to see if Transfer-Encoding is already set, if so, it is a no-op. A FileResponse object would notice that the file being served may have a gzip extension and start with the gzip chararaters and set the headers appropriately. The GzipResponse would then use the body of the wrapped response, reading or printing it, and gzipping the results. There are some advantages of being a proxy, but, it's not a necessary requirement for the design it could be built-in as a flag of some sort.