Waiting For Benchmarks.
A fast and static web server for serving web apps
31–40 of 135 posts
Re: A fast and static web server for serving web apps
#32Earlier quoted context omitted.
Yes, it's a thing, and aside from the lack of HTTPS it's not much worse than your standard "./configure", "make", "make install" install flow of the last 20-whatever years of open source. If you don't trust the developer to serve you a safe install.sh script you shouldn't trust the rest of their code either. If you don't trust them you should audit the code no matter what the install process looks like. That said, if…
It's a lot worse than the standard configure, make and make install. For one, it's only requiring one simple script to get compromised and replaced to compromise your entire machine. At least when I download the tarball, unpack it, etc. I've got several steps before I even get to the make install that I would run as root. And I might not even do that depending on my install target. If I do, I have ample opportunity t…
"Provide an install tarball and provide a checksum of it that we can verify."
https://github.com/timothyej/Shortfin
My point was the people who are going to blindly run curl/sh commands are also going to blindly download the source tarball and run configure/make/make install, and the people who want to do more verification are certainly free to do so.
Re: A fast and static web server for serving web apps
#33What's a "static web server"? I haven't seen this term. A webserver for only static pages, i.e. it won't talk to a runtime? But it's "for serving web apps", this means all the dynamic content is pulled from client side JS? Then you would still need programs on the server to answer AJAX requests. I did not find an explanation on the page or by Googling.
A server that only serves static files. It doesn't enable the use of dynamic content like CGI[1]. Compare this to something like Apache or nginx. Both can serve static files but also support a number of ways of either directly running scripts (ex: mod_perl or mod_php in Apache) or proxying to other servers that handle dynamic content. [1]: https://en.wikipedia.org/wiki/Common_Gateway_Interface
OK, then, sorry if I'm being dense, but how can it be "for serving web apps"? App seems an odd term for a site consisting of only static files.
Re: A fast and static web server for serving web apps
#34I think the landing page would greatly benefit from two short paragraphs:
Why Shortfin when we have Nginx/Lighttpd?
Why Shortfin when we have thttpd?
Re: A fast and static web server for serving web apps
#35While I appreciate the time and effort that went into this, I'm more concerned with security than just speed alone. It's still relatively easy to throw hardware at the load problem (up to a point, naturally), but safety shouldn't take a back seat to performance.
The wget shell script installation does make me nervous and I'm glad the source is available separately. Blind installation of scripts was never "a thing" with me.
Of course, I'm still glad people are writing proper web servers (as opposed to simple 2-10 line ones). That creates an opportunity to explore the field with fresh ideas.
Re: A fast and static web server for serving web apps
#36Close.
Can add this to the list like thttpd.
Something I keep thinking I'll build is a fast, high connection count, limited HTTP server, something that is essentially a wrapper around a program that works like 'regular' and emits HTML. It is a corner case in a custom corner, but the target it something which is essentially a 'transponder.'
In the 'Internet of Things' I want to build a wrapper/environment such that my program can be
main(int argc, char *argv[]) {
uint16_t sense;
uint16_t chan;
sense = adc_read(atoi(argv[1]));
printf("Sensor %d reads : %d\n", chan, sense);
}
The keys are low memory footprint, lots of connections, easily wrapped around a 'regular' program.
Re: A fast and static web server for serving web apps
#37Just run the following command as root to install the server. # wget http://shortfin.io/install.sh && sh install.sh What? Are they serious? Is this becoming a thing? Please don't tell me that this is a thing.
I don't see any rational basis for this. If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three. And if you do want to vet the code, you know what to do. Practically no installation instructions include a "vet the code" step, so you aren't losing anything here. The lack of TLS is worrisome, but that's not so much "becoming a thing" a…
Although this isn't new, it should make you throw up in your mouth a little bit.
Malicious compromise is not the only way that an install script can become broken, or corrupted, on a remote site. The ability to checksum what you're running is a very useful sanity check and you should be doing it with all downloaded scripts/packages.
I suppose this is tilting at windmills, though.
Re: A fast and static web server for serving web apps
#38Earlier quoted context omitted.
Yes, it's a thing, and aside from the lack of HTTPS it's not much worse than your standard "./configure", "make", "make install" install flow of the last 20-whatever years of open source. If you don't trust the developer to serve you a safe install.sh script you shouldn't trust the rest of their code either. If you don't trust them you should audit the code no matter what the install process looks like. That said, if…
It's a lot worse than the standard configure, make and make install. For one, it's only requiring one simple script to get compromised and replaced to compromise your entire machine. At least when I download the tarball, unpack it, etc. I've got several steps before I even get to the make install that I would run as root. And I might not even do that depending on my install target. If I do, I have ample opportunity t…
I'm a Windows user. Virtually every piece of software I install comes in the form of an executable, that I download-and-run directly from the browser. I often give this executable administrator priviledges. The executable can then do whatever it wants on my computer. Usually it will install said piece of software (except when it was made by Oracle, it'll install said software and the Ask.com toolbar)
This has been standard practice for decades. It's very comprable to that wget oneliner. Why is it bad? Or, why is the wget oneliner bad but not Windows installers? Do Windows sysadmins compile tarballs and verify checksums? Or are Windows sysadmins simply dumber/less paranoid than Linux sysadmins?
Re: A fast and static web server for serving web apps
#39Just run the following command as root to install the server. # wget http://shortfin.io/install.sh && sh install.sh What? Are they serious? Is this becoming a thing? Please don't tell me that this is a thing.
I don't see any rational basis for this. If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three. And if you do want to vet the code, you know what to do. Practically no installation instructions include a "vet the code" step, so you aren't losing anything here. The lack of TLS is worrisome, but that's not so much "becoming a thing" a…
>"If you weren't vetting the code you downloaded before, you don't lose anything by blindly running the commands on one line instead of three."
Nginx is included in the OpenBSD base system (as of 5.2) and it does get vetted.
Re: A fast and static web server for serving web apps
#40Very cool. I've been doing the same thing lately, writing my own little web server that serves static files. It's been a fun learning experience!