This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients martin.panter, matrixise, orsenthil
Date 2015-11-06.02:30:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1446777037.95.0.451230134901.issue21224@psf.upfronthosting.co.za>
In-reply-to
Content
What are the advantages of changing the default? Just that the user no longer has to set it manually?

What do you think of the problem mentioned in the documentation? If an existing HTTP 1.0 server that works fine in Python 3.5 were to suddenly have protocol_version="HTTP/1.1" forced by default, it sounds like all its responses may stop working (hang from the client’s POV) if they don’t explicitly close the connection.

One option could be to wrap the “wfile” stream in a chunk encoder, and insert Transfer-Encoding: chunked. I haven’t thought through this much, and it may not work very well because Python’s HTTP server is so low-level. This would basically be a HTTP 1.1 to HTTP 1.0 proxy.

Similarly, I understand HTTP 1.1 requires chunked encoding support for requests, but there is no support for that in the Python implementation. Existing servers accepting e.g. POST uploads would expect a Content-Length header, which would be hard to fake with a compatibility proxy (may need to buffer it all to count the bytes).

Another way might be a deprecation cycle, to force people using 3.6 to set protocol_version.
History
Date User Action Args
2015-11-06 02:30:37martin.pantersetrecipients: + martin.panter, orsenthil, matrixise
2015-11-06 02:30:37martin.pantersetmessageid: <1446777037.95.0.451230134901.issue21224@psf.upfronthosting.co.za>
2015-11-06 02:30:37martin.panterlinkissue21224 messages
2015-11-06 02:30:36martin.pantercreate