Request/response middleware flow in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

Middleware request processing order

Consider three Django middleware classes: M1, M2, and M3, added in this order in settings. When a request comes in, in what order are their process_request methods called?

A M1 → M3 → M2

B M3 → M2 → M1

C M2 → M1 → M3

D M1 → M2 → M3

💡 Hint

Think about how middleware wraps the request processing in the order they are listed.

Django calls process_request methods in the order middleware are listed in settings. So M1 first, then M2, then M3.

❓ component_behavior

intermediate

Middleware response processing order

Given the same middleware order M1, M2, M3, in what order are their process_response methods called when returning a response?

A M3 → M2 → M1

B M1 → M3 → M2

C M1 → M2 → M3

D M2 → M1 → M3

💡 Hint

Response processing happens in reverse order of request processing.

Django calls process_response methods in reverse order of the middleware list. So M3 first, then M2, then M1.

❓ lifecycle

advanced

Effect of middleware returning a response early

If middleware M2's process_request returns an HttpResponse object instead of None, what happens next?

A The view is executed, then M2's process_response is called.

B M3's process_request is still called, then view is executed.

C M2's process_response is called immediately, skipping M3's process_request and the view.

D All middleware process_request methods run, but the view is skipped.

💡 Hint

Returning a response early stops further request processing.

If a middleware's process_request returns a response, Django skips calling later middleware's process_request and the view. It starts calling process_response in reverse order from the middleware that returned the response.

📝 Syntax

advanced

Correct middleware method signature

Which of these is the correct signature for a Django middleware's process_view method?

A def process_view(self, request, response, view_func):

B def process_view(self, request, view_func, view_args, view_kwargs):

C def process_view(self, request, view_func):

D def process_view(self, request):

💡 Hint

Check the official Django docs for process_view parameters.

The process_view method receives the request, the view function, and the positional and keyword arguments for the view.

🔧 Debug

expert

Diagnosing middleware response order bug

You have middleware M1, M2, M3 in that order. M2's process_response modifies the response content. But you notice M2's process_response changes overwrite M3's changes. Why?

A M3's process_response runs before M2's, so M2 overwrites M3's changes.

B process_response methods run in the same order as process_request, so M3 runs last.

C Middleware order in settings is reversed, so M3 runs last.

D M2's process_response is not called because M3 returns a response early.

💡 Hint

Remember the order of response processing is reverse of request processing.

process_response methods run in reverse order of middleware list. So M3 runs before M2. M2's changes overwrite M3's if both modify the same response parts.

Practice

1. What is the main purpose of middleware in Django's request/response flow?

easy

A. To directly render HTML templates

B. To run code before and after the view processes a request

C. To manage database migrations

D. To handle user authentication only

Solution

1. Step 1: Understand middleware role

   Middleware runs code before and after views to modify requests or responses.

2. Step 2: Compare options

   Only To run code before and after the view processes a request describes this behavior; others describe unrelated tasks.

3. Final Answer:

   To run code before and after the view processes a request -> Option B

4. Quick Check:

   Middleware = pre/post view code [OK]

Hint: Middleware wraps views to add pre/post processing [OK]

Common Mistakes:

• Confusing middleware with template rendering
• Thinking middleware manages database directly
• Assuming middleware only handles authentication

2. Which of the following is the correct minimal structure of a Django middleware class?

easy

A. def my_middleware(get_response):
def middleware(request):
return get_response(request)
return middleware

B. class MyMiddleware:
def process_request(self, request):
pass

C. class MyMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
response = self.get_response(request)
return response

D. class MyMiddleware:
def handle(self, request):
return request

Solution

1. Step 1: Recall Django middleware class pattern

   Middleware must have __init__ with get_response and __call__ with request.

2. Step 2: Match options to pattern

   Only class MyMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): response = self.get_response(request) return response matches this exact structure; others miss __call__ or use wrong methods.

3. Final Answer:

   Class with __init__ and __call__ methods -> Option C

4. Quick Check:

   Middleware class = __init__ + __call__ [OK]

Hint: Middleware class needs __init__ and __call__ methods [OK]

Common Mistakes:

• Using process_request instead of __call__
• Defining middleware as a simple function without class
• Missing get_response parameter in __init__

3. Given this middleware code, what will be printed when a request is processed?

class LogMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        print('Init called')
    def __call__(self, request):
        print('Before view')
        response = self.get_response(request)
        print('After view')
        return response

# Assume this middleware is active and a request comes in

medium

A. Init called\nBefore view\nAfter view

B. Before view\nAfter view\nInit called

C. After view\nBefore view\nInit called

D. Init called only

Solution

1. Step 1: Understand middleware instantiation

   __init__ runs once when server starts, printing 'Init called'.

2. Step 2: Trace __call__ during request

   On request, prints 'Before view', calls view, then prints 'After view'.

3. Final Answer:

   Init called\nBefore view\nAfter view -> Option A

4. Quick Check:

   Init once, then before/after view prints [OK]

Hint: Init prints once; __call__ prints before and after view [OK]

Common Mistakes:

• Thinking __init__ runs on every request
• Mixing order of prints
• Ignoring that __call__ wraps the view call

4. Identify the error in this middleware code snippet:

class ExampleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
    def __call__(self, request):
        response = self.get_response
        return response

medium

A. Missing parentheses when calling get_response in __call__

B. Missing __init__ method

C. Using wrong method name instead of __call__

D. Returning request instead of response

Solution

1. Step 1: Check __call__ method

   It assigns response = self.get_response without calling it (missing parentheses).

2. Step 2: Understand consequence

   Without parentheses, response is a function, not a response object, causing errors.

3. Final Answer:

   Missing parentheses when calling get_response in __call__ -> Option A

4. Quick Check:

   Call get_response() with () [OK]

Hint: Always call get_response with parentheses in __call__ [OK]

Common Mistakes:

• Forgetting parentheses on function calls
• Confusing method names
• Returning request instead of response

5. You want to add a custom header 'X-Hello: World' to every response using middleware. Which code correctly implements this?

hard

A. class HeaderMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
response = self.get_response(request)
response.header['X-Hello'] = 'World'
return response

B. class HeaderMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
request['X-Hello'] = 'World'
response = self.get_response(request)
return response

C. class HeaderMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
response = self.get_response(request)
response.add_header('X-Hello', 'World')
return response

D. class HeaderMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
response = self.get_response(request)
response['X-Hello'] = 'World'
return response

Solution

1. Step 1: Recall how to add headers in Django response

   Response objects support dict-like access to headers: response['Header-Name'] = value.

2. Step 2: Check options for correct header addition

   class HeaderMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): response = self.get_response(request) response['X-Hello'] = 'World' return response uses response['X-Hello'] = 'World' correctly after calling get_response.

3. Final Answer:

   response['X-Hello'] = 'World' after getting the response -> Option D

4. Quick Check:

   Use response['Header'] = value to add headers [OK]

Hint: Add headers by setting response['Header'] = value after get_response [OK]

Common Mistakes:

• Trying to add headers to request object
• Using non-existent add_header method
• Accessing headers attribute which doesn't exist on response