# Index of types

A
argument_processing [Netcgi1_compat.Netcgi] |
argument_processing [Netcgi] | How to process CGI arguments: ``Memory`: Keep the value of the argument in memory, ``File`: Store the value of the argument in an external file, ``Automatic`: If the argument is structured and carries a file name, the value will be stored in a file; otherwise it is loaded into memory. (Note: The meaning of ``Automatic` changed in OcamlNet 0.92.)
auth [Netcgi_jserv] | Authentication record
C
cache_control [Netcgi1_compat.Netcgi_types] |
cache_control [Netcgi_types] | This is only a small subset of the HTTP 1.1 cache control features, but they are usually sufficient, and they work for HTTP/1.0 as well.
cgi_config [Netcgi1_compat.Netcgi_env] |
cgi_config [Netcgi_env] |
cgi_cookie [Netcgi1_compat.Netcgi_types] |
cgi_cookie [Netcgi_types] |
controlpipe [Netcgi_jserv] | The type of the control pipe
F
fcgiBeginRequestBody [Netcgi_fcgi_10] | begin request
fcgiEndRequestBody [Netcgi_fcgi_10] | end request
fcgiHeader [Netcgi_fcgi_10] | protocal header
fcgiRequest [Netcgi_fcgi_10] | fcgi params will return an asociation list fcgi stdin will return a string a full request record, what you get when you call fcgi_accept
I
input_mode [Netcgi1_compat.Netcgi_env] |
input_mode [Netcgi_env] | Determines how to read the request: ``Standard`: Only the request body is read from the input channel (CGI standard), Not yet implemented: ``Direct`: Both header and body of the request are read from the input channel
input_state [Netcgi1_compat.Netcgi_env] |

input_state [Netcgi_env]

The input processing state: ``Start`: Input data have not yet been received, ``Receiving_header`: The request header is currently being received, ``Received_header`: The request header has been completely received, and nothing of the request body has yet been received, ``Receiving_body`: The request body is currently being received, ``Received_body`: The request body has been completely received Transition diagram:

     `Start ->
     `Receiving_header ->
     `Received_header ->
     `Receiving_body ->
     `Received_body

J

jserv_config [Netcgi_jserv_app]

Server configuration: `js_backlog` is the maximum length of the backlog queue (containing client connections that are not yet accepted by the application server), `js_reuseaddr`: Whether to reuse the port immediately, `js_cgiconfig`: The CGI-level configuration, `js_init_process`: This hook is called when a new process is initialized. For ``Sequential` servers it is called once before the server begins to accept connections. For ``Forking` and ``Process_pool` servers it is called when new processes are forking., `js_fini_process`: The reverse hook of `js_init_process`: Called after a process receives the shutdown notification. For ``Sequential` servers it is called once after the server stops to accept connections. For ``Forking` and ``Process_pool` servers it is called before sub processes exit., `js_idle_master`: This hook is called every second by the master process that accepts new connections. When it raises an exception, the master socket is closed, and the exception falls through to the caller., `js_idle_worker`: This hook is called every second by the worker process that processes connections. Exceptions are logged. Examples: `js_init_process`: Open a new database connection for every process, `js_fini_process`: Close the database connection, `js_idle_master`: Check whether the server should shut down, and if so, raise an exception to exit, `js_idle_worker`: Close database connections after a period of inactivity

O
operating_type [Netcgi1_compat.Netcgi] |
operating_type [Netcgi] | The operating type determines how generated data are buffered.
other_url_spec [Netcgi1_compat.Netcgi_types] |
other_url_spec [Netcgi_types] | Determines how an URL part is generated:
output_mode [Netcgi1_compat.Netcgi_env] |
output_mode [Netcgi_env] | Determines how to deliver the response: ``Standard`: The format of the response header has CGI format, followed by the response body, Not yet implemented: ``Direct`: The format of the response header has HTTP format, followed by the response body. This is also known as "non-parsed header" format.
output_state [Netcgi1_compat.Netcgi_env] |

output_state [Netcgi_env]

The output processing state: ``Start`: Output has not yet been sent, ``Sending_header`: The response header is currently being sent, ``Sent_header`: The response header has been completely sent, and nothing of the body has yet been sent, ``Sending_body`: The response body is currently being sent, ``Sent_body`: The response body has been sent up to a check point, ``End`: The response has been completely sent Transition diagram:

                  `Start ->
                  `Sending_header ->
                  `Sent_header ->
              +-> `Sending_body
              |      |
              |      V
              +-- `Sent_body
                     |
                     V
                  `End

P
protocol [Netcgi1_compat.Netcgi_env] |
protocol [Netcgi_env] | Now defined in `Nethttp`
protocol_attribute [Netcgi1_compat.Netcgi_env] |
protocol_attribute [Netcgi_env] | Now defined in `Nethttp`
protocol_type [Netcgi_jserv_app] | Selects the protocol.
protocol_version [Netcgi1_compat.Netcgi_env] |
protocol_version [Netcgi_env] | Now defined in `Nethttp`
Q
query_string_spec [Netcgi1_compat.Netcgi_types] |
query_string_spec [Netcgi_types] | Determines how the query part of URLs is generated:
R
representation [Netcgi1_compat.Netcgi_types] | Embedded in the single place of use.
representation [Netcgi_types] | Representations of CGI arguments: ``Simple msg`: The argument is unstructured, ``MIME msg`: The argument has a MIME header in addition to the value

request_handler [Netcgi_jserv_app]

The request handler consists of: `req_activate`: A function to process requests and to generate responses. The function gets a fully initialized `cgi_activation` object, and is expected to write the response., `req_processing`: Style of CGI argument processing. Same meaning as in `Netcgi`., `req_operating_type`: Style of CGI response buffering. Same meaning as in `Netcgi`.

request_method [Netcgi1_compat.Netcgi_types] |
request_method [Netcgi_types] | The supported request methods: ``GET`: Side effect-free request of a web resource, ``POST`: Request with side effects, ``HEAD`: Only the header of the corresponding ``GET` are requested, ``DELETE`: Request to delete the web resource, ``PUT arg`: Request to upload the web resource
S

server_type [Netcgi_jserv_app]

Server type: ``Sequential servlets`: The server processes the requests sequentially., ``Forking(n,servlets)`: The server forks for every request, and processes it in the child process. The integer `n` is the maximum number of children processes; if it is exceeded, an error message is displayed immediately without forking., ``Process_pool(n,servlets)`: The server forks a fixed number of times (the integer `n`). The children will process the requests concurrently. If more requests arrive than children are available, the requests must wait until a child becomes free again. In `servlets` the list of available servlets is passed.

status [Netcgi1_compat.Netcgi_types] |
status [Netcgi_types] |
store [Netcgi1_compat.Netcgi_types] | Embedded in the single place of use.
store [Netcgi_types] | Determines where the data of the CGI argument are actually stored.
T
t [Netcgi_jserv] | The type of an AJP server
W
workaround [Netcgi1_compat.Netcgi_env] |
workaround [Netcgi_env] | Indicates special behaviour: ``Work_around_MSIE_Content_type_bug`: Versions of the Internet Explorer send illegal content types. This workaround extracts the right data from the malformed data field, ``Work_around_backslash_bug`: Almost all browsers send illegal backslash sequences when backslashes occur in filenames. This workaround accepts such sequences.