Webs_cgiCGI gateway connector.
This connector serves one request via CGI by reading headers from the process environment, reading the body from Unix.stdin and writing the response on Unix.stdout.
See serve for making sure your gateway passes an environment suitable for deriving a Webs.Http.Response.t value.
Note. This was reimplemented at some point. But that new implementation was little tested. Expect hiccups.
References.y
val make :
?extra_vars:string list ->
?log:(Webs.Http.Connector.Log.msg -> unit) ->
?max_request_body_byte_size:int ->
?service_path:Webs.Http.Path.t ->
unit ->
tmake () is a new connector with:
extra_vars c the list of custom environment variables whose content is added to the request headers of requests handled by c. See serve.log the connector message logger. Defaults to Webs.Http.Connector.Log.default with trace enabled.max_request_body_byte_size the maximal request body size in bytes. FIXME not enforced.service_path is the path on which the root of the service is served by the gateway. This value can be found in a request in the Webs.Http.Request.service_path property. This path is stripped from the path found in the request's target to yield the Webs.Http.Request.path property of the request. Defaults to Webs.Http.Path.root.val extra_vars : t -> string listextra_vars c is the list of additional environment variables of c. See make.
val log : t -> Webs.Http.Connector.Log.msg -> unitlog c is the log of c. See make.
val max_request_body_byte_size : t -> intmax_request_body_byte_size c is the maximal request body size in bytes supported by c. See make.
val service_path : t -> Webs.Http.Path.tservice_path c is service path of c. See make.
val serve :
t ->
(Webs.Http.Request.t -> Webs.Http.Response.t) ->
(unit, string) Stdlib.resultserve c service runs service service with connector c. The connector supports Webs_unix.Fd.Writer body writers.
This blocks until the response for the request has been served. The error is returned in case of connector error, it's a good practice to write the message on stderr and exit with a non-zero exit code if that happens.
The Webs.Http.Request.t value is constructed from the environment and Unix.stdin as follows:
Webs.Http.Request.method' is the value of the REQUEST_METHOD variable.Webs.Http.Request.raw_path is the value of the non standard REQUEST_URI which should have the raw, percent-encoded, request target (HTTP/1.1) or :path pseudo-header (HTTP/2, HTTP/3).Webs.Http.Request.version is the value of the SERVER_PROTOCOL variable.Webs.Http.Request.service_path is the value of service_path cWebs.Http.Request.headers has the following headers defined:
Webs.Http.Headers.content_type if the variable CONTENT_TYPE is defined and non empty.Webs.Http.Headers.content_length if the variable CONTENT_LENGTH is defined and non empty.HTTP_$VAR there is a corresponding $var header whose name is made by lowercasing $VAR and mapping '_' to '-'. For example HTTP_USER_AGENT becomes Webs.Http.Headers.user_agent. If defined the variables HTTP_CONTENT_TYPE and HTTP_CONTENT_LENGTH are respectively overriden by CONTENT_TYPE and CONTENT_LENGTH when present.$VAR in extra_vars c a header is added with the value of the variable. The header name of a variable is made by lowercasing it, mapping '_' to '-' and prefixing the result with x-cgi. For example SERVER_SOFTWARE becomes x-cgi-server-software.Webs.Http.Request.body, is the result of reading Unix.stdinThe connector otherwise adheres to the following conventions:
Note. We require the non standard URI_REQUEST environment variable because recovering the value for Webs.Http.Request.raw_path from the CGI PATH_INFO and QUERY_STRING variables is not really possible. Moreover PATH_INFO easily get confused by requests like "/s1/s2%2Fha/s3".