URI Too Long
ActiveHTTP 414 URI Too Long indicates the server refuses the request because the target URI is longer than the server is willing to interpret. Defined in RFC 9110 §15.5.15. Previously named 'Request-URI Too Long.' Common server limits range from 4KB (Nginx) to 32KB (Cloudflare).
Description
The 414 URI Too Long status code indicates that the server is refusing to service the request because the target URI is longer than the server is willing to interpret. This condition is rare in normal practice but can occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a loop of redirection that appends query parameters on each cycle, or when the server is under attack by a client attempting to exploit potential security holes.
The HTTP specification deliberately does not define an upper limit for URI length — it is left to implementations. In practice, servers impose their own limits: Apache defaults to approximately 8,190 bytes, Nginx defaults to 4,096 bytes via its large_client_header_buffers directive, IIS allows up to 16,384 bytes, and Cloudflare imposes a 32KB ceiling. These limits exist both for performance (parsing and routing overhead) and security (buffer overflow prevention, hash-collision DoS protection).
Browsers also impose client-side URI length limits. Chrome handles URIs up to approximately 2MB, Firefox caps at around 65,535 characters, and legacy Internet Explorer was restricted to 2,083 characters. When a URI exceeds the browser limit, the request may be silently truncated or fail before reaching the server — a silent failure mode distinct from a 414 response.
The canonical fix is architectural: if your request requires more data than a reasonable URI can carry, use POST with a request body instead of GET with query parameters. For complex filtering APIs, consider accepting filter specifications in a JSON request body, using POST-based search endpoints, or implementing cursor-based pagination to avoid encoding large state in URLs.
A 414 response can also surface indirectly through cookie replay attacks where oversized cookies are reflected into URLs by middleware, recursive redirect loops that accumulate query parameters at each hop, or client-side URL builders that concatenate deeply nested filter expressions without length guards.
Examples
GET /api/search?filters=category%3Delectronics%26brand%3Dsamsung%26brand%3Dapple%26brand%3Dsony%26brand%3Dlg%26brand%3Dpanasonic%26price_min%3D100%26price_max%3D5000%26color%3Dblack%26color%3Dwhite%26color%3Dsilver%26features%3Dwireless%26features%3Dbluetooth%26features%3Dnoise-cancelling%26features%3Dwaterproof%26features%3D... HTTP/1.1
Host: api.example.com
Accept: application/jsonHTTP/1.1 414 URI Too Long
Content-Type: application/json
Content-Length: 187
{"error": "uri_too_long", "message": "The request URI exceeds the server's configured maximum of 8192 bytes.", "uri_length": 12847, "max_length": 8192, "suggestion": "Use POST with a request body for complex queries."}GET /api/reports/generate?payload=%7B%22start_date%22%3A%222024-01-01%22%2C%22end_date%22%3A%222024-12-31%22%2C%22metrics%22%3A%5B%22revenue%22%2C%22orders%22%2C%22customers%22%2C%22returns%22%2C%22margin%22%5D%2C%22dimensions%22%3A%5B%22region%22%2C%22product_category%22%2C%22channel%22%2C%22segment%22%5D%2C%22filters%22%3A%7B%22regions%22%3A%5B%22us-east%22%2C%22us-west%22%2C%22eu-west%22%2C%22apac%22%5D%7D%7D HTTP/1.1
Host: api.example.com
Authorization: Bearer token123HTTP/1.1 414 URI Too Long
Content-Type: application/json
{"error": "uri_too_long", "message": "Request URI is 24,576 bytes; maximum allowed is 8,192 bytes. This endpoint supports POST with a JSON body for complex report configurations.", "documentation": "https://api.example.com/docs/reports#post-generate", "max_uri_bytes": 8192, "received_uri_bytes": 24576}GET /auth/callback?state=abc123&redirect=/dashboard?tab=overview§ion=metrics&ref=login&utm_source=email&utm_medium=newsletter&utm_campaign=q4_2024&utm_content=hero_cta&session=prev_abc123&state=def456&redirect=/dashboard?tab=overview§ion=metrics&ref=login&... HTTP/1.1
Host: www.example.com
Cookie: session=xyz789HTTP/1.1 414 URI Too Long
Content-Type: text/html
Connection: close
<html><head><title>414 URI Too Long</title></head><body><h1>URI Too Long</h1><p>The requested URL's length exceeds the capacity limit for this server.</p></body></html>Edge Cases
- •Different servers have vastly different limits — a request that works on Apache (8KB) may fail on Nginx (4KB default). Always test against the actual deployment target, not local development servers.
- •Cookie replay attacks: if a cookie is set with a very long value and the server or middleware reflects it into a redirect URL, subsequent requests can trigger 414 — even though the client never intentionally constructed a long URI.
- •Recursive redirect loops that append query parameters at each hop will eventually hit the URI limit. The resulting 414 is a symptom — the root cause is the redirect cycle. Check for Location headers that preserve and duplicate existing parameters.
- •Client-side URL builders that concatenate array filters (e.g., ?id=1&id=2&id=3... for thousands of IDs) can silently approach the limit. The failure is intermittent — it depends on how many items the user selects.
- •CDNs and reverse proxies (Cloudflare, AWS ALB, Nginx) may impose stricter limits than the origin server. A request that reaches the origin in development may be rejected at the edge in production.
- •Base64-encoded tokens or state parameters in OAuth flows can push URIs past limits, especially when combined with other query parameters. This is common in SSO integrations with lengthy SAML assertions.
- •Some servers return 400 Bad Request instead of 414 for oversized URIs — the behavior is implementation-specific. Nginx returns 414 for URI overflow but 400 for oversized request headers via the same buffer mechanism.
When You'll See This
- →Search API receiving complex filter combinations encoded as query parameters instead of a POST body
- →OAuth/SAML callback URL where the identity provider appends a long base64-encoded assertion or state token
- →Single-page application encoding full application state in the URL for deep-linking and sharing
- →GraphQL over GET with large query strings (some CDNs only cache GET requests, forcing query-in-URL)
- →Analytics tracking URLs accumulating dozens of UTM parameters, referrer chains, and session identifiers across redirect hops
- →Bulk selection UI where selecting hundreds of items encodes each item ID as a query parameter
- →Misconfigured redirect middleware creating an infinite loop that appends parameters on each cycle
Implementation References
| Language | Constant |
|---|---|
| Go | http.StatusRequestURITooLong |
| Rust | http::StatusCode::URI_TOO_LONG |
| Python | http.HTTPStatus.REQUEST_URI_TOO_LONG |
| Node.js | http.STATUS_CODES[414] |
| .NET | HttpStatusCode.RequestUriTooLong |
| Java | HttpURLConnection.HTTP_REQ_TOO_LONG |
| PHP | Response::HTTP_REQUEST_URI_TOO_LONG (Symfony) |
| Ruby | :request_uri_too_long (Rack) |
History
Introduced as '414 Request-URI Too Long' in HTTP/1.1 (RFC 2068, January 1997) and carried forward in RFC 2616 (June 1999). Renamed to '414 URI Too Long' in RFC 9110 (June 2022) to align with modern terminology that distinguishes the target URI from the request line.
Related Status Codes
Related Headers
FAQ
What is the maximum URL length allowed by HTTP?
The HTTP specification (RFC 9110) does not define a maximum URI length — it explicitly leaves this to implementations. In practice, server defaults vary widely: Apache allows ~8,190 bytes, Nginx defaults to 4,096 bytes (configurable via large_client_header_buffers), IIS permits 16,384 bytes, and Cloudflare caps at 32KB. On the client side, Chrome supports URIs up to ~2MB, Firefox ~65,535 characters, and legacy IE was limited to 2,083 characters. For portable, safe URLs, keeping under 2,000 characters is a widely accepted guideline.
How do I fix a 414 URI Too Long error?
The preferred fix is architectural: switch from GET with long query strings to POST with a JSON request body. For search and filter endpoints, accept filter criteria in the request body rather than encoding them as query parameters. If you must use GET (for caching or idempotency reasons), implement cursor-based pagination to avoid encoding large state in the URL, use short parameter names, and consider a two-step pattern where the client POSTs the query to get a query ID, then GETs results by that ID. On the server side, you can increase limits (e.g., Nginx's large_client_header_buffers), but this treats the symptom rather than the cause.
Why does my server return 414 when the URL looks short?
Three common causes: (1) Oversized cookies — if a cookie is very large and gets included in the request, the total request header (including the URI line) can exceed the server's buffer. Nginx shares the same buffer pool (large_client_header_buffers) for both URI and headers. (2) Invisible redirect loops — middleware may be appending parameters on each redirect cycle, inflating the URL before the request reaches your application. Check your access logs for repeated redirects with growing URIs. (3) Proxy/CDN limits — a reverse proxy in front of your server may have a stricter URI limit than the origin. Always check the actual rejection point in your infrastructure.