You can replace . with any of your other cloud storage backends too (s3, google drive, dropbox, etc), or http with sftp, webdav, ftp, dlna. It works on Windos/macOS/Linux.
Using `nix` I have an alias called `serve` that runs `nix run nixpkgs.caddy -c caddy -host 0.0.0.0 -port 8000 browse` which will download Caddy if it is not in my cache and then run it. It's one of my favorite aliases and I use it way more frequently than I'd expect.
It's similar to the others mentioned here, with the nice extras that there's optional basic auth, optional HTTPS with automatic creation and use of a self-signed certificate, there are installers for most popular OS's package managers (snap, homebrew, scoop, chocolatey), tiny 2-5 MB zero-dependency binary and some other features.
I've had plans to add automatic Let's Encrypt certs, Onion service creation and reverse SSH functionality (either using one's own SSH server or one of the public ones) for a while and hope I'll get to them soon. Does anyone have any specific preferences for one of those or another feature specifically for the use case of serving files to another person as quickly as possible?
Huh .. that'd be a fun post; see how many of these can be susceptible for climbing out of their web root. The author does list which ones support dir indexes.
Caddy is a one-liner. Plenty of the one-liners are suitable for production. There are so many solutions that you might as well use one, even in development, that doesn't have such glaring issues, because you're basically training your muscle memory to reach for it.
You might want to include a disclaimer that you're the author, maintainer and person behind the company that operates ngrok ;)
Just wanted to chime in and say I love ngrok too, not allow allows you to easily create proxies, it allows you to create proxies that also works on the public internet (ngrok assigns you a x.ngrok.io address) and with tcp connections. Great work on it inconshreveable!
I was pleased and surprised that the Python 3 one works with Termux on this cellphone. I've had trouble with Python socket stuff on here in the past, but now I suspect that may have been specific to IP multicast.
Unlike `python3 -m http.server`, `npx serve` doesn’t redirect `/path/to/dir` to `/path/to/dir/`. This is a problem if you are using relative paths in your `/path/to/dir/index.html`.
Eh! That’s not true. I just tried and both Python 2.7.16 and Python 3.7.6 return a "404 Not Found” when I try to download and existing file that is located one or more levels up from the directory where the HTTP server was started. Here is a screenshot showing both results: https://i.imgur.com/uizp7zV.png
Huh? When I use SimpleHTTPServer with .. it just ignores the .. and keeps me in the same directory. Is the behavior different on different versions of python or something? Is there some special technique I don't know? I tried with '.' and with '%2e' .
Same-origin policy prevents that specific attack, although the same idea exists if you’re not protected from DNS rebinding on localhost, and `--bind 127.0.0.1` (or some other way to block the port) is necessary – but the Pythons’ built-in HTTP servers aren’t vulnerable to path traversal anyway.