Live data from Hacker News

Big list of HTTP static server one-liners

gist.github.com

61–70 of 100 posts

Re: Big list of HTTP static server one-liners

#61

My favourite is thttpd [1] which is super tiny, battle-tested and actually meant for the job (and only this job). It's available as a package on most Linux distros. Serving a static folder `/static` on port `3000` as user `static-user` and with cache headers set to 60 seconds would go like this: thttpd -D -h 0.0.0.0 -p 3000 -d /static -u static-user -l - -M 60 Even if you've got Python lying around on every Ubuntu se…

https://github.com/blueness/sthttpd

Re: Big list of HTTP static server one-liners

#62

Note that a lot of these bind to 0.0.0.0 by default. This has caused me surprises in the past as I was failing to connect to a host that is available over IPv6. Sometimes it was even intermittent as I would sometime resolve to the IPv4 and sometimes get the IPv6 and fail. For python3 this is easily remedied. python -m http.server -b :: On most OS configurations this will listen on both IPv4 and IPv6. Or for when you…

For the use cases of most of that software list, they should actually listen to localhost (127.0.0.1 and ::1) only, because security. Listening on every IPv6 interface, which might be exposed directly on the IPv6 internet, is even a worse idea.

In general I agree. Localhost is a safer default, it doesn't cost much to type a bind address when you need jt. However 0.0.0.0 is a worse default than ::

Re: Big list of HTTP static server one-liners

#63

My favourite is thttpd [1] which is super tiny, battle-tested and actually meant for the job (and only this job). It's available as a package on most Linux distros. Serving a static folder `/static` on port `3000` as user `static-user` and with cache headers set to 60 seconds would go like this: thttpd -D -h 0.0.0.0 -p 3000 -d /static -u static-user -l - -M 60 Even if you've got Python lying around on every Ubuntu se…

Because the point is that I want a webserver up now. If I was running something long-term I would just use Caddy anyway.

Re: Big list of HTTP static server one-liners

#66
post #63

My favourite is thttpd [1] which is super tiny, battle-tested and actually meant for the job (and only this job). It's available as a package on most Linux distros. Serving a static folder `/static` on port `3000` as user `static-user` and with cache headers set to 60 seconds would go like this: thttpd -D -h 0.0.0.0 -p 3000 -d /static -u static-user -l - -M 60 Even if you've got Python lying around on every Ubuntu se…

Because the point is that I want a webserver up now . If I was running something long-term I would just use Caddy anyway.

Yeah, I want a HTTP server up because I need an actual server to test my web app or because I want to send a large file to someone on my local network and don't want to guide them through setting up smb/rsync/whatever and just want to give them a URL.

I don't particularly care about what's least likely to fall over under sustained load or is suitable security wise to expose to the internet, because it's not going to have to deal with either of these things. Being "already installed" on the other hand is a big selling point.

Re: Big list of HTTP static server one-liners

#67
post #40

Weird to call these one liners, they're just invocation commands. By that logic, apache is a one-liner.

With that logic there are no one-liners. Even binary code is just an abstraction interpreted by microcode.

The point is that there is a working http server already installed on your machine. And you just need to run this one simple, memorable command to use it.

Very useful if you just want to quickly copy some files from A to B in your LAN or WAN (wouldn't use it over Internet because not encrypted).

Re: Big list of HTTP static server one-liners

#70

$ emrun --port 8000 . # Handles WASM; most others don't.[1] [1] Emscripten's emsdk includes emrun, which actually serves WASM files with the correct MIME type out-of-the-box, unlike the python2 and python3 servers and most others.

Does emrun allow CORS, required for SharedArrayBuffers?

CORS is up to the server you're calling, not up to the server hosting the JS code. Any server that supports custom HTTP headers, support CORS. No, SharedArrayBuffers don't require "CORS" (which you probably mean if they work in CORS context rather than "require"). What they do require is a Secure Context (https, localhost or similar) https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

I wonder how come CORS is such a misunderstood concept globally. It's a really simple concept in general, and understanding it will make a lot of your work as a frontend/full stack developer easier. Take a day and fully understand it, it'll pay off.

Post reply on HN