WSGI middleware concept in Flask - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What does this WSGI middleware do to the response?

Consider this WSGI middleware wrapping a Flask app. What will be the final response body sent to the client?

Flask

class SimpleMiddleware:
    def __init__(self, app):
        self.app = app

    def __call__(self, environ, start_response):
        def custom_start_response(status, headers, exc_info=None):
            headers.append(('X-Custom-Header', 'Middleware'))
            return start_response(status, headers, exc_info)

        response = self.app(environ, custom_start_response)
        modified_response = []
        for data in response:
            modified_response.append(data.upper())
        return modified_response

from flask import Flask
app = Flask(__name__)

@app.route('/')
def index():
    return 'hello world'

app.wsgi_app = SimpleMiddleware(app.wsgi_app)

A The client receives 'HELLO WORLD' with an extra header 'X-Custom-Header: Middleware'.

B The client receives 'hello world' with no extra headers.

C The client receives 'HELLO WORLD' but no extra headers.

D The client receives 'hello world' with an extra header 'X-Custom-Header: Middleware'.

💡 Hint

Think about how the middleware modifies both headers and response body.

The middleware adds a custom header by modifying the start_response call and converts the response body to uppercase by iterating over it and changing each chunk to uppercase.

❓ lifecycle

intermediate

When is the WSGI middleware __call__ method executed?

In a Flask app wrapped by WSGI middleware, at what point is the middleware's __call__ method triggered?

A Only once when the Flask app starts.

B Each time the Flask app receives an HTTP request.

C Only when the Flask app sends a response.

D Only when the Flask app raises an error.

💡 Hint

Think about what WSGI middleware wraps and how requests flow.

The __call__ method of WSGI middleware is called every time a new HTTP request comes in, because it wraps the app's WSGI callable which handles requests.

🔧 Debug

advanced

Why does this WSGI middleware cause a TypeError?

This middleware tries to modify the response but causes a TypeError. Why?

Flask

class FaultyMiddleware:
    def __init__(self, app):
        self.app = app

    def __call__(self, environ, start_response):
        response = self.app(environ, start_response)
        return response.upper()

A Because start_response is called twice causing a TypeError.

B Because the middleware forgot to call start_response.

C Because response is an iterable, not a string, so .upper() is invalid.

D Because the app does not return any response causing NoneType error.

💡 Hint

Check the type of the response returned by the app.

The app returns an iterable (like a list or generator) of byte strings, not a single string. Calling .upper() on the iterable causes a TypeError.

📝 Syntax

advanced

Which option correctly adds a header in WSGI middleware?

Select the code snippet that correctly adds a custom header 'X-Test: Yes' in WSGI middleware.

A

def __call__(self, environ, start_response):
    def custom_start(status, headers):
        headers.append(('X-Test', 'Yes'))
        return start_response(status, headers)
    return self.app(environ, custom_start)

B

def __call__(self, environ, start_response):
    headers = [('X-Test', 'Yes')]
    start_response('200 OK', headers)
    return self.app(environ, start_response)

C

def __call__(self, environ, start_response):
    start_response('200 OK', [('X-Test', 'Yes')])
    return self.app(environ, start_response)

D

def __call__(self, environ, start_response):
    def custom_start(status, headers, exc_info=None):
        headers.append(('X-Test', 'Yes'))
        return start_response(status, headers, exc_info)
    return self.app(environ, custom_start)

💡 Hint

Remember the start_response signature and how to wrap it.

Option D correctly defines a wrapper function with the right signature including exc_info, appends the header, and calls the original start_response. Others have wrong signatures or call start_response too early.

🧠 Conceptual

expert

What is the main benefit of using WSGI middleware in Flask apps?

Why would a developer add WSGI middleware around a Flask app instead of modifying the Flask app code directly?

A To add reusable functionality like logging or headers without changing the app code.

B To speed up the Flask app by bypassing Flask's routing system.

C To convert Flask apps into asynchronous apps automatically.

D To replace Flask's request handling with a different framework.

💡 Hint

Think about separation of concerns and reusability.

WSGI middleware allows adding features like logging, security checks, or header modifications in a reusable way without touching the Flask app code itself.

Practice

1. What is the main role of WSGI middleware in a Flask application?

easy

A. To serve static files directly to the client

B. To replace the Flask app entirely

C. To sit between the server and the Flask app to modify requests or responses

D. To handle database connections automatically

Solution

1. Step 1: Understand WSGI middleware position

   WSGI middleware acts as a layer between the web server and the Flask app, intercepting requests and responses.

