Description: Cherokee is a flexible, very fast, lightweight Web server. It is implemented entirely in C, and has no dependencies beyond a standard C library. It is embeddable and extensible with plug-ins. It supports on-the-fly configuration by reading files or strings, TLS/SSL (via GNUTLS or OpenSSL), virtual hosts, authentication, cache friendly features, PHP, custom error management, and much more.
Keywords: cherokee web server httpd http

## Index → Modules → Handlers

## Handler: CGI

The cgi handler executes CGI programs.

### Parameters

This module accepts three parameters:

Parameters | Type | Description
--- | --- | ---
Script Alias | String | It defines a kind of execution interpreter. The CGI will be run as a parameter of this script.
Change to UID | String | Executes each CGI under its owner’s user ID.
Error handler | Boolean | Use CGI output as error message.
Check file | Boolean | Check file existence to build PATH_INFO and SCRIPT_NAME.
Pass request | Boolean | Pass request headers.
Allow X-Sendfile | Boolean | Use the non-standard X-Sendfile header.
Pass Request Headers | Boolean | Forward all the headers to the CGI as HTTP_*

Note that the X-Sendfile feature also supports `X-Accel-Redirect` headers transparently. This is to allow the migration of applications supporting it whithout having to make major code rewrites.

### Warning:

The `Check file` flag affects how PATH_INFO and SCRIPT_NAME are generated. You should disable this when you have an application that is running the whole virtual server tree, as it is a common source of problems. You can look at a practical example about PATH_INFO in the List & Send handler documentation.

`Check file` must be disabled for cases such as Rails, Django, etc, where everything that arrives to Cherokee must be re-sent to the framework as request.

Enabling `Check file` is the way to go if you are using any kind of file-based system, such as PHP.

If you are unsure of the way this is being taken into account, try both settings and see how your application behaves.

### Examples

This is a pretty common example. It defines a directory called `cgi` that points to a path out of the Sever root directory where the CGI programs are located.

Handler CGI configuration
Handler | CGI
Document Root | /usr/lib/cgi-bin
Script Alias | None
Change UID | Disabled
Error handler | Disabled
Check file | Enabled
Pass Request Headers | Enabled
Allow X-Sendfile | Disabled

Handler CGI intreface
Script Alias

Another example could be the case where you wanted your default requests to be managed by a specific script.

A real life example could be running Trac as a CGI script. In that case you would want to map an URL to the trac.cgi script.

For this you only need to set up the Script Alias option. Assuming you are using a `Directory`-type rule for the path `/trac` managed by the `CGI` handler, you could set `/usr/share/trac/cgi-bin/trac.cgi` as Script Alias.

After this, every request that matched the `/trac` path would be managed by the `trac.cgi` script.