use chunked encoding for streaming responses with HTTP/1.1

[rawler]

This approach differs a bit from the approach in PR#1328, in that it is completely contained in the server without any change in the application. (As per RFC, no reliance on hop-by-hop headers). It is triggered if HTTP/1.1 is configured (such as by specifying a subclass of request_handler), at which point Connection: close behavior is always replaced with Transfer-Encoding: chunked. The rationale is that any spec-compliant HTTP client must support this, so it should not cause any unjustifiable regressions for clients. From what I've seen, this seems to also match behavior in other WSGI-servers to ensure the apps behave consistently across test/prod.

• fixes Add support for chunked responses on test server #1327
• fixes Chunked response support for werkzeug.serving #2090
• previous attempt: Adds automatic chunking and (basic) output content filtering API #1328

Checklist:

• Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• Add or update relevant docs, in the docs folder and in code.
• Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• Add .. versionchanged:: entries in any relevant code docs.
• Run pre-commit hooks and fix any issues.
• Run pytest and tox, no tests failed.

[rawler]

I'm not sure if there are any docs that needs to change as an effect of this. If so, I need a pointer to the right place.

[davidism]

While playing around with this and making HTTP/1.1 the default, I've noticed that the debugger page can be inconsistent about loading all the resources when in HTTP/1.1 keep-alive mode, every 3 reloads or so it gets stuck loading the font file. As soon as I go back to HTTP/1.0 mode, where every connection is always closed after a single request, everything loads. Or if I enable the threaded server, everything loads.

This did lead me to notice that the debugger could use send_file and set etags for the resource files, and once they're cached there's no issues with the page load. Additionally, the initial debugger page could be modified to return the content-length header so it didn't act like a streaming response for no reason.

In my own projects I've been leaning towards using Gunicorn or another WSGI server in development since it just generally supports more features than the Werkzeug dev server ever will. You can even enable Werkzeug's debugger, here's an example with Flask:

from flask import Flask
from werkzeug.debug import DebuggedApplication

app = Flask(__name__)

if app.env == "development":
    app.wsgi_app = DebuggedApplication(app, evalex=True)

$ export FLASK_ENV=development
$ gunicorn -b localhost:5000 --reload example:app

[davidism]

OK, after a bit more experimenting, I think it's safe to enable HTTP/1.1 if threaded or processes is used.

[davidism]

I changed

if self.server.passthrough_errors or (status_sent and chunk_response):
    raise

to

if self.server.passthrough_errors:
    raise

if status_sent is not None and chunk_response:
    self.close_connection = True

So that the dev server's traceback logging is used instead of raising the error up to the base server.