Separate HTTP Continue admission from AI body approval

Choose one incoming request path

A fictional AI intake service accepts a small plain-text maintenance note for an already authenticated workspace. Before a cooperative client sends its body, the service can examine the method, route and complete header section. The reader’s question is which application path owns that decision, and which later gates still apply.

This worksheet selects the documented Node.js v24.16.0 built-in HTTP/1.1 server interface and one direct application listener L-A. It excludes intermediaries, HTTP/2 or HTTP/3, upgrades, other expectation values and TLS early data. It is a protocol/API review scope, not advice to deploy an unencrypted service.

The upload guide covers quarantine and later processing. This earlier boundary concerns an interim HTTP response and event routing. No listener, client, request or body is constructed here; all eight cards are PROPOSED_UNRUN.

Review the default before adding a listener

The selected Node HTTP reference documents checkContinue for a request carrying the 100-continue expectation. Without a listener, the server responds with 100 Continue as appropriate. Handling the event instead requires choosing writeContinue() or an appropriate HTTP response. Crucially, when it is emitted and handled, the ordinary request event is not emitted.

That last distinction changes an application review. Suppose authentication and body dispatch exist only in the usual request listener. Adding a custom Continue handler cannot assume that listener will subsequently supply those gates. A handler that merely writes the interim response has not demonstrated a complete intake path.

The proposed design assigns one trusted owner to the attempt. It invokes the required header admission and explicitly routes any admitted body into the complete body-review pipeline under the same attempt association. This is an implementation obligation, not code supplied here. Unknown registration, multiple competing owners or an unexplained route leaves the plan unadmitted.

Answer the header question without waiting for the body

RFC 9110 section 10.1.1 requires an origin receiving the applicable complete header section to send an immediate final response when determinable from those fields, or an immediate 100 response. It must not wait for content before sending 100. Section 15.2.1 describes 100 as initial receipt without rejection so far, not final success.

For route R-A, the application’s header-only gate H-A considers supported identity evidence, current route rights, permitted representation and declared-length policy, plus whether intake is available. A declaration within policy is not a measurement of received bytes. This guide supplies neither authentication nor header parsing or framing validation.

If a decision requires the content, keep that decision in the later body stage rather than silently waiting for it before Continue. If required setup cannot establish a supported complete path, withhold application dispatch and use a separately supported protocol disposition. “Held” is not permission to leave the client waiting indefinitely.

Preserve two later boundaries

The writeContinue() documentation describes sending an HTTP/1.1 invitation for the body. Our proposed ledger records that invitation separately from complete bounded intake, content/business validation and current action authorization. No model call, index write or other effect follows from the interim status alone.

RFC 9110 allows an expecting client to proceed without having received a response. It also requires a final status after content is received and processed, unless the connection closes prematurely. Therefore refusal of the invitation supplies no zero-body-arrival, bandwidth or resource-protection proof.

Independent limits must cover bytes already arriving, elapsed time, memory and subsequent processing. Their enforcement, and any supported connection close-or-read policy after early refusal, remain unimplemented prerequisites. This article gives no draining loop, socket disposal or automatic retry recipe. Unknown effect outcomes remain unknown; a later response cannot undo work already dispatched.

Write an attempt-owned admission sheet

The original sheet below uses labels only. It is not a request, event trace or executable configuration:

PROPOSED_UNRUN
Attempt: A-A / direct listener L-A / fixed note route R-A
Event owner: O-A / admitted registration and routing revision
Header disposition H-A: immediate supported decision
Continue disposition C-A: invitation only, if permitted
Body disposition B-A: initially unreceived / unvalidated
Action disposition W-A: no model work or effect yet
Final outcome F-A: separately recorded, never inferred from C-A

The positive keeps an ordinary note submission useful. If H-A, actual listener ownership, supported runtime, same-request routing and independent intake controls are established, the application may invite the cooperative client’s content. The body still needs its own complete review before any authorized next stage.

Actual runtime/build, effective event registration, trusted identity/parser behavior, current rights and bounded intake are unknown here. Those prerequisites block real admission until supported. No observed request reached any of these states.

Walk eight interim-response cards

State what the worksheet did not exercise

For these proposed cases, no server, listener, client, event, request, response, header, body, socket, timer, HTTP/TLS fixture or runtime experiment occurred. Documentation reads and private editorial file handling are separate. No latency, throughput, body-rejection or resource-ceiling result was measured.

Boundary is a prelaunch model router with planned request-path checks, not a shipped Node intake or approval engine. Its synthetic action exercise and existing mock evidence do not test Continue handling or this admission pipeline.