HTTP request smuggling · YanoSec Academy

An HTTP request may pass through a frontend proxy before reaching a backend application. Both components need to agree on where each request ends. Message framing is the rule for finding those boundaries. If the components disagree, leftover bytes can be interpreted in a different request context; this is the basis of HTTP request smuggling.

Content-Length describes a body length in bytes, while HTTP/1.1 Transfer-Encoding describes transfer coding such as chunked. Their rules are protocol syntax, not visual page formatting. The supplied symbolic diagram marks two different end positions without constructing a request to send.

Before you begin

Recommended first: Notes: scope, command, result, time, HTTP methods, headers, status codes, cookies, How a web app is put together, Same-origin policy, Server-side template injection
Estimated time: 18 min reading, 12 min activity. Setup and optional practice may take longer.
Where you work: Read the original fictional source, object tables, token claims and policy models in any current desktop or mobile browser. No loader, template engine, provider registration, service or network request is required.
Without a lab: Follow the printed data through each stated rule on paper. Record the decision, its supporting fact and a limit, then compare with the guided rubric. Model reasoning does not establish a live tool result. Reading works without JavaScript. Checking requires JavaScript and a secure context; saving also requires usable storage.

After this lesson you can:

Define framing as the agreement on where a message ends.
Mark byte 40 and byte 28 on the diagram.
Choose the policy that rejects the message when those ends differ.

01Example

This fresh symbolic example demonstrates unequal request boundaries. The supplied guided diagram uses different end positions.

Reader One ends at byte 24.
Reader Two ends at byte 36.
Bytes 25–36 fall into different message contexts.
Model policy: reject the disagreement.
No request bytes or network capture are supplied.

02Disagree, then stop

The backend marks byte 28 as the end, while the frontend includes through byte 40. The disagreement leaves bytes 29–40 in different contexts for the two components. The diagram contains no second request and is not a packet capture; it demonstrates the boundary error rather than a working exploit.

Use protocol-compliant parsing that rejects ambiguous or malformed messages, and keep intermediary and backend framing behavior aligned. RFC 9112 gives specific precedence/error rules for HTTP/1.1; this card uses the stricter teaching policy that a detected disagreement is rejected and the connection is not reused for leftover bytes. HTTP/2 has different framing, but translation between protocols still requires correct boundaries.

Mark two different ends of one fictional message, and refuse to forward the leftover bytes as another request.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Reject the disagreement

136

Reader One24

Reader Two36

Reader One ends at symbolic byte 24.

Follow the explanation

Reader One ends at symbolic byte 24.
Reader Two ends at 36; positions 25–36 have different message contexts, so reject.

Read every state and value

1. Reader One ends at symbolic byte 24.

Selected Endpoint: one
Visible Endpoint: one
Disagreement Range: Not established
Decision shown: No

2. Reader Two ends at 36; positions 25–36 have different message contexts, so reject.

Selected Endpoint: Reader Two
Visible Endpoint: one · Reader Two
Disagreement Range: Start: 24; End: 36
Decision shown: Yes

Unequal framing boundaries are the modeled problem; these are positions, not a usable request or capture.

03Mark the ends

Read the evidence before comparing with the activity rubric. Send nothing.

One fictional message. Bytes are counted on this card, not captured from a network.

Positions 1 through 28: the request the backend accepts as complete.
Positions 1 through 40: the request the frontend accepts as complete.
Positions 29 through 40: inside the frontend's request and after the backend's request.

The card does not write a second request into those bytes.
The failure is that the two peers disagree on the end.

Download the byte diagram

Policy for a frontend and a backend that both see the same bytes.

If their end positions differ, both reject the message.
Neither peer forwards the leftover bytes as another request.
A font setting is unrelated to this decision.

Activity: mark the two end positions on framing-diagram.txt.
They are 40 and 28.

Download the parser policy

Write the frontend end and the backend end.
Write what the policy says to do when they differ.
Check: the ends are 40 and 28. Both peers reject the message, and neither forwards the leftover as another request.
Stop. Do not send an ambiguous message to a shared intermediary.

04Optional challenge

Say why both peers have to reject the message. The rubric is: if only one rejects it, the other can still treat the leftover as a request. About ten minutes.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Framing case A: new symbolic positionsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Frontend regards bytes 1 through 31 as one message.
Backend regards bytes 1 through 17 as one message.
Count positions inclusively; the diagram supplies no request bytes or second request.
Teaching policy: if detected end positions disagree, both peers reject and do not reuse leftover bytes.
No network traffic exists in this case.

Framing case B: independent agreementOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Frontend end: byte 52. Backend end: byte 52.
No information about other message validation is supplied.

06Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: derive an inclusive interval from distinct ends; apply consistent rejection without leftover reuse; distinguish boundary agreement from complete validity; retain symbolic provenance and avoid inventing request bytes.

07Common mistakes

If you write a second request into bytes 29 through 40, you left the card. The card does not do that.

If you pick a font setting, you left the byte counts.

If you treat the counts as a packet capture, they are labels on a diagram.

Check 1
Use case A. Which inclusive byte interval lies inside the frontend message but after the backend message? Give start-end using decimal integers and one ASCII hyphen, without spaces.
Format: Match the text, including capital and lowercase letters. Spaces at the ends do not matter.
Check 2
Use case A’s exact teaching policy. Which response to the detected disagreement follows?
Select one line.
- Both reject the message and do not forward leftovers as another request.
- Only frontend rejects while backend reuses any remaining bytes.
- Only backend rejects while frontend keeps forwarding leftover bytes.
- Keep both parses and change how byte labels are displayed.
Check 3
Use only case B. Which conclusion is supported?
Select one line.
- The peers agree on the boundary; this fact alone does not establish all message validity.
- Bytes 53-60 are proven to contain a second request.
- The peers disagree because identical numbers name different endpoints.
- Agreement proves the application’s authorization checks passed.

0 of 3 required checks answered.

Practice

Practice with the supplied advanced modelsExplain the untrusted input, the boundary and the fitting defense using only the original printed evidence. Record uncertainty instead of inventing a tool result.

References

RFC 9112: HTTP/1.1
Sections 6.2–6.3 define HTTP/1.1 transfer coding and body-length precedence/error handling. The symbolic diagram is not a complete request.
PortSwigger: HTTP request smuggling
Further explanation of this mechanism and its defenses. The original printed model supplies the required evidence.