put http.server on a diet

[vpython]

BPO	37018

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-05-23.05:22:46.131>
labels = []
title = 'put http.server on a diet'
updated_at = <Date 2019-05-23.05:22:46.131>
user = 'https://bugs.python.org/vpython'

bugs.python.org fields:

activity = <Date 2019-05-23.05:22:46.131>
actor = 'v+python'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2019-05-23.05:22:46.131>
creator = 'v+python'
dependencies = []
files = []
hgrepos = []
issue_num = 37018
keywords = []
message_count = 1.0
messages = ['343275']
nosy_count = 1.0
nosy_names = ['v+python']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue37018'
versions = []

[vpython]

The idea inspired by the email exchange below is basically in three parts:

1. investigate the various popular web server frameworks, to determine what parts of http.server they depend on. For example, bottle.py depends only on BaseHTTPRequestHandler and HTTPServer, which is less than half the code in http.server. Because of the deficiencies in the remaining parts, it seems unlikely that other frameworks use much more.

2. Trim http.server to those useful parts, removing the the rest from stdlib. Many of the "enhanced features" of http.server are such minimal enhancements that they are feature-poor and out-of-date with respect to current web server standards. The novice user is likely to be enticed into a swamp of missing capability when attempting to use them, as I was. It would take significant work to implement true CGI together with SSL on forking OSes; it took me significant work to implement true CGI together with SSL on Windows (non-forking). I gave up trying to do it on Linux, and switched to bottle.

3. Enhance what is left of http.server to support SSL and threading, so that the web frameworks that use http.server as a test server can at least offer those capabilities as well. It isn't too hard to add those things for bottle.py, but it would be nicer if users didn't have to google for the blog posts that show how, and reimplement it (most of the blog posts are somewhat dated).

On 5/22/2019 4:09 AM, Christian Heimes wrote:
> On 22/05/2019 01.11, Glenn Linderman wrote:
>> On 5/21/2019 2:00 PM, Nathaniel Smith wrote:
>>> On Tue, May 21, 2019 at 10:43 AM Glenn Linderman <v+python@g.nevcal.com> wrote:
>>>> After maintaining my own version of http.server to fix or workaround some of its deficiencies for some years, I discovered bottle.py. It has far more capability, is far better documented, and is just as quick to deploy. While I haven't yet converted all past projects to use bottle.py, it will likely happen in time, unless something even simpler to use is discovered, although I can hardly imagine that happening.
>>> bottle.py uses http.server for its local development mode (the one you
>>> see in their quickstart example at the top of their README). Same with
>>> flask, django, and probably a bunch of other frameworks. It's *very*
>>> widely used.
>>>
>>> -n
>>>
>> The source for bottle.py version 0.13-dev has an import for http.client, but not http.server. I hadn't tracked down every indirect dependency in the bottle.py source code, but it seems that if one uses the "default server" for bottle, that it is "wsgiref", imported from wsgiref.simple_server, and that in turn does import BaseHTTPRequestHandler and HTTPServer from http.server.
>>
>> It is the higher-level code in http.server that has significant deficiencies that have caused me problems over the years... a "SimpleHTTPRequestHandler" that is so simple it doesn't do POST, PUT or PASTE, a "CGIHTTPRequestHandler" that only implements part of the CGI protocol, only CGI support in POST, no support for PUT or PASTE, and no support for https, and not much bug fix activity in those areas.
>>
>> Maybe http.server should be split into the "basic parts" (used by bottle.py, and other frameworks), and the "higher-level parts", which could then be discarded by this PEP! At this point, though, I'd have to agree that the whole should not be discarded. Thanks for making me dig deeper.
>
> The idea has merrit. However I feel its out of scope for the PEP [594]. The http.server module and socketserver module are still widely used for debug and toy examples.
>
> Could you please open a bug to track your proposal? We may pursue it in a couple of years from now.