411 - Length Required
HTTP 411 Length Required means the server requires a defined Content-Length for this request.
Last reviewed: February 10, 2026|Editorial standard: source-backed technical guidance
What Does Length Required Mean?
The server rejects this body-bearing request before processing because message length is not explicitly provided in the form this endpoint requires.
Common Causes
- -Client sends chunked body without Content-Length, but upstream requires fixed length for request signing logic.
- -Gateway policy enforces Content-Length on POST and PUT for quota accounting and rejects missing header.
- -Upload service pre-allocates buffers from declared length, so absent Content-Length fails early validation.
How to Fix Length Required
- 1Send an accurate
Content-Lengthfor body-bearing requests when endpoint policy requires it. - 2Ensure transport layers do not drop or rewrite length metadata during retries and proxy hops.
- 3If streaming is required, verify server and intermediaries support the chosen framing model consistently.
Step-by-Step Diagnosis for Length Required
- 1Capture raw request bytes and verify
Content-Lengthheader presence, format, and numeric accuracy. - 2Compare client framing behavior with gateway/origin rules for body-bearing methods.
- 3Inspect intermediaries for transfer transformations that invalidate or remove declared length.
- 4Retest with a small deterministic payload and validated
Content-Lengthcalculation.
Message Framing and Length Integrity
- -Verify header length matches actual payload byte count (example: UTF-8 body counted as characters instead of bytes causes mismatch).
- -Check request-building libraries for late body mutations after length is computed (example: middleware appends JSON field post-serialization).
Proxy and Transfer-Encoding Compatibility
- -Trace proxy behavior that strips
Content-Lengthduring replay or buffering (example: edge retry path removes length header on POST). - -Audit
Transfer-EncodingversusContent-Lengthhandling consistency (example: origin requires fixed length, intermediary converts to chunked stream).
Implementation Examples
curl -i -X POST https://api.example.com/v1/resource -H "Content-Type: application/json" -d "{"sample":true}"
# Response:
# HTTP/1.1 411 Length Required
# {"error":"Length Required","code":"411"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'POST',
headers: { 'Content-Type': 'application/json', 'Accept': 'application/json' },
body: JSON.stringify({ sample: true })
});
if (response.status === 411) {
console.error('Handle 411 Length Required');
}import requests
response = requests.post(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json', 'Content-Type': 'application/json'},
json={'sample': True}
)
if response.status_code == 411:
print('Handle 411 Length Required')How to Verify the Fix
- -Repeat the request and confirm 411 is cleared when length metadata is valid and preserved.
- -Validate body framing behavior across direct, proxied, and retried request paths.
- -Monitor parser errors for residual length/framing mismatches after rollout.
How to Prevent Recurrence
- -Use client libraries that consistently set Content-Length for buffered payloads.
- -Add gateway regression tests for framing and Content-Length preservation.
- -Alert on spikes in length-related request parsing failures.
Pro Tip
- -serialize payload once, freeze the byte buffer, and compute
Content-Lengthfrom that immutable buffer to avoid race-condition mismatches.
Decision Support
Compare Guide
HTTP 400 vs 422: Bad Request vs Unprocessable Content
Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Playbook
Validation Failure Playbook (400 / 422 / INVALID_ARGUMENT)
Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.