Adding request handlers¶
Handlers are callables with the signature
(app, request, next_handler).
Add a handler to the handler chain.
Handlers added via this method are inserted into the system handler chain above the main handler. They will be called in the order they are added (the last handler added will be called directly before the main handler).
Handlers are typically functions but can be any callable that accepts
Each handler should either call its
next_handler, return a response object, or raise an exception.
TODO: Allow ordering?
System handler chain¶
Requests are processed through a chain of handlers. This module contains the “system” handlers. These are handlers that always run in a specific order.
Most of the system handlers always run. They can’t be turned off, but
you can swap in different implementations via settings. Take a look at
tangled/web/defaults.ini to see how you would do this.
Some handlers are only enabled when certain settings are enabled or when
certain configuration takes place. For example, to enable CSRF
tangled.app.csrf.enabled setting needs to be set to
True. Another example: the static files handlers is only enabled
when at least one static directory has been mounted.
If an auth handler is enabled, it will run directly before any (other) handlers added by the application developer.
All added handlers are called in the order they were added. The last
handler to run is always the
main() handler; it calls into
application code (i.e., it calls a resource method to get data or
error_handler(app, request, main_handler, original_response)¶
Handle error response.
If an error resource is configured, its
GETmethod will be called to get the final response. This is accomplished by setting the error resource as the resource for the request and then passing the request back into the main handler.
If CORS is enabled, the main handler will be wrapped in the CORS handler so that error responses will have the appropriate headers.
If no error resource is configured, the original error response will be returned as is.
request_finished_handler(app, request, _)¶
Call request finished callbacks in exc handling context.
This calls the request finished callbacks in the same exception handling context as the request. This way, if exceptions occur in finished callbacks, they can be logged and displayed as usual.
Finished callbacks are not called for static requests.
tweaker(app, request, next_handler)¶
Tweak the request based on special request parameters.
resource_finder(app, request, next_handler)¶
Find resource for request.
If a resource isn’t found, a 404 response is immediatley returned. If a resource is found but doesn’t respond to the request’s method, a
405 Method Not Allowedresponse is returned.
timer(app, request, next_handler)¶
Log time taken to handle a request.
main(app, request, _)¶
Get data from resource method and return response.
If the resource method returns a response object (an instance of
Response), that response will be returned without further processing.
If the status of
request.responsehas been set to 3xx (either via @config or in the body of the resource method) AND the resource method returns no data, the response will will be returned as is without further processing.
Otherwise, a representation will be generated based on the request’s Accept header (unless a representation type has been set via @config, in which case that type will be used instead of doing a best match guess).
If the representation returns a response object as its content, that response will be returned without further processing.
Otherwise, request.response will be updated according to the representation type (the response’s content_type, charset, and body are set from the representation).