Request to Response

In the previous installment of "Behind the Scenes", we saw how the control flows from Form to File Storage. Today, we are going to see how the application reacts from request to response.

In this post, we are going to assume that we are using django's inbuilt runserver. The flow doesn't change much for other WSGI servers available.

When you invoke the runserver management command, the command line options are validated and an instance of WSGIServer is created and passed the WSGIRequestHandler, which is used to create the request object (WSGIRequest). After the request object is created and the request started signal is fired, the response is fetched through the WSGIRequestHandler.get_response(request).

In the get_response method of the request handler, first the urlconf location (by default the is setup based on the settings.ROOT_URLCONF. Then a RegexURLResolver compiles the regular expressions in the urlconf file. Next, the request middlewares are called in the order specified in the settings.MIDDLEWARE_CLASSES followed by the view middlewares after matching the view (callback) function against the compiled regular expressions from the urlconf. Then the view (callback) is invoked and verified that it does not return None before calling the response middlewares.

You can see the pictorial representation of the flow below:

Request to Response Flow{.align-center width=”543px” height=”792px”}

Thank you for reading the Agiliq blog. This article was writen by thejaswi on Jan 2, 2012 in response .
You can subscribe ⚛, read our books 📖 or contact us ✉