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

A fast and static web server for serving web apps

shortfin.io

Post reply on HN
Print view View original

111–120 of 135 posts

Re: A fast and static web server for serving web apps

#111

Post by superuser2 »

ebbv wrote: post #27
tlrobinson wrote: post #24

Earlier 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…

If the site or domain is compromised, wouldn't a mildly competent attacker change the hashes also?

Re: A fast and static web server for serving web apps

#112

Post by [deleted] »

ebbv wrote: post #27
tlrobinson wrote: post #24

Earlier 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…

[deleted]

Re: A fast and static web server for serving web apps

#113

Post by steinnes »

jamespo wrote: post #106
hrjet wrote: post #74

Earlier quoted context omitted.

If you are taking recommendations, I wouldn't recommend installing them at all. You could ask the authors to support a platform which has a better security model. (Given that there are open-source and robuster-than-Windows platforms freely available.).

Cool, I'll just email MS and ask them to port Sharepoint to BSD.

Good job making an honest and good recommendation sound naive.

Re: A fast and static web server for serving web apps

#114

Post by thwarted »

ChuckMcM wrote: post #93
skrebbel wrote: post #58

Earlier quoted context omitted.

I don't understand (and am interested). What's "static" about it? With Apache and mod_rewrite and CGI, I could make the functionality you want (which is, of course, completely not low footprint, but I don't understand how what you want is different from CGI).

Static in the sense that it always executes the one function (doesn't load it from disk, its part of the executable) and so there is never any risk that some other path might get you 'out' of the docs directory and into the cgi_bin directory. So in this case static is code for 'compiled in' versus 'dynamically loaded.'

The apache module to do this is like a screenful of code. Really, mod_perl or mod_python or mod_wsgi can do this with dynamic languages, the code is only loaded once (per child in prefork apache). Your apache config can avoid reading the filesystem all together.

As long as you have a web server that can load modules and be invoked on specific URL requests, you can embed this.

Re: A fast and static web server for serving web apps

#116

Post by icebraining »

mbreese wrote: post #98
ChuckMcM wrote: post #93

Earlier quoted context omitted.

Static in the sense that it always executes the one function (doesn't load it from disk, its part of the executable) and so there is never any risk that some other path might get you 'out' of the docs directory and into the cgi_bin directory. So in this case static is code for 'compiled in' versus 'dynamically loaded.'

Like a statically linked HTML document? I know you're talking C code, but I could imagine some kind of HTML to C "compiler" that could you then statically link into an executable. Then you could have a full website that ran as a single static executable, including CGI-esque calls.

It's actually rather easy: http://www.linuxjournal.com/content/embedding-file-executabl...

Re: A fast and static web server for serving web apps

#117

Post by tracker1 »

ChuckMcM wrote: post #93
skrebbel wrote: post #58

Earlier quoted context omitted.

I don't understand (and am interested). What's "static" about it? With Apache and mod_rewrite and CGI, I could make the functionality you want (which is, of course, completely not low footprint, but I don't understand how what you want is different from CGI).

Static in the sense that it always executes the one function (doesn't load it from disk, its part of the executable) and so there is never any risk that some other path might get you 'out' of the docs directory and into the cgi_bin directory. So in this case static is code for 'compiled in' versus 'dynamically loaded.'

I'm more familiar with Windows, but Linux should be similar. If your application is executed often, then it's pages should be in memory already, and not necessarily need to be read from disk. In terms of execution, if it's a compiled binary, it should be fast enough, if you need more, what you want is a lightweight application server anyway.

Re: A fast and static web server for serving web apps

#118

Post by toupeira »

jfb wrote: post #11

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

This has indeed become so established that chocolatey.org can offer the following command with a straight face and call it "Easy Install!":

  @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

Re: A fast and static web server for serving web apps

#119

Post by andrewcooke »

c-a wrote: post #73

The request parsing code seems to be of dubious quality https://github.com/timothyej/Shortfin/blob/master/src/reques... From a cursory glance: 1. https://github.com/timothyej/Shortfin/blob/master/src/reques... should be (data_len - i >= 4) since it accesses data[i+3] 2. https://github.com/timothyej/Shortfin/blob/master/src/reques... shouldn't headers[header_count]->key also be null terminated? 3. https://github.com/t…

the code in general is not that great, imho.

as well as the header count (which i came here to post), there's another suspicious hard-coded size limit in the number of servers (1000). although you could only crash the system in that case by configuring too many.

there's very little error handling. good c code returns error codes all over the damn place. this hardly has any.

i wouldn't use this.

Re: A fast and static web server for serving web apps

#120

Post by corresation »

timothy89 wrote: post #110

A lot of you wanted benchmarks so here's one comparing Shortfin with Nginx. The tests was performed with a 56.1 kB PNG image with keep-alive turned off on my laptop. The best result out of 3 tests is shown below. tl;dr: Shortfin: 18 914 req/sec Nginx: 15 603 req/sec SHORTFIN sudo ab -n 100 -c 100 http://127.0.0.1:40/timothy-johansson.png Server Software: shortfin/0.9.5 Server Hostname: 127.0.0.1 Server Port: 40 Docum…

I don't know how valid a test of five milliseconds is to one of six milliseconds (much less one requesting a single known resource with no keep-alive). Though practically, even if those results held in a realistic test, is it still a viable alternative to nginx? You eliminate an enormous amount of flexibility (I admit -- I ♥ nginx) and proven trust for a margin-of-error theoretical speed advantage?

I understand the desire to get software out there, but webserver is a ridiculously hard nut to crack. nginx broke in through a new architectural paradigm.

Post reply on HN