Request context in Flask - Step-by-Step Execution

Concept Flow - Request context

Start HTTP Request

↓

Create Request Context

↓

Push Context to stack

↓

Handle Request in View

↓

Access request, session, g

↓

Return Response

↓

Pop Context from stack

↓

End HTTP Request

Flask creates a request context for each HTTP request, pushes it to a stack, lets the view access request data, then pops it after response.

Execution Sample

Flask

from flask import Flask, request
app = Flask(__name__)

@app.route('/')
def home():
    return f"You requested {request.path}"

This code creates a Flask app that returns the path of the current request using the request context.

Execution Table

Step	Action	Request Context State	Accessed Variables	Output
1	Start HTTP request to '/'	No context yet	null	null
2	Create request context for '/'	Context created with path='/'	null	null
3	Push context to stack	Context active on stack	null	null
4	Call view function 'home'	Context active	request.path='/'	null
5	Return response string	Context active	request.path='/'	You requested /
6	Pop context from stack	Context removed	null	null
7	End HTTP request	No context	null	Response sent

💡 Request ends after response sent and context popped from stack

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 6	Final
request.path	null	null	/	/	null	null
request context stack	Empty	Empty	Contains context	Contains context	Empty	Empty

Key Moments - 2 Insights

Why can we access 'request.path' inside the view without passing it explicitly?

Because Flask pushes a request context on a stack before calling the view (see execution_table step 3), making 'request' available globally during the request.

What happens if we try to access 'request' outside a request context?

There is no active request context (see execution_table step 1 or 7), so accessing 'request' will raise an error because Flask doesn't know which request you mean.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the request context pushed to the stack?

A Step 3

B Step 2

C Step 4

D Step 6

💡 Hint

Check the 'Action' and 'Request Context State' columns around steps 2-4.

According to the variable tracker, what is the value of 'request.path' after step 4?

A null

B '/home'

C '/'

D Empty string

💡 Hint

Look at the 'request.path' row under 'After Step 4' column.

If the context was not popped at step 6, what would happen?

A The response would not be sent.

B The request context stack would remain full, possibly causing memory issues.

C The view function would not run.

D The request path would change.

💡 Hint

Refer to the 'request context stack' row in variable_tracker after step 6.

Concept Snapshot

Flask creates a request context for each HTTP request.
This context is pushed to a stack before the view runs.
Inside the view, 'request' and other globals are accessible.
After the response, the context is popped from the stack.
Accessing 'request' outside this context causes errors.

Full Transcript

When Flask receives an HTTP request, it creates a request context that holds data about the request, like the URL path. This context is pushed onto a stack so that inside the view function, you can access 'request' and other related objects without passing them explicitly. After the view returns a response, Flask pops the context off the stack to clean up. If you try to use 'request' outside this context, Flask will raise an error because it doesn't know which request you mean. This flow ensures each request is handled separately and safely.

Practice

1. What does the Flask request object represent during a web request?

easy

A. The server configuration settings

B. The database connection for the app

C. The template rendering engine

D. Information about the current web request like headers and form data

Solution

1. Step 1: Understand the role of request in Flask

   The request object holds data about the current HTTP request, such as headers, form inputs, and client IP.

2. Step 2: Differentiate from other Flask components

   Database connections, server settings, and template engines are separate from the request context and not part of request.

3. Final Answer:

   Information about the current web request like headers and form data -> Option D

4. Quick Check:

   Request object = current web request info [OK]

Hint: Request object holds current HTTP request info [OK]

Common Mistakes:

• Confusing request with server or database objects
• Thinking request exists outside a web request
• Assuming request holds app config

2. Which of the following is the correct way to import the request object in a Flask app?

easy

A. from flask import request

B. from flask import Request

C. import flask.request

D. from flask.request import request

Solution

1. Step 1: Recall Flask import conventions

   Flask provides request as a lowercase object to import directly from flask.

2. Step 2: Check each option's syntax

   from flask import request uses correct lowercase import. from flask import Request wrongly capitalizes. import flask.request is invalid syntax. from flask.request import request tries to import from a submodule that doesn't exist.

3. Final Answer:

   from flask import request -> Option A

4. Quick Check:

   Correct import is lowercase 'request' [OK]

Hint: Import request lowercase from flask [OK]

Common Mistakes:

• Using uppercase 'Request' instead of 'request'
• Trying to import from flask.request submodule
• Using incorrect import syntax

3. Given this Flask route code, what will print(request.method) output when a user visits /hello in a browser?

from flask import Flask, request
app = Flask(__name__)

@app.route('/hello')
def hello():
    print(request.method)
    return 'Hi'

medium

A. GET

B. POST

C. PUT

D. DELETE

Solution

1. Step 1: Identify default HTTP method for browser visits

   When a user visits a URL in a browser, the request method is usually GET.

2. Step 2: Check route method defaults

   The route does not specify methods, so it accepts GET by default.

3. Final Answer:

   GET -> Option A

4. Quick Check:

   Browser visit = GET method [OK]

Hint: Browser visits use GET method by default [OK]

Common Mistakes:

• Assuming POST is default method
• Confusing route methods with request methods
• Not knowing default HTTP methods

4. What is the error in this Flask code snippet?

from flask import Flask, request
app = Flask(__name__)

@app.route('/data')
def data():
    user_agent = request.headers['User-Agent']
    return user_agent

print(request.method)

medium

A. Route decorator syntax is wrong

B. Missing import for request

C. Accessing request outside request context causes error

D. Headers attribute does not exist on request

Solution

1. Step 1: Identify where request.method is accessed

   The last line tries to print request.method outside any route or request handling function.

2. Step 2: Understand Flask request context rules

   The request object only works inside a request context, such as inside route functions. Accessing it outside causes a runtime error.

3. Final Answer:

   Accessing request outside request context causes error -> Option C

4. Quick Check:

   Request only valid inside route functions [OK]

Hint: Use request only inside route functions [OK]

Common Mistakes:

• Trying to use request globally
• Assuming request is always available
• Confusing import errors with context errors

5. You want to log the client's IP address for every request in your Flask app. Which code correctly accesses the IP using the request context inside a route?

from flask import Flask, request
app = Flask(__name__)

@app.route('/log')
def log_ip():
    # Fill in the blank
    client_ip = _____
    print(f'Client IP: {client_ip}')
    return 'Logged'

hard

A. request.client_ip

B. request.remote_addr

C. request.ip_address

D. request.headers['Client-IP']

Solution

1. Step 1: Recall how Flask exposes client IP

   Flask provides the client IP via request.remote_addr.

2. Step 2: Check other options for validity

   request.client_ip and request.ip_address do not exist. request.headers['Client-IP'] may not be set reliably.

3. Final Answer:

   request.remote_addr -> Option B

4. Quick Check:

   Client IP = request.remote_addr [OK]

Hint: Use request.remote_addr for client IP inside routes [OK]

Common Mistakes:

• Using non-existent attributes like client_ip
• Trying to get IP from headers directly
• Accessing request outside route