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

61–70 of 135 posts

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

#61

Post by chc »

pnathan wrote: post #25
bru wrote: post #12

Earlier quoted context omitted.

Side-note for the author: the download can be made more elegant that way $ curl http://shortfin.io/install.sh | sh I definitely agree with the HTTPS. For example this is what meteor proposes: $ curl https://install.meteor.com | sh

asdfsdfgkjlsdfg! Streaming your install script directly into computer execution without even giving it a once-over, md5 compare, etc is atrociously insecure.

That's completely orthogonal to what we're talking about here. If you're already not doing it, you're not doing it any less by being more efficient. And it doesn't really matter if you're running it in a throwaway VM like I do.

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

#62

Post by chc »

eksith wrote: post #59
chc wrote: post #50

Earlier quoted context omitted.

I am not seeing the relevance.

Your assertion is that if we want to vet the code, there are steps to do that and no conventional installation includes these steps, correct? Well, getting the "trust us, this is easy" type installation instructions here isn't terribly comforting from a brand new project. That's the sort of thing I'd expect from a source I know. Not from this project that I didn't even know existed before this post. It's unrealistic…

That's all true, but I don't see what it adds to the conversation. It's just a plug for nginx. "Conservative, security-conscious people like older projects with large, trusted organizations backing them" is something of a tautology.

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

#63

Post by eksith »

chc wrote: post #62
eksith wrote: post #59

Earlier quoted context omitted.

Your assertion is that if we want to vet the code, there are steps to do that and no conventional installation includes these steps, correct? Well, getting the "trust us, this is easy" type installation instructions here isn't terribly comforting from a brand new project. That's the sort of thing I'd expect from a source I know. Not from this project that I didn't even know existed before this post. It's unrealistic…

That's all true, but I don't see what it adds to the conversation. It's just a plug for nginx. "Conservative, security-conscious people like older projects with large, trusted organizations backing them" is something of a tautology.

This conversation started when you said you don't see any rational basis for the criticism of running wget/install as root when no vetting takes place on conventional installations. My post wasn't a plug for Nginx, but an imploring to know what you install.

Since I can't know everything that's running on my system, I'd trust that from some place that actually does vetting. It doesn't need to be OpenBSD, but some competent source with an established record for security.

That's not tautology. It's sane practice that I wish more people followed.

The wget/shell install as root is presumptuous in the extreme for a young project with no history. In fact, many young projects, whose security we know nothing about, have similar installations and that's a bad precedent to set and continue.

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

#64

Post by timothy89 »

tunnuz wrote: post #2

You're from Lund! I've been studying in Lund! By the way, can you show some statistics and performance metrics with respect to nginx, Apache and such? To put it another way: why did you choose to write your own webserver instead of using, say, nginx?

Lund is awesome! ;)

I will perform some benchmarks and compare it to nginx (and maybe apache) in a while.

By the time (2010, 2011) I was working at a company that needed a tracking server for tracking clicks and views in email. So I started to mod lighttpd and thought that I could make it faster. So in true "challenge accepted" spirit I started to write my own HTTP server. And since then I've made it better and better. It's not meant to be an nginx killer. It will always be very basic, fast and lightweight. It's great for projects where you need a web server included.

As I wrote in another comment I have used the code base myself in various projects such as:

