5 ms·

This doesn't make any sense to me. And I've written a Go reverse proxy server https://github.com/carlmjohnson/simple-reverse-proxy https://github.com/carlmjohns

This doesn't make any sense to me. And I've written a Go reverse proxy server https://github.com/carlmjohnson/simple-reverse-proxy https://github.com/carlmjohnson/simple-reverse-proxy . Python's SimpleHTTPServer is for when you have some directory on your computer and you want to test it locally in the browser. That's all. So, there's no reason to use GZIP or HTTP2 with a SimpleHTTPServer replacement. If you need those features, it's because you're doing things _in production_, in which case you should use Nginx, Apache, or Caddy (if you really want to use something Go-based). TL;DR: If you need GZIP/HTTP2, it's not "simple."

rhardih 11y ago
Python's SimpleHTTPServer is for when you have some directory on your computer and you want to test it locally in the browser. That's all. That is however, the same intended purpose as this tool. So, there's no reason to use GZIP or HTTP2 with a SimpleHTTPServer replacement. If you need those features, it's because you're doing things _in production_ Call me old fashioned, but I find it useful to know what a request would look like served from a production setting, without actually having to get it from production. If you're optimising for load times, the final size of a gzipped request matters greatly. It's nice to know if you're within the 14kb boundary before pushing out. HTTP/2 is a completely different beast as well. Since this is mostly for working on static sites, odds are you might host on a CDN with static file caches. If you've optimised your site for HTTP/1.1, bundling, inlining etc., but the the edge of the CDN actually serves these files as HTTP/2, you're very likely to have worked against the performance improvements given to you by HTTP/2.