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

I recommend CGI instead of web frameworks

halestrom.net

Post reply on HN
Print view View original

71–80 of 89 posts

Re: I recommend CGI instead of web frameworks

#71

Post by pjc50 »

user5994461 wrote: post #37
simonw wrote: post #17

CGI really is a beautiful abstraction. The reason we stopped using it 15+ years ago was performance: forking a new process for every incoming web request just didn't make sense on ~2000 era hardware. I wonder how true that is today, given that our machines have vastly more RAM and CPU? If you squint at them the right way AWS Lambda functions are pretty similar to the CGI model.

It's unusable today, more so than it was a decade ago: - modern frameworks have a much higher startup time (see Python imports, Java VM and other). CGI was fine to run a perl script with no dependencies. - it prevents any form of caching. caching is very important for many use cases. - it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis…

> prevents any form of caching. caching is very important for many use cases

There are alternatives; even back in 2000 you'd keep the stuff you wanted cached in the filesystem, where the webserver would handle the cache headers for you, and there are ways to hook a cache miss by the webserver to generate content on demand.

Re: I recommend CGI instead of web frameworks

#72

Post by bawolff »

swamp_gas wrote: post #62
bawolff wrote: post #43

Earlier quoted context omitted.

> it prevents any form of caching. caching is very important for many use cases > it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis for caching). nutcracker, twemproxy?

apache caching reverse proxy even.

From context i assume the poster meant object caching, since the cgi model wouldnt affect client caching or cdn style front-end caching.

Re: I recommend CGI instead of web frameworks

#73

Post by bawolff »

czx4f4bd wrote: post #70
wazoox wrote: post #46

Earlier quoted context omitted.

For these there's good old "perl -T" :)

How does perl -T protect against XSS?

Its dynamic taint checking - it tries to keep track of which variables are user controlled (tainted) and prevent you from using them unsafely.

As a strategy for dealing with xss, its fallen out of favour, but static taint analysis, which is the same thing but not at runtime and less accurate is still super popular in big shops as a CI step.

As an approach though its more a way to make sure you dont screw up as opposed to a way to solve the problem in general.

Re: I recommend CGI instead of web frameworks

#74

Post by JulianMorrison »

laurencerowe wrote: post #63
JulianMorrison wrote: post #16

Earlier quoted context omitted.

You'll find that the isolation goes out of the window when you need sessions; they need to be stored somewhere that persists across requests.

Where sessions are too large to store in signed cookies (which should usually be preferred when possible since they require no extra infrastructure and avoid any risk of session data mixups) they normally end up in some kind of database or memcache since you likely want to support multiple processes. It's much less likely you'll lookup the wrong user's session than accidentally store some user data in a module or clo…

That is literally what session hijacking is. A uses the session created for B, various ways.

Do not store sessions in signed cookies, because those can be stolen, and they bloat your requests and responses shipping all the data up and down each time. Store sessions in a database, tie them to an IP, and time them out. Transmit only an opaque ID. Ideally, re-create a different ID with each new request. If you are using a web framework, it should have tried and tested mechanisms to do all this for you. This is the kind of thing you lose cooking your own CGI.

Re: I recommend CGI instead of web frameworks

#75

Post by bawolff »

ozim wrote: post #52
Gaelan wrote: post #32

There's an important point I haven't seen discussed yet: I don't believe it's possible to write secure web apps without a templating engine with safe-by-default XSS handling (i.e. interpolated text is sanitized, unless explicitly marked as trusted HTML somehow), which implies some amount of a web framework or at least a web-specific library.

I think important point is distinction between: a) static documents - basically HTML+CSS and no scripts on the back-end There is not much to discuss here a lot of stuff could be just that but people don't want to write blog posts directly in html :) We have static site generators that are doing great so it seems to be working well. b) dynamic documents - you get data from DB based on query, like list of phone numbers…

Nobody would use cgi for (a) (cgi integrates with webservers, so you already have one to serve your static documents).

You still care about xss (and other vulns, although the technology the grandparent mentioned is specificly for xss) in case b just like case c.

- you might host other things on that domain (or even subdomain, which is a lot trickier but not impossible to attack), and this could be a launching point of an attack.

- attackers might rewrite your page to mislead people, e.g. as part of a phishing attack, to harm your reputation or just to redirect to advertisers.

The impact of any security vulnerability is going to depend on what you are doing and what you have to lose. It seems less significant in case B, but its a mistake to extrapolate as its impossible to tell without business-specific context. Maybe the simple list page is listing out life-saving information.

Re: I recommend CGI instead of web frameworks

#77

Post by TheCoelacanth »

loup-vaillant wrote: post #59
user5994461 wrote: post #37

Earlier quoted context omitted.

It's unusable today, more so than it was a decade ago: - modern frameworks have a much higher startup time (see Python imports, Java VM and other). CGI was fine to run a perl script with no dependencies. - it prevents any form of caching. caching is very important for many use cases. - it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis…

Wait a minute, how CGI is preventing anyone from reusing connections? The web server doesn’t have to cut connections between CGI requests, the same way it doesn’t have to cut connections between the delivery of two different static files. Maybe current web servers are written in such a way that they do cut connections between CGI requests, but I’d be surprised if they really have to.

They aren't talking about client->server connections but about server->DB or server->other server connections.

With CGI, any connection you create in your script is going to close at the end of the request when your process shuts down.

Re: I recommend CGI instead of web frameworks

#78

Post by samus »

zozbot234 wrote: post #30
simonw wrote: post #17

CGI really is a beautiful abstraction. The reason we stopped using it 15+ years ago was performance: forking a new process for every incoming web request just didn't make sense on ~2000 era hardware. I wonder how true that is today, given that our machines have vastly more RAM and CPU? If you squint at them the right way AWS Lambda functions are pretty similar to the CGI model.

Forking a new process for every incoming web request might just make a lot of sense on ~2020 era, Spectre- and Meltdown-prone hardware. And so the Wheel of Samsara turns.

The threat posed by Spectre and Meltdown cannot be mitigated by just switching to a multiprocessing architecture. The threat is exactly about bypassing that abstraction too.

Re: I recommend CGI instead of web frameworks

#79

Post by samus »

jagged-chisel wrote: post #11
speedgoose wrote: post #6

Earlier quoted context omitted.

It's a bit better but one process can only process one request at a time. You need a lot more processes compared to a http framework processing http requests in parallel.

How do those web frameworks gain the ability to process things in parallel? What prevents a ‘single process’ from adopting those same methods?

Usually you have a thread pool (threads have startup costs too), monitor the server socket and assign incoming connections to one of the worker threads. Nonblocking architectures that do everything in a single thread also exist.

It's very common even to do this: just use Apache `mod_proxy` (or something more specialised) to forward requests to a backend server such as Apache Tomcat.

Re: I recommend CGI instead of web frameworks

#80

Post by samus »

jagged-chisel wrote: post #68
speedgoose wrote: post #27

Earlier quoted context omitted.

Those web frameworks are lower level and have an embedded HTTP server designed to process things in parallel. It's in the standard library in golang or nodejs for example.

Sounds like one can use libuv in a CGI project and gain the same parallelization.

... and end up with something like Node.js or Vert.x.
Post reply on HN