Reject the request before you read the upload

Upload endpoints have two different jobs. They decide whether a caller may submit work, and they inspect the artifact after it arrives. If the second job starts before the first decision, an unauthenticated client can make the service read and hold a body it will never accept.

That is an availability problem even when the application has perfect authentication. The backend may reject the request correctly, but the public proxy has already spent a worker, a socket, and upstream bandwidth. HTTP semantics allow an origin to respond before request content is complete; use that property deliberately.

The order matters

A defensible upload path makes its cheap decisions first:

1. Parse the request safely. Reject ambiguous framing, duplicate length fields, unsupported transfer coding, oversized headers, and unknown routes.
2. Check admission. Require the expected credential shape, confirm the caller and tenant, and check whether the service is entitled to accept work.
3. Reserve capacity. Apply global, per-tenant, and where necessary per-client concurrency limits before reading the body.
4. Read and validate the artifact. Enforce the body limit, deadline, filename and profile rules, then verify the digest.

The exact implementation varies. The invariant does not: a caller who cannot submit should not be able to make the upload path read a large body first.

Four useful limits

Size

Set a maximum request size at the edge, proxy, and application. The limits should be compatible and should fail before a buffer or worker grows to the largest value.

Time

Use an absolute deadline and a minimum ingress rate. A long maximum timeout protects a legitimate large file poorly if a sender can hold a connection open with almost no progress.

Concurrency

Keep expensive uploads out of the pool that serves static pages, health checks, and short control requests. Limit total submissions and each tenant or client separately.

Work

Limit the processing cost after the bytes arrive: file types, decompression, parsing, CPU time, output size, and any downstream calls. An upload limit is not a processing limit.

The review test

Send a request that has a valid path and a declared body, but no credential. Confirm that the service returns an authentication error without opening the backend stream and without waiting for the body. Repeat with a syntactically valid but invalid credential. Then hold several authenticated uploads open and verify that a normal page still responds within its normal budget.

Test the edge and the origin separately. A cloud control can buffer, rate-limit, or reject a request before it reaches the host, but the origin should remain safe when that control is misconfigured, bypassed by an internal caller, or changed during an incident.

What to record

• Which layer made each size, time, and concurrency decision.
• Whether the request was authenticated before body bytes were read.
• How many upload slots can coexist with static traffic.
• What happens when the backend is slow, unavailable, or returns an authentication error.
• The evidence and date for the limits you chose, including rejected and legitimate traffic.

How KernelHawk applies the lesson

KernelHawk reviews the path from the public listener to the application handler. We look at admission order, request framing, resource pools, deadlines, and what remains reachable when a downstream service is unavailable. The result is a short finding with a reproducible test, an owner, and a fix that can be retested.