NAME

       mod_esi - Erlang Server Interface

DESCRIPTION

       This  module  defines the Erlang Server Interface (ESI) API. It is a more efficient way of writing Erlang
       scripts for your Inets web server than writing them as common CGI scripts.

DATA TYPES

       The following data types are used in the functions for mod_esi:

         env() = :
           {EnvKey()::atom(), Value::term()}

           Currently supported key value pairs

           {server_software, string()}:
             Indicates the inets version.

           {server_name, string()}:
             The local hostname.

           {gateway_interface, string()}:
             Legacy string used in CGI, just ignore.

           {server_protocol, string()}:
             HTTP version, currently "HTTP/1.1"

           {server_port, integer()}:
             Servers port number.

           {request_method, "GET | "PUT" | "DELETE" | "POST" | "PATCH"}:
             HTTP request method.

           {remote_adress, inet:ip_address()} :
             The clients ip address.

           {peer_cert, undefined | no_peercert | DER:binary()}:
             For TLS connections  where  client  certificates  are  used  this  will  be  an  ASN.1  DER-encoded
             X509-certificate  as  an  Erlang  binary.  If  client  certificates  are not used the value will be
             no_peercert, and if TLS is not used (HTTP or connection is lost due to network failure)  the  value
             will be undefined.

           {script_name, string()}:
             Request URI

           {http_LowerCaseHTTPHeaderName, string()}:
             example: {http_content_type, "text/html"}

EXPORTS

       deliver(SessionID, Data) -> ok | {error, Reason}

              Types:

                 SessionID = term()
                 Data = string() | io_list() | binary()
                 Reason = term()

              This  function  is  only  intended to be used from functions called by the Erl Scheme interface to
              deliver parts of the content to the user.

              Sends data from an Erl Scheme script back to the client.

          Note:
              If any HTTP header fields are added by the script, they must be in the first  call  to  deliver/2,
              and the data in the call must be a string. Calls after the headers are complete can contain binary
              data to reduce copying overhead. Do  not  assume  anything  about  the  data  type  of  SessionID.
              SessionID must be the value given as input to the ESI callback function that you implemented.

ESI CALLBACK FUNCTIONS

EXPORTS

       Module:Function(SessionID, Env, Input)-> {continue, State} | _

              Types:

                 SessionID = term()
                 Env = env()
                 Input = string() | chunked_data()
                 chunked_data()  =  {first, Data::binary()} | {continue, Data::binary(), State::term()} | {last,
                 Data::binary(), State::term()}
                 State = term()

              Module must be  found  in  the  code  path  and  export  Function  with  an  arity  of  three.  An
              erlScriptAlias must also be set up in the configuration file for the web server.

              mod_esi:deliver/2  shall  be  used  to  generate  the  response  to the client and SessionID is an
              identifier that shall by used when calling  this  function,  do  not  assume  anything  about  the
              datatype.  This  function  may be called several times to chunk the response data. Notice that the
              first chunk of data sent to the client must at least contain  all  HTTP  header  fields  that  the
              response  will  generate.  If  the  first  chunk does not contain the end of HTTP header, that is,
              "\r\n\r\n", the server assumes that no HTTP header fields will be generated.

              Env environment data of the request see description above.

              Input is query data of a GET request or the body of a PUT or POST request.  The  default  behavior
              (legacy  reasons)  for  delivering the body, is that the whole body is gathered and converted to a
              string. But if the httpd config parameter max_client_body_chunk is set, the body will be delivered
              as binary chunks instead. The maximum size of the chunks is either max_client_body_chunk or decide
              by the client if it uses HTTP chunked encoding to send the body. When using the chunking mechanism
              this  callback  must  return  {continue,  State::term()}  for  all  calls  where  Input is {first,
              Data::binary()} or {continue, Data::binary(), State::term()}. When Input is {last, Data::binary(),
              State::term()} the return value will be ignored.

          Note:
              Note  that  if the body is small all data may be delivered in only one chunk and then the callback
              will be called  with  {last,  Data::binary(),  undefined}  without  getting  called  with  {first,
              Data::binary()}.

              The  input State is the last returned State, in it the callback can include any data that it needs
              to keep track of when handling the chunks.

       Module:Function(Env, Input)-> Response

              Types:

                 Env = env()
                 Input = string()
                 Response = string()

              This callback format consumes much memory, as the whole response must be generated  before  it  is
              sent to the user. This callback format is deprecated. For new development, use Module:Function/3.