classification
Title: Remove HTTP 0.9 server support
Type: behavior Stage: patch review
Components: Library (Lib) Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Lukasa, barry, eric.araujo, giampaolo.rodola, icordasc, jhylton, loewis, martin.panter, orsenthil, pitrou, rhettinger, stutzbach
Priority: normal Keywords: patch

Created on 2010-12-16 18:21 by pitrou, last changed 2016-11-24 03:10 by martin.panter.

Files
File name Uploaded Description Edit
http09server.patch pitrou, 2010-12-16 18:21 review
http09server.v2.patch martin.panter, 2016-08-10 07:16 review
http09server.v3.patch martin.panter, 2016-10-29 01:09 review
http09server.v4.patch martin.panter, 2016-11-24 03:10 review
Messages (13)
msg124145 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-12-16 18:21
http.server has support for old-style HTTP 0.9 requests ("command path" without a version string). This issue proposes to remove this support, since there are probably no clients around which still issue such requests.

See issue10711 for the client side.
msg124149 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-16 18:49
LGTM
msg124166 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-17 00:15
The question really is whether we want or want not to support RFC 1945 (i.e HTTP/1.0). If we want to support it, we also must comply to section 3.1, which says

 The version of an HTTP message is indicated by an HTTP-Version field
 in the first line of the message. If the protocol version is not
 specified, the recipient must assume that the message is in the
 simple HTTP/0.9 format.

If we then choose to not support HTTP/0.9 (after recognizing that the message is HTTP/0.9), we must then reject the request. According to RFC 2145, we then may send back error 505 (HTTP version not supported).
msg124184 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-12-17 05:05
If a client sends a request without specifying the version, GET /, then the Python server should behave like other common servers are behaving, namely support rfc 1945 for HTTP 1.0 spec and return the response without headers.

Removing the HTTP 0.9 from the http.client is okay. But punishing *any client* for not sending the correct request is not so desirable, especially when there are other servers which are lenient to his behavior for whatever reasons.

So, I am not a firm +1 to this. We should arrive a conclusion and then go about with the change. Martin's point is valid here too.
msg221636 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-26 19:34
How, if at all, has the requirement for HTTP 0.9 support changed since this issue was first raised?
msg221637 - (view) Author: Cory Benfield (Lukasa) * Date: 2014-06-26 19:38
To answer your question, Mark, RFC 7230 has removed the expectation that HTTP/1.1 servers will be able to support HTTP/0.9 requests.
msg261962 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-03-18 10:36
Does this need any deprecation cycle, or can we just remove everything immediately in 3.6?

I suspect that the HTTP 0.9 support never properly worked, but I don’t have enough info to be sure. Wouldn’t a HTTP 0.9 request send b"GET <path>\r\n" with a single line, and then wait for a response? If so, Python’s server hangs waiting for a second blank line (or EOF), so the protocol will deadlock.

In any case, I would be in favour of removing HTTP 0.9 support. Senthil: do you know of actual clients that do HTTP 0.9 requests?

I left a review comment. The patch will also need manual merging with current code.
msg261963 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-03-18 10:37
Also I guess documentation should be added somewhere, even if there is no deprecation step.
msg272320 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-08-10 07:16
FWIW I doubt HTTP 1.1 ever required support for other HTTP versions; see for instance <https://tools.ietf.org/html/rfc2068#section-19.7>.

This v2 patch adds another test that includes what I understand is a true HTTP 0.9 request (although the mock connection infrastructure closes the connection before receiving the response, so you don’t see any deadlock). This is based on <https://tools.ietf.org/html/rfc1945#page-22>, which includes only one CRLF newline. I also added an entry to the What’s New page.
msg272410 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-08-11 07:33
There is so very little code in support of HTTP/0.9 that I don't think we get any benefit from removing it.  So why bother with the churn?  It is cleaner to just leave it place.
msg272435 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-08-11 10:31
There are a few small benefits from removing it, but I am not too fussed if we decide to leave it.

* If we keep it, should we fix it so that it doesn’t deadlock? Otherwise, we carry around buggy and untested code that claims to be a HTTP 0.9 server but isn’t. Keeping it as it is doesn’t feel “clean” to me.

* Easy way to resolve bug reports like Issue 26578.

* Potentially slightly easier to maintain the rest of the code in the future.

If we do keep it, I would like to add comments clarifying that it does not implement the real HTTP 0.9 protocol.
msg279643 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-10-29 01:09
Here is a slightly updated patch I have been sitting on. I think the main difference was tweaks to the documentation.

Issue 28548 would also benefit if the HTTP 0.9 code was removed. The presence of the HTTP 0.9 code means a suboptimal response is sent in some error cases. IMO it would be better if the server responded using HTTP 1.0, where we can use error codes like “400 Bad request”. The current code will not use HTTP 1.0 unless it sees that the client supports it.
msg281601 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-11-24 03:10
V4 patch adjusting to recent code change.

Raymond: Given the problems caused by the current code, would you reconsider your opposition?

Otherwise, what do you think should be the future of the code? Should we fix it so that it handles real HTTP 0.9 requests, or just admit that it doesn’t implement the protocol properly.
History
Date User Action Args
2016-11-24 03:10:59martin.pantersetfiles: + http09server.v4.patch

messages: + msg281601
2016-10-29 01:09:15martin.pantersetfiles: + http09server.v3.patch

messages: + msg279643
versions: + Python 3.7, - Python 3.6
2016-10-28 22:59:01barrysetnosy: + barry
2016-08-11 10:31:37martin.pantersetmessages: + msg272435
2016-08-11 10:20:26martin.panterlinkissue26578 dependencies
2016-08-11 07:33:01rhettingersetnosy: + rhettinger
messages: + msg272410
2016-08-10 07:16:30martin.pantersetfiles: + http09server.v2.patch

messages: + msg272320
2016-08-07 16:16:34gregory.p.smithsetnosy: - gregory.p.smith
2016-03-18 15:09:22BreamoreBoysetnosy: - BreamoreBoy
2016-03-18 10:37:46martin.pantersetmessages: + msg261963
2016-03-18 10:36:52martin.pantersetnosy: + martin.panter

messages: + msg261962
versions: + Python 3.6, - Python 3.4, Python 3.5
2014-06-27 11:04:35exarkunsetnosy: - exarkun
2014-06-26 19:38:41Lukasasetnosy: + Lukasa
messages: + msg221637
2014-06-26 19:37:15icordascsetnosy: + icordasc
2014-06-26 19:34:54BreamoreBoysetnosy: + BreamoreBoy

messages: + msg221636
versions: + Python 3.4, Python 3.5, - Python 3.2
2010-12-17 05:05:53orsenthilsetnosy: loewis, jhylton, gregory.p.smith, exarkun, orsenthil, pitrou, giampaolo.rodola, stutzbach, eric.araujo
messages: + msg124184
2010-12-17 00:15:32loewissetnosy: + loewis
messages: + msg124166
2010-12-16 18:49:26eric.araujosetnosy: + eric.araujo
messages: + msg124149
2010-12-16 18:21:42pitroucreate