Django Request and Response Flow

A Graphical way of Django Request and Response Flow


The Web Server & WSGI:

When you hit enter in your browser to load a page, your request makes its way through the internet to something that looks like this.

This server needs to know what to do with what you just sent it. That’s a job for the Web Server Gateway Interface, or WSGI. All WSGI wants to do is take your request and give you back a response.

Django has a WSGI layer that takes in your request and gets a response from it.


If you look at the first picture, you’ll notice that the word “Middleware” shows up multiple times in between the two WSGI parts. Django middleware is a really small, light-weight plugin that modifies the requests that come in and the responses that go out.

Middleware comes in five flavors – request middleware, view middleware, error middleware, template response middleware, and response middleware. The order your define your middleware in your settings file matters. If you define middlewares in the order shown below (CommonMiddleware, then SessionMiddleware…), the execution order is shown in the picture below.

Middleware Execution Order


The request and view middlewares get processed first and in order. The exception, template response and response middleware get executed in reverse order after the view.

Request Middleware:

Request middleware runs on every request that comes in before that request is directed to a view. This part doesn’t know what is going to happen with this request – there’s no URL resolution so it knows nothing about which view it’s going to go to. All this middleware knows is that this request was made by a user and was passed from the WSGI layer.

This is really useful if you want to process the request differently depending on where it’s coming from. For example, you can find out if the request is coming from a mobile device pass that information down to your views when this request gets resolved.

This should return a HttpResponse object or None. If you return None, then the exectution will keep happening (the flow chart in the first picture will keep going on). If you return an HttpResponse, the response will go straight back to the WSGI layer and no other middleware or views will be called.

URL Resolution:

This is the part where Django looks at the URL associated with the request and figures out which view to go to. This part hits the urlconfs in your project. It’s pretty straightforward. If you’re confused about this you can read the Django docs on this (it does a great job of explaining urlconfs).

View Middleware:

The view middleware acts on the request after it knows which view it’s going to. Personally, I haven’t seen this being used anywhere. You also have to be careful here and not mess with request.POST. If you edit request.POST here, your view will never get executed.


This is the place where a backend developer will spend lots of time. Views are where we can put together data from models and templates to create the pages that users will see. This is also the place where you handle incoming POST calls that edit the data layer.

Views always accept a request object and return a response object.


Views that generate pages that users will see generally use templates. Templates are HTML pages with a bit of python thrown in to help you create really useful pages. Views can pass in a dictionary of data (called the context) to a template. The template can access the data by referring to the keys. For example, the context for this page contains a key called likeCount. When I want to show the like count somewhere in the HTML, I can refer to the key with {{likeCount}} in my template.

To learn more about how templates work, you can look here in the Django docs.