WSGI middleware concept in Flask - Step-by-Step Execution

Concept Flow - WSGI middleware concept

Client Request

↓

WSGI Server

↓

Middleware: Receives Request

↓

Middleware: Processes or Modifies Request

↓

Passes Request to Flask App

↓

Flask App: Generates Response

↓

Middleware: Receives Response

↓

Middleware: Processes or Modifies Response

↓

WSGI Server

↓

Client Receives Response

The WSGI middleware sits between the server and the Flask app, intercepting requests and responses to modify or process them before passing along.

Execution Sample

Flask

def simple_middleware(app):
    def middleware(environ, start_response):
        print('Before app')
        response = app(environ, start_response)
        print('After app')
        return response
    return middleware

This middleware prints messages before and after calling the Flask app, showing how it wraps the app call.

Execution Table

Step	Action	Evaluation	Result
1	Client sends request	Request data created	Request ready for server
2	WSGI server receives request	Prepares environ dict	Environ passed to middleware
3	Middleware receives request	Prints 'Before app'	Logs message before app call
4	Middleware calls Flask app	Flask app processes request	Response generated
5	Middleware receives response	Prints 'After app'	Logs message after app call
6	Middleware returns response	Response passed to server	Server sends response to client
7	Client receives response	Response displayed	Request cycle complete

💡 Request cycle ends after response is sent back to client

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
environ	None	Request data dict	Passed to app	Passed back from app	Used by server
response	None	None	Flask app response	Middleware response	Sent to client

Key Moments - 3 Insights

Why does the middleware print 'Before app' before calling the Flask app?

Because middleware runs code before passing the request to the app, as shown in step 3 of the execution_table.

How does the middleware modify the response after the Flask app processes the request?

Middleware can run code after the app call, like printing 'After app' in step 5, allowing it to change or log the response.

What is the role of the 'environ' variable in the middleware?

'environ' holds request data passed from server to middleware and then to the Flask app, tracked in variable_tracker.

Visual Quiz - 3 Questions

Look at the execution_table, what is printed by the middleware before calling the Flask app?

A 'After app'

B 'Before app'

C 'Request received'

D 'Response sent'

💡 Hint

Check step 3 in the execution_table where middleware prints before calling the app.

At which step does the Flask app generate the response?

A Step 3

B Step 5

C Step 4

D Step 6

💡 Hint

Look at step 4 in the execution_table where the app processes the request.

If the middleware did not call the Flask app, what would happen to the response variable?

A It would be None and no response sent

B It would contain the request data

C It would be the final response

D It would cause an error in the server

💡 Hint

Refer to variable_tracker and execution_table steps 3 and 4 about response assignment.

Concept Snapshot

WSGI middleware wraps the Flask app call.
It receives the request environ and can modify it.
Calls the app to get a response.
Can modify the response before returning.
Acts as a bridge between server and app.
Useful for logging, auth, or modifying requests/responses.

Full Transcript

WSGI middleware is a piece of code that sits between the WSGI server and the Flask application. When a client sends a request, the server passes it to the middleware first. The middleware can look at or change the request before sending it to the Flask app. After the Flask app creates a response, the middleware can again modify or log the response before sending it back to the server, which then sends it to the client. This process allows middleware to add features like logging or authentication without changing the Flask app itself. The example code shows middleware printing messages before and after calling the app, demonstrating how it wraps the app call. Variables like 'environ' hold request data and 'response' holds the app's output, both tracked through the steps. Understanding this flow helps beginners see how middleware fits into the request-response cycle.

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