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 martin.panter
Recipients martin.panter, quentel
Date 2017-06-05.23:22:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1496704921.93.0.412422771016.issue30576@psf.upfronthosting.co.za>
In-reply-to
Content
Why do you want to this? Encoding files on the fly seems out of scope of the SimpleHTTPRequestHandler class to me, but perhaps a more flexible API that could be plugged in by the user could be beneficial.

See xmlrpc.server.SimpleXMLRPCRequestHandler.accept_encodings and related code for an existing implementation.

Did you consider using Transfer-Encoding instead of Content-Encoding?

What do you propose to do with Content-Length? What would happen to code that uses persistent HTTP connections?

There are a few bugs open about this in the client: Issue 1508475 discusses handling compression (especially via Content-Encoding), and Issue 4733 talks about text decoding, which would depend on decoding the Content-Encoding first.
History
Date User Action Args
2017-06-05 23:22:01martin.pantersetrecipients: + martin.panter, quentel
2017-06-05 23:22:01martin.pantersetmessageid: <1496704921.93.0.412422771016.issue30576@psf.upfronthosting.co.za>
2017-06-05 23:22:01martin.panterlinkissue30576 messages
2017-06-05 23:22:01martin.pantercreate