On 5/21/2019 11:15 AM, Christian Heimes wrote:
On 21/05/2019 18.29, Glenn Linderman wrote:
On 5/20/2019 2:20 PM, Christian Heimes wrote:
On 20/05/2019 23.12, Andrew Svetlov wrote:
socketserver.py is also questionable
I briefly though about the module, but didn't consider it for removal. The
http.server, xmlrpc.server, and logging configuration server are implemented on
top of the socketserver. I don't want to remove the socketserver module without
a suitable replacement for http.server in the standard library.
But http.server could be on the remove list too... it gets mighty little
support, has very little functionality, and implements a CGI interface
(although that also has very little functionality), and you have the CGI tools
on the remove list, rendering the CGI interface implemented by http.server less
easily usable.
Further, it doesn't directly support https:, and browsers are removing/reducing
support for http:.
I can't speak to xmlrpc or logging configuration.
Hi,
thanks for bringing this topic up. Initially I considered http.server, too. But
as Guido put it, it's both used and useful for local testing and quick hacks.
I'm already facing opposition for modules that are less controversial and
useful than http.server, too.
Indeed. That's why they were created in the first place (http.server,
and those other modules). But these days there are better alternatives.
That's the point of the PEP, if I understand correctly... get rid of the
junkware, point to the betterware, and avoid the need to learn the
betterware later, because you wasted time and effort using the junkware
at first, because it was "included".
I have two remarks:
1) The http.server does not act as a CGI server by default. In CGI server mode,
it does not depend on the cgi module.
CGIHTTPRequestHandler is part of the package. While it does not depend
on the cgi module, its existence encourages the users to search for,
find, and use the cgi and cgitb modules when using
CGIHTTPRequestHandler. I certainly did in past projects, prior to
finding bottle.py.
2) The lack of HTTPS support is not a major problem for connections on localhost. There
is a RFC draft to consider any connection to "localhost" as secure,
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06
Which certainly didn't exist when Chrome (noting the author's
organization) and other browsers first started implementing feature
restrictions for http, and while I haven't tested this since the RFC you
mention was published, it was certainly a difficulty I faced when
attempting to use features with security restrictions for local testing
a couple years ago.
Christian
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
