<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#330033" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 5/21/2019 11:15 AM, Christian Heimes
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:66dc8643-6c91-ac1f-6ff8-ebce4de39a5b@python.org">
      <pre class="moz-quote-pre" wrap="">On 21/05/2019 18.29, Glenn Linderman wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On 5/20/2019 2:20 PM, Christian Heimes wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">On 20/05/2019 23.12, Andrew Svetlov wrote:
</pre>
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">socketserver.py is also questionable
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">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.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
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.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
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. </pre>
    </blockquote>
    <br>
    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".<br>
    <br>
    <blockquote type="cite"
      cite="mid:66dc8643-6c91-ac1f-6ff8-ebce4de39a5b@python.org">
      <pre class="moz-quote-pre" wrap="">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.</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite"
      cite="mid:66dc8643-6c91-ac1f-6ff8-ebce4de39a5b@python.org">
      <pre class="moz-quote-pre" wrap="">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, <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06">https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06</a></pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite"
      cite="mid:66dc8643-6c91-ac1f-6ff8-ebce4de39a5b@python.org">
      <pre class="moz-quote-pre" wrap="">Christian
</pre>
    </blockquote>
    <br>
  </body>
</html>