* Tracking clicks, view, etc. for AlphaMail * The send-API server for AlphaMail * A DMARC report server (https://github.com/amail/comfirm-dmarc-report-server) * A REST server with redis as storage

I've never used it as a static web server in production yet. Mostly because of the lack of a reverse proxy and other great features that nginx has and shortfin not.

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

#65

Post by timothy89 »

davidcollantes wrote: post #5
tunnuz wrote: post #2

You're from Lund! I've been studying in Lund! By the way, can you show some statistics and performance metrics with respect to nginx, Apache and such? To put it another way: why did you choose to write your own webserver instead of using, say, nginx?

I am curious too, on the performance metrics. He is still using Nginx though.

Nginx is just acting as a reverse proxy because I host other sites on the same server. Benchmarks will come!

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

#66

Post by chc »

eksith wrote: post #63
chc wrote: post #62

Earlier quoted context omitted.

That's all true, but I don't see what it adds to the conversation. It's just a plug for nginx. "Conservative, security-conscious people like older projects with large, trusted organizations backing them" is something of a tautology.

This conversation started when you said you don't see any rational basis for the criticism of running wget/install as root when no vetting takes place on conventional installations. My post wasn't a plug for Nginx, but an imploring to know what you install. Since I can't know everything that's running on my system, I'd trust that from some place that actually does vetting. It doesn't need to be OpenBSD, but some comp…

Yes, but at this point, of course you won't want to use the OP's software, or any other newish project linked on Hacker News. The method of installation (which is what we were talking about here) isn't the problem, because you wouldn't use anything from him because he isn't OpenBSD. And that's OK — you can be as conservative as you like. It just had me confused as to why you were bringing it up.

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

#67

Post by eksith »

chc wrote: post #66
eksith wrote: post #63

Earlier quoted context omitted.

This conversation started when you said you don't see any rational basis for the criticism of running wget/install as root when no vetting takes place on conventional installations. My post wasn't a plug for Nginx, but an imploring to know what you install. Since I can't know everything that's running on my system, I'd trust that from some place that actually does vetting. It doesn't need to be OpenBSD, but some comp…

Yes, but at this point, of course you won't want to use the OP's software, or any other newish project linked on Hacker News. The method of installation (which is what we were talking about here) isn't the problem, because you wouldn't use anything from him because he isn't OpenBSD. And that's OK — you can be as conservative as you like. It just had me confused as to why you were bringing it up.

  because you wouldn't use anything from him because he isn't OpenBSD
My sarcasm detector must be malfunctioning. Who said I don't want to use his software or install anything linked on HN because they're new? I've checked out and installed plenty of things linked on HN, not because they're new, but because they're interesting. But lax procedures like the root shell install aren't good indicators.

In fact, I was just going over his install script to see whether it's worth installing and test, but seeing things like this :

  # The umask is ridiculous, or mkdir does not conform to POSIX,
  # or it failed possibly due to a race condition.  Create the
  # directory the slow way, step by step, checking for races as we go.
  
  
  case $dstdir in
     /*) prefix='/';;
     -*) prefix='./';;
     *)  prefix='';;
  esac
Is what makes me nervous.

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

#68

Post by babuskov »

untothebreach wrote: post #14
babuskov wrote: post #4

I don't get it. You create a server to solve C10K problem, and then host its own website with nginx? Why? Having HN crowd coming and testing your server would be a great test, no?

From the footer: > It was created in 2011 by Timothy E. Johansson and is the base for the send-API and the tracking server for AlphaMail. > It also powers this website (though behind nginx). You can reach it directly on port 88 : shortfin.io:88

I read that. But why?

What's the point in using this if you're going to have nginx in front?

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

#69

Post by Isofarro »

ds9 wrote: post #54
packetslave wrote: post #51

Earlier quoted context omitted.

Perhaps you've heard of this new language, JavaScript?

Still not much of an app unless the JS does AJAX, but then it's talking to a server that's running some dynamic process, maybe with DB access etc. - right?

Not necessarily. You can make an ajax request to a static resource. The server doesn't have to be a dynamic process. Static resources are just files.

A client-side JavaScript Twitter could be done this way. Every tweet, or timeline can be pre-baked into a static json file, and ajaxed in.

Twitter can then be simplified to a backend application that updates these files.

Granted, tweeting is a separate matter; that requires an endpoint that processes data.

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

#70

Post by babuskov »

tlrobinson wrote: post #24
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.

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 not the same as configure,make,make install as you can always: configure --prefix=$HOME/whatever

and later run it on some unprivileged TCP port over 1024.

Post reply on HN