4 ms·

The reason most Python folks moved away from CGI more than two decades ago now is that the performance is terrible. The interpreter startup time (plus any time

The reason most Python folks moved away from CGI more than two decades ago now is that the performance is terrible. The interpreter startup time (plus any time executing module imports) has to run per request. This is much less of an issue for shell scripts which startup very quickly. The programming model does have its advantages though. Persistent servers risk leaking information across requests (seems to be a particular risk in async programming systems where requests execute concurrently in the same thread) so there's a definite advantage to isolation between requests. I'd love to see a server that used per-request v8 isolates (with snapshots for fast startup time.)

JulianMorrison 5y ago
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.
- laurencerowe 5y ago
  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 closure variable shared between requests which may come from different users.
  - JulianMorrison 5y ago
    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.
alisonkisk 5y ago
Fastcgi solved that specific problem about minutes after CGI was invented.
- laurencerowe 5y ago
  FastCGI is pretty much equivalent to proxying to another HTTP process (though it does make it easier to share authentication information from the http server to the proxied process.)

JulianMorrison 5y ago

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.

laurencerowe 5y ago
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 closure variable shared between requests which may come from different users.
- JulianMorrison 5y ago
  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.

alisonkisk 5y ago

Fastcgi solved that specific problem about minutes after CGI was invented.

laurencerowe 5y ago
FastCGI is pretty much equivalent to proxying to another HTTP process (though it does make it easier to share authentication information from the http server to the proxied process.)