# Class type Nethttpd_engine.http_request_header_notification

    class type http_request_header_notification = object .. end

## Notification that a new request header has arrived

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