2. Step 2: Identify middleware purpose

   It modifies or adds features like logging or security without replacing the app or handling unrelated tasks.

3. Final Answer:

   To sit between the server and the Flask app to modify requests or responses -> Option C

4. Quick Check:

   Middleware = intercepts requests/responses [OK]

Hint: Middleware wraps app to add features between server and app [OK]

Common Mistakes:

• Thinking middleware replaces the app
• Confusing middleware with static file serving
• Assuming middleware manages database connections

2. Which of the following is the correct way to wrap a Flask app with WSGI middleware named MyMiddleware?

easy

A. app = MyMiddleware(app)

B. app = app.MyMiddleware()

C. MyMiddleware(app)

D. app.middleware = MyMiddleware

Solution

1. Step 1: Recall middleware wrapping syntax

   WSGI middleware wraps the Flask app by passing the app instance to the middleware constructor.

2. Step 2: Match correct syntax

   The correct syntax is assigning the wrapped app back to app using app = MyMiddleware(app).

3. Final Answer:

   app = MyMiddleware(app) -> Option A

4. Quick Check:

   Wrap app by passing it to middleware constructor [OK]

Hint: Wrap app by calling middleware with app as argument [OK]

Common Mistakes:

• Calling middleware as a method on app
• Not assigning wrapped app back to a variable
• Assigning middleware class without instantiation

3. Given this WSGI middleware code wrapping a Flask app, what will be printed when a request is made?

class SimpleMiddleware:
    def __init__(self, app):
        self.app = app
    def __call__(self, environ, start_response):
        print('Before app')
        response = self.app(environ, start_response)
        print('After app')
        return response

app = Flask(__name__)
app = SimpleMiddleware(app)

medium

A. No output is printed

B. Only Before app is printed

C. Only After app is printed

D. Before app printed before request, After app printed after request

Solution

1. Step 1: Analyze middleware call flow

   The middleware prints 'Before app' before calling the wrapped app, then prints 'After app' after the app returns.

2. Step 2: Understand request handling

   When a request comes, both print statements execute in order around the app call.

3. Final Answer:

   Before app printed before request, After app printed after request -> Option D

4. Quick Check:

   Middleware prints before and after app call [OK]

Hint: Middleware __call__ runs code before and after app call [OK]

Common Mistakes:

• Assuming only one print runs
• Thinking prints happen asynchronously
• Confusing middleware with Flask route handlers

4. Identify the error in this WSGI middleware implementation:

class BrokenMiddleware:
    def __init__(self, app):
        self.app = app
    def __call__(self, environ, start_response):
        # Forgot to call the wrapped app
        return 'Hello'

medium

A. Middleware must call the wrapped app and return its response

B. Middleware should not have an __init__ method

C. Middleware should return a Flask response object, not a string

D. Middleware must not accept environ and start_response parameters

Solution

1. Step 1: Check middleware call method

   The __call__ method must call the wrapped app with environ and start_response to get the response.

2. Step 2: Identify missing call

   This code returns a string directly and does not call the wrapped app, breaking the WSGI chain.

3. Final Answer:

   Middleware must call the wrapped app and return its response -> Option A

4. Quick Check:

   Middleware must call wrapped app [OK]

Hint: Middleware must call and return wrapped app response [OK]

Common Mistakes:

• Returning a string instead of calling app
• Removing __init__ method unnecessarily
• Misunderstanding WSGI call signature

5. You want to add a WSGI middleware to your Flask app that adds a custom header X-Custom-Header: Hello to every response. Which approach correctly implements this?

hard

A. Wrap the app and modify the start_response to add the header after calling the app

B. Wrap the app and modify the start_response to add the header before calling the app

C. Modify the Flask app routes to add the header manually in each view

D. Add the header in the middleware by modifying the response iterable directly without start_response

Solution

1. Step 1: Understand start_response role

   start_response is a callable that sets HTTP status and headers before the response body is sent.

2. Step 2: Add header by wrapping start_response

   Middleware should wrap start_response to add the custom header before passing it to the app, so when the app calls it, the header is added.

3. Final Answer:

   Wrap the app and modify the start_response to add the header before calling the app -> Option B

4. Quick Check:

   Add headers by wrapping start_response before app call [OK]

Hint: Wrap start_response to add headers before app call [OK]

Common Mistakes:

• Adding headers after calling app (too late, start_response already called by app)
• Modifying response iterable directly (not standard for headers)
• Changing all routes instead of middleware