class type http_request_header_notification =object..end
This object notifies the user that a new request header has arrived.
The header is accessible by the environment object. The channels
also contained in this object are locked at this moment. The user must
now either call schedule_accept_body or schedule_reject_body. The
user will get a second notification (a http_request_notification, below)
when the request body has completely arrived (in case of acceptance), or
immediately (in case of rejection). One can also call schedule_finish
at any time to drop the current request.
method req_state : engine_req_stateReturns the request processing state which is `Received_header at the
moment when this notification is delivered.
method environment : extended_async_environmentThe request environment. Depending on the request processing state, parts
of the environment are already set up or still unaccessible ("locked").
In the state `Received_header only the request header and the
derived fields are accessible, and the input and output channels are
locked. In the state `Receiving_body the input channel is unlocked,
but it is not yet filled (reading from it may cause the exception
Buffer_underrun). The output channel remains locked.
In the state `Received_request, the input channel is unlocked and filled
with data, and the output channel is unlocked, too.
This environment is not fully CGI-compatible. In particular, the following differences exist:
cgi_path_info and no cgi_path_translated.Status response header works as in CGI. The Location header, however,
must be a full URL when set (only browser redirects)Content-Length is not set. In CGI this is interpreted as missing body.
It is unlikely that clients send requests with chunked encoding, as this
may cause interoperability problems anyway.
method schedule_accept_body : on_request:(http_request_notification -> unit) ->
?on_error:(unit -> unit) -> unit -> unitSchedules that the request body is accepted. In terms of HTTP, this sends the "100 Continue" response when necessary. One can reply with a positive or negative message.
This method returns immediately, and sets callbacks for certain events.
When the body has completely arrived (or is empty), the function
on_request is called back. The argument is the full request notification
(see below).
When the request is dropped for some reason, on_error is called back instead.
This can be used to free resources, for example.
Neither of the callbacks must raise exceptions.
method schedule_reject_body : on_request:(http_request_notification -> unit) ->
?on_error:(unit -> unit) -> unit -> unitSchedules that the request body is rejected. In terms of HTTP, this prevents sending the "100 Continue" response. Any arriving request body is silently discarded. One should immediately reply with an error mesage. negative message.
This method returns immediately, and sets callbacks for certain events.
When the body has completely arrived (or is empty), the function
on_request is called back. The argument is the full request notification
(see below).
When the request is dropped for some reason, on_error is called back instead.
This can be used to free resources, for example.
Neither of the callbacks must raise exceptions.
method schedule_finish : unit -> unitSchedules that the request is finished. This method should be called after the regular processing of the request to ensure that the HTTP protocol is fulfilled. If the request body has not been fully read, this is now done, and its data are dropped. If the response is incomplete, it is completed. If the error is not recoverable, a "Server Error" is generated.
