use a printable object and/or io stream for HTTP.Response body

[clarkevans]

The design of HTTP.Response is a bit inflexible in that it requires applications to render their data to a byte-stream. Presumably this was the 1st pass in the design to get this library working, however, perhaps it shouldn't be the final design.

I was expecting a design to be more flexible with regard to the content body. For example, the library could read from the byte-stream or print from an object into a buffer. If the response body is done before the buffer is full, then the Content-Length is known and it could be sent. Otherwise, HTTP could use chunked encoding and send the first chunk, filling up the buffer again, and so-on. This is the sort of design used by Python's WSGI protocol.

[clarkevans]

@quinnj What is the appetite for fixing this? We could make Response{T} where T is the type of the object that can write its content to the IOStream. If I packaged up a pull request, would this even be considered?

[clarkevans]

Note that due to this implementation, the benchmark at https://github.com/aj-monk/C10k.jl copies the file being served, on each request, into in-memory bytes object, rather than directly using sendfile (optimized web application deployments would already have the files on disk sent already gzip compressed).

[quinnj]

The HTTP.Response struct is now parameterized on the body field and is better suited for the request here. (currently only on master, coming soon in 1.0 release).