Streaming HTTP handler

[zaphoyd]

While the non-blocking HTTP handler (#425) introduced in 0.6.0 addresses a number of the usability and performance issues with the HTTP handler, it does not address the case of needing to fully buffer HTTP responses before sending. In addition, reverse proxy functionality would also require this ability.

This issue will track an API feature that would allow streaming HTTP responses.

[zlpinson]

how to understand “This issue will track an API feature that would allow streaming HTTP responses.”？

[kim366]

Does "streaming" in this case mean HTTP responses that are not available in full at time of sending? Something like

defer()
send_headers()
append_body("Hello, ")
send_body_part()
append_body("world!")
send_body_part()
close()

Or is this functionality already available?

Thanks!

[zaphoyd]

Does "streaming" in this case mean HTTP responses that are not available in full at time of sending? Something like

defer()
send_headers()
append_body("Hello, ")
send_body_part()
append_body("world!")
send_body_part()
close()

Or is this functionality already available?

Thanks!

That is correct. The existing API for returning HTTP responses takes a string for the body, which needs to be fully loaded in memory before beginning to send.