Class type Nethttpd_engine.http_request_header_notification

class type http_request_header_notification = object .. end

method req_state : engine_req_state

Returns the request processing state which is `Received_header at the moment when this notification is delivered.

method environment : extended_async_environment

The 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:

• There is no cgi_path_info and no cgi_path_translated.
• The user is always unauthenticated.
• The Status response header works as in CGI. The Location header, however, must be a full URL when set (only browser redirects)
• When the request body is transmitted by chunked encoding, the header 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 -> unit

Schedules 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 -> unit

Schedules 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 -> unit

Schedules 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.