CGI, FastCGI, SCGI, WSGI, servlets and such

From Helpful

These are primarily notes
This is probably not going to be complete in any real sense, and exists to contain bits of useful information.

Contents

CGI

Basic CGI refers to the web server running an external program and having it interact with the browser on its behalf. Since almost all work and responsibility for correctness lies with the CGI app, this is often more bother than is necessary, though a few libraries can relieve that.

More importantly, though, most other things mentioned below are designed to be faster, easier, and/or scale better, because of technical reasons (e.g. always kept in memory) and/or because of the setup it is used in (e.g. processing units behind a work dispatcher).

See also:


CGI/HTTP/Environment variables

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

The canonical set defined by CGI 1.1 (see RFC 3875) are:

  • REQUEST_METHOD (values such as "GET", "POST", "HEAD", etc. )
  • QUERY_STRING
  • SCRIPT_NAME
  • PATH_INFO
  • PATH_TRANSLATED - local path after any applicable virtual-to-physical translation
  • SERVER_NAME
  • SERVER_PORT
  • CONTENT_LENGTH (of request)
  • CONTENT_TYPE (of request)
  • REMOTE_ADDR
  • REMOTE_HOST
  • AUTH_TYPE ("Basic" or "Digest", if used)
  • REMOTE_IDENT (see RFC 1413)
  • REMOTE_USER (as part of auth)
  • GATEWAY_INTERFACE - version of CGI, e.g. "CGI 1.1"
  • SERVER_PROTOCOL
  • SERVER_SOFTWARE

You may also see:

  • extension meta-variables - should be prefixed with X_
  • Protocol-Specific Meta-Variables
    • For example, HTTP servers will frequently set HTTP_*, such as:
      • HTTP_HOST
      • HTTP_REFERER,
      • HTTP_USER_AGENT,
      • HTTP_ACCEPT
      • HTTP_COOKIE,
      • ...and others


FastCGI and SCGI

FastCGI most broadly refers to the concept of running a persistent process to handle many requests over its lifetime, avoiding the process startup overhead that basic CGI implies.

SCGI (Simple CGI) is mostly an alternative to FastCGI for which the protocol is a little easier to implement.


Notes:

  • Apps are free from web server details; various web servers can be gateways to SCGI and FastCGI apps behind them (e.g. using mod_scgi and mod_fastcgi on apache). (Though in a few details it would be preferable to run on the web server to use some of its guts)
  • Makes it easier to scale up apps as it is usually easier to add references to more FastCGI hosts than to set up more hosts with embedded interpreters like PHP.
  • Makes it easier to apply separate security policies for each such process


See also:

WSGI

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

WSGI (Web Server Gateway Interface) is a callback-based API for Python web apps, which eases application hosting, wrapping, and such in much the same way similar APIs in other languages do.

See also Python notes - WSGI

AJP

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

AJP (Apache JServ Protocol) seems to be a simple and fast binary protocol, which makes it play in the same area as FastCGI, and has functionality similar to WSGI.

It is used in Tomcat, Jetty

Some other things speak it too, to make it more pluggable. This also makes it useful in FastCGI types of ways.

Others/Unsorted

  • Apache API
  • ISAPI (Internet Server API), mostly library loading (so comparable to CGI without the process start overhead)
  • Java servlet API
  • NSAPI (Netscape Server API): No formal standard, not too common.
  • Oracle's WRB
  • SAPI Spyglass Server API