Pierre Quentel added the comment:
Thanks for the comments. I agree with some of them, and have improved the PR
accordingly, but I don't agree on the opinion that HTTP compression is beyond
the scope of http.server : like browser cache (which also implies a negociation
between client and server) it's a basic, normalized feature of HTTP servers ;
it doesn't change the intention of "mapping requests to the directory
structure", it just changes the way some files are served, improving transfer
speed and network load, which is especially useful on mobile networks.
The implementation makes HTTP compression the default for the types defined in
SimpleHTTPRequestHandler.compressed_types, but it can be disabled if the system
can't handle it, like in the case you mention : just by setting
compressed_types to the empty list. I have made it more clear in the
documentation.
I understand the concern for HEAD requests, but they must return the same
headers as GET, so the compression must be done to determine the content-length
header.
To address the case when the tmp zone is limited, I have also added a
try/except block that checks if the temporary gzipped file can be created ; if
not, the file is returned uncompressed.
I don't understand Martin's suggestion to use HTTP compression for .gz files :
they are already compressed, there wouldn't be any benefit to compress them
again. It's the same for audio or video files. Compression is only useful for
uncompressed data such as text files, scripts, css files, etc. that are not
already compressed. All those files are sent unmodified and with their own
content type.
I have also improved the PR for the alternative forms of Accept-Encoding
("gzip;q=0", "*", "GZIP", etc.).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30576>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
