Elli example callback.
Behaviours: elli_handler
.
Your callback needs to implement two functions, handle/2
and handle_event/3
. For every request, Elli will call your handle function with the request. When an event happens, like Elli completed a request, there was a parsing error or your handler threw an error, handle_event/3
is called.
chunk_loop/1 | Send 10 separate chunks to the client. |
handle/2 | Handle a Req uest. |
handle_event/3 | Handle Elli events, fired throughout processing a request. |
chunk_loop(Ref) -> any()
Equivalent to chunk_loop(Ref, 10)
.
Send 10 separate chunks to the client.
handle(Req, _Args) -> Result
Req = elli:req()
_Args = elli_handler:callback_args()
Result = elli_handler:result()
Handle a Req
uest. Delegate to our handler function.
See also: handle/3.
handle_event(Event, Args, Config) -> ok
Event = elli:event()
Args = elli_handler:callback_args()
Config = [tuple()]
Handle Elli events, fired throughout processing a request.
elli_startup
is sent when Elli is starting up. If you are implementing a middleware, you can use it to spawn processes, create ETS tables or start supervised processes in a supervisor tree.
request_complete
fires after Elli has sent the response to the client. Timings
contains timestamps (native units) of events like when the connection was accepted, when headers/body parsing finished, when the user callback returns, response sent, etc. Sizes
contains response sizes like response headers size, response body or file size. This allows you to collect performance statistics for monitoring your app.
request_throw
, request_error
and request_exit
events are sent if the user callback code throws an exception, has an error or exits. After triggering this event, a generated response is sent to the user.
invalid_return
is sent if the user callback code returns a term not understood by elli, see elli_http:execute_callback/1
. After triggering this event, a generated response is sent to the user.
chunk_complete
fires when a chunked response is completely sent. It's identical to the request_complete
event, except instead of the response body you get the atom client
or server
depending on who closed the connection. Sizes
will have the key chunks
, which is the total size of all chunks plus encoding overhead.
request_closed
is sent if the client closes the connection when Elli is waiting for the next request on a keep alive connection.
request_timeout
is sent if the client times out when Elli is waiting for the request.
request_parse_error
fires if the request is invalid and cannot be parsed by erlang:decode_packet/3
or it contains a path Elli cannot parse or does not support.
client_closed
can be sent from multiple parts of the request handling. It's sent when the client closes the connection or if for any reason the socket is closed unexpectedly. The Where
atom tells you in which part of the request processing the closed socket was detected: receiving_headers
, receiving_body
or before_response
.
client_timeout
can as with client_closed
be sent from multiple parts of the request handling. If Elli tries to receive data from the client socket and does not receive anything within a timeout, this event fires and the socket is closed.
bad_request
is sent when Elli detects a request is not well formatted or does not conform to the configured limits. Currently the Reason
variable can be {too_many_headers, Headers}
or {body_size, ContentLength}
.
file_error
is sent when the user wants to return a file as a response, but for some reason it cannot be opened.