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 terry.reedy
Recipients martin.panter, quentel, r.david.murray, terry.reedy, v+python
Date 2017-07-20.19:08:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500577709.74.0.519749561153.issue30576@psf.upfronthosting.co.za>
In-reply-to
Content
I saw the python-ideas post.  I have no experience with http.server, but I just read the doc, and know something of our general enhancement policies.  I hope these comments help.

There are two questions: Should compression support be added to http.server?  If so, how?

To me, the purpose of the module is to provide a server and request handlers for toy, experimental, and basic production use, whether on a private or the public net.  Whatever the case was when the module was written, compression strikes me as a basic http feature now.

I agree with Martin that compression does not fit with the current definition of SimpleHTTPRequestHandler.  I suggest instead a subclass thereof.  CompressionHTTPRequestHandler?  ZippyHTTPRequestHandler?  Then add -zip to command line options.

If cgi + compression is relevant, a CompressionMixin might be posible, but I notice that there has been no suggestion so far that the combination is needed.

I suspect one motivation for adding compression to Simple... is to make it default.  I understand the desire to give users something for 'free', but changing default behavior usually breaks something somewhere and is therefore contrary to our general policy, and I definitely would not break it for this.
History
Date User Action Args
2017-07-20 19:08:29terry.reedysetrecipients: + terry.reedy, v+python, r.david.murray, quentel, martin.panter
2017-07-20 19:08:29terry.reedysetmessageid: <1500577709.74.0.519749561153.issue30576@psf.upfronthosting.co.za>
2017-07-20 19:08:29terry.reedylinkissue30576 messages
2017-07-20 19:08:29terry.reedycreate