Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Big list of HTTP static server one-liners

gist.github.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Big list of HTTP static server one-liners

#91

Post by gunnarmorling »

It will be a one-liner in Java soon too, once JEP 408 ("simple web server") has landed. In the meantime, this will do:

    jbang webster@gunnarmorling
This launches Vert.x, publishing the current directory, via the JBang launcher. Source code is here if you want to see what you actually run: https://github.com/gunnarmorling/jbang-catalog/blob/master/w...

Re: Big list of HTTP static server one-liners

#92

Post by throw0101a »

lipanski wrote: post #10

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…

> 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.

Surprising not on Debian or Ubuntu AFAICT:

* https://packages.debian.org/search?keywords=thttpd

Though it does seem to have this from the same author:

* https://packages.debian.org/search?keywords=mini-httpd

* http://www.acme.com/software/mini_httpd/

There are times that I want to run Let's Encrypt that's not a full-time web server (SMTP, IMAP, etc), and it would be handy to spin up something ad hoc on tcp/80 to do the verification step and then stop it right after.

Re: Big list of HTTP static server one-liners

#93

Post by Sohcahtoa82 »

satyanash wrote: post #6

The ruby one with the -run option is a bit nonintuitive in how it works. $ ruby -run -ehttpd . -p8000 The -r option requires un.rb[1] which is a file full of convenience functions, such as httpd in this example. Classic Ruby. Given that go has popularized long args with a single hyphen (-name etc), it is easy to mistake -run as an option by itself. [1] https://github.com/ruby/ruby/blob/master/lib/un.rb#L323

I've always disliked not having a space between a -parameter and it's option. "-r un" is so much more readable and explicit than "-run".

Why do people not include that space? Certainly it's not to save the time of not hitting the spacebar, right?

Re: Big list of HTTP static server one-liners

#94

Post by hmsimha »

capableweb wrote: post #34
henearkr wrote: post #31

Anybody has a one-liner allowing CORS (e.g. through options)? That would be utterly convenient to quickly test multithread WASM applications... I'm currently using ExpressJS for that, but it feels overkill..

I think these are meant for development setups, which you normally run in a localhost context, meaning you most likely won't have to deal with CORS. But, if you still need it, the http-server program has a --cors flag to enable wildcard CORS.

You could still want CORS if, for example, you're testing a front-end service that typically calls out to a remote resource. Maybe you typically deploy both same-origin in production, but for dev you want to be able to feed it some specific data. In this case a different port would require CORS.

There are lots of ways around this (put the files in your static folder, embed it into the file you're debugging, use a library which provides mock data, probably more), but it's not inconceivable to just want to be able to point the 'api' configuration param to localhost on a different port so you can just feed it json files from a directory that already has the data you want.

Re: Big list of HTTP static server one-liners

#95

Post by capableweb »

hmsimha wrote: post #94
capableweb wrote: post #34

Earlier quoted context omitted.

I think these are meant for development setups, which you normally run in a localhost context, meaning you most likely won't have to deal with CORS. But, if you still need it, the http-server program has a --cors flag to enable wildcard CORS.

You could still want CORS if, for example, you're testing a front-end service that typically calls out to a remote resource. Maybe you typically deploy both same-origin in production, but for dev you want to be able to feed it some specific data. In this case a different port would require CORS. There are lots of ways around this (put the files in your static folder, embed it into the file you're debugging, use a lib…

No, you misunderstand how CORS works. CORS (the allowance of CORS to be precise) is up to the server you're request data from, not your own local instance.

So if you're hosting a frontend, you can use whatever you want to host that frontend. It's up to the backend you're connecting to, to set the right headers to allow your quests. Then you're no longer using static file servers (probably) but rather some custom built/framework where you can easily set the headers you want.

Re: Big list of HTTP static server one-liners

#96

Post by hmsimha »

capableweb wrote: post #95
hmsimha wrote: post #94

Earlier quoted context omitted.

You could still want CORS if, for example, you're testing a front-end service that typically calls out to a remote resource. Maybe you typically deploy both same-origin in production, but for dev you want to be able to feed it some specific data. In this case a different port would require CORS. There are lots of ways around this (put the files in your static folder, embed it into the file you're debugging, use a lib…

No, you misunderstand how CORS works. CORS (the allowance of CORS to be precise) is up to the server you're request data from, not your own local instance. So if you're hosting a frontend, you can use whatever you want to host that frontend. It's up to the backend you're connecting to, to set the right headers to allow your quests. Then you're no longer using static file servers (probably) but rather some custom buil…

I don't think I am.

If I'm testing a react app on localhost:3000, and it normally calls out to an api of mine also, I may want to feed it some dummy data. Let's say I use python http.serve on port 5000 in a directory with files in a subdirectory `api` with files `users` and `posts` (which contain JSON data representative of the API response). I then set my react app to use localhost:5000 as the api.

The react app will then make the requests to the api such as `localhost:5000/api/users` and `localhost:5000/api/posts`. The server will respond with the data; however, if the header `Access-Control-Allow-Origin: http://localhost:3000` isn't set, the browser will block this data (probably? unless there are exceptions for localhost)

Re: Big list of HTTP static server one-liners

#97

Post by TheRealPomax »

closeparen wrote: post #83
TheRealPomax wrote: post #75

Earlier quoted context omitted.

it's also very insecure, because you have no guarantee that the version of `serve` that gets pulled down has been vetted and is verified exploit-free, unless you tell npx exactly which version should be used, at which point things start become less easy and more "having to remember which versions are safe".

Which software do you run that is vetted and verified exploit-free?

What a lovely strawman counter-argument you're attempting.

Shall we instead focus on installing with SHA verification based on CVE? Let's do that, that sounds pretty sensible instead of just throwing around yet another thinly disguised "letting the perfect be the enemy of good".

Re: Big list of HTTP static server one-liners

#98

Post by closeparen »

TheRealPomax wrote: post #97
closeparen wrote: post #83

Earlier quoted context omitted.

Which software do you run that is vetted and verified exploit-free?

What a lovely strawman counter-argument you're attempting. Shall we instead focus on installing with SHA verification based on CVE? Let's do that, that sounds pretty sensible instead of just throwing around yet another thinly disguised "letting the perfect be the enemy of good".

You brought up this incredible standard, "vetted and verified exploit free." I would like to know how it is achieved.

Re: Big list of HTTP static server one-liners

#99

Post by antihero »

TheRealPomax wrote: post #75
antihero wrote: post #39

If you have npm installed then simply doing npx serve is very easy

it's also very insecure, because you have no guarantee that the version of `serve` that gets pulled down has been vetted and is verified exploit-free, unless you tell npx exactly which version should be used, at which point things start become less easy and more "having to remember which versions are safe".

I'd love to audit every bit of code that runs on my machine but I also do not have a billion hours. Perhaps this is worse in JS land (it is) but this is a different problem to solve.

Re: Big list of HTTP static server one-liners

#100

Post by antihero »

kevincox wrote: post #57
antihero wrote: post #39

If you have npm installed then simply doing npx serve is very easy

Of course this requires internet access. It is also arguably less secure as it is downloading code from the internet and means that you are trusting the latest code from a handful of people https://www.npmjs.com/package/serve

I mean as a JS developer I am already kind of desensitized to taking my life in my hands when I do pretty much anything.
Post reply on HN