Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We're still serving a cgi-bin directory at work for the occasional quick and dirty internal web app. The ergonomics are great as long as you keep it simple. The fact that it's cgi doesn't mean you have to print http/1.0 to stdout manually. For example, in python the builtin wsgiref.handlers.CGIHandler lets you run any wsgi app as a cgi script:

  import wsgiref.handlers, flask
  app = flask.Flask(__name__)
  wsgiref.handlers.CGIHandler().run(app)
The way we run the scripts is with uwsgi and its cgi plugin[1]. I find it simpler and more flexible than running apache or lighttpd just for mod_cgi. Since uwsgi runs as a systemd unit, we also have all of systemd's hardening and sandboxing capabilities at our disposal. Something very convenient in uwsgi's cgi handling that's missing from mod_cgi, is the ability to set the interpreter for a given file type:

  cgi = /cgi-bin=/webapps/cgi-bin/src
  cgi-allowed-ext = .py
  cgi-helper = .py=/webapps/cgi-bin/venv/bin/python3  # all dependencies go here
Time to first byte is 250-350ms, which is acceptable for our use case.

[1]: https://uwsgi-docs.readthedocs.io/en/latest/CGI.html



This is great information, thanks! And it looks like wsgiref.handlers.CGIHandler isn't deprecated yet.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: