The direct answer
Require a supported receiver to establish the complete HTTP request boundary before treating extracted bytes as an admitted document. Keep framing, content validation and action authorization separate, and give rejected or incomplete messages a supported connection disposition rather than assuming that an application error makes reuse safe.
Ask which bytes belong to this request
A fictional maintenance assistant accepts one small note on a fixed authenticated route. The note may later become model context. Checking its JSON or text is too late to establish whether the HTTP receiver assigned those bytes to the intended request.
The separate Continue guide concerns an interim invitation. The JSON guide starts with an already-extracted body. This earlier worksheet concerns message delimitation and the connection after rejection; neither later gate repairs a framing disagreement.
Select one direct HTTP/1.1 receiver, one owner O-A and one fixed note route R-A. Intermediaries, upgrades, CONNECT, HTTP/2, HTTP/3, early data and Expect handling are outside this profile. It does not prove agreement across a proxy chain. Actual supported transport and receiver behavior remain prerequisites, not observations about a deployment.
Separate standard framing from local route policy
The source profile is RFC 9112 and RFC 9110, both June 2022 Standards Track documents. RFC 9110 defines Content-Length in decimal octets and requires protection against conversion overflow. Its identical-value comma-list exception permits rejection or replacement with one value. Those options are not a universal ban on every duplicate length.
Our proposed route is stricter: one Content-Length field containing one valid decimal value, no repeated length declarations, no comma list and no Transfer-Encoding. It also requires a nonempty note within a separately enforced body limit. These are application admission choices, not a replacement HTTP specification.
Rejecting transfer-coded submissions at this route does not mean disabling required HTTP parsing capability: RFC 9112 requires recipients to understand chunked coding. Do not build a competing splitter around the application body stream. The maintained receiver must own framing and expose enough trustworthy evidence for the chosen route policy.
Review failure disposition along with the body boundary
Under RFC 9112, Transfer-Encoding overrides Content-Length when both appear; servers may reject or process that request but must close after responding. Invalid length without transfer coding requires 400 and closure, subject to the identical-list exception. A valid length defines the expected octets; premature closure or timeout makes the message incomplete and requires closure. With neither delimiter, a request has zero body length; requests are not close-delimited. RFC 9112 sections 6.1–6.3.
For persistence, a server must read the entire request body or close after responding. RFC 9112 section 9.3. Therefore “the application returned an error” is not enough evidence that the remaining connection is reusable.
This worksheet selects rejection and supported connection closure for profile failures rather than an application drain-and-reuse path. That conservative choice is not a socket recipe or a promise that an error response reaches the client. Actual maintained receiver ownership, response/closure handling and failure reporting must be reviewed together. Unknown behavior blocks admission, even when a higher-level middleware reports an ordinary error.
Preserve evidence before normalization hides it
RFC 9110 sections 5.2–5.3 describe repeated field lines and combined values; the whole request header section must arrive before applying the request to the resource. A convenient one-value header dictionary is not automatically evidence that the original input satisfied this stricter no-duplicates policy.
Require a supported receiver contract that can attest to the selected framing decision and original policy-relevant multiplicity. If an earlier component normalized duplicate lengths and discarded that evidence, do not invent it from the final number. The actual route stays unsupported until its admission boundary can be reviewed. This is an implementation requirement, not a parser API supplied by these RFCs.
Keep minimized decisions for attempt A-A: receiver/profile revision, original-field policy disposition, expected and received body-length status, complete/incomplete result, connection disposition and current route authorization. Avoid logging full headers, credentials or note content. The labels are invented and describe no captured traffic.
Walk eight inert framing cards
Every card is PROPOSED_UNRUN. Conditions are prose descriptions, not raw requests or executable fixtures.
| Card | Proposed condition | Decision |
|---|---|---|
| 1. Ordinary note | One valid declaration; complete bounded content; actual O-A/R-A prerequisites established. | Conditionally release only to the normal content/business gates. |
| 2. Competing framing | Length and transfer coding both offered. | Reject under this profile and use the documented closure disposition. |
| 3. Conflicting lengths | Different repeated length values. | No body release; apply the documented invalid-framing treatment. |
| 4. Matching duplicates | Identical repeated values, or only a normalized result remains. | Local policy rejects duplicates; missing original evidence cannot attest eligibility. |
| 5. Invalid length | Value fails length syntax, conversion support or the route limit. | Reject; distinguish framing invalidity from a valid but locally excessive size. |
| 6. Transfer-coded note | Otherwise valid transfer coding is requested. | Outside route policy; no decoder fallback or claim that chunking is inherently invalid. |
| 7. No body delimiter | No length or transfer coding for this note route. | Zero-length request body; reject the missing required note, not wait for EOF. |
| 8. Incomplete or unknown | Declared content is incomplete, or receiver/evidence/closure ownership is unknown. | No partial note release and no presumed safe connection reuse. |
Keep a useful positive conditional
The ordinary positive is a short maintenance note from an authorized viewer. If the actual maintained receiver, original framing evidence, complete bounded intake and supported lifecycle are established, the body may proceed to its usual content checks. Current object rights, trusted identity, representation policy and processing resource limits still apply. None is implemented by this worksheet.
No request, header, body, socket, parser, client, server or runtime fixture was constructed or exercised. No smuggling test, model call or security outcome was measured. Boundary remains prelaunch with planned request-path checks; this article does not describe a shipped HTTP receiver or request-smuggling defense.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.