414 - URI Too Long
HTTP 414 URI Too Long means the target URI is longer than the server is willing or able to interpret.
Last reviewed: April 18, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does URI Too Long Mean?
The request target itself became too large for one hop to interpret. That usually means query state exploded, a redirect loop kept appending parameters, or a client pushed body-like data into the URL instead of the request payload.
Common Causes
- -SPA serializes large filter state into query string with hundreds of IDs, exceeding proxy URL length limit.
- -Redirect loop appends returnUrl repeatedly on each hop, causing URI growth until gateway rejects request target.
- -Legacy client places JWT in query parameter instead of Authorization header, pushing URI beyond server threshold.
- -A form or client accidentally converts what should be a POST body into a long GET query string.
- -Repeated encoding or nested
next/returnUrlparameters inflate the request target faster than the application expects.
How to Fix URI Too Long
- 1Move large query payloads to request body (for example POST with filter object) instead of expanding URI.
- 2Break redirect loops and eliminate repeated query-appending logic.
- 3Align URI length limits across edge and origin, then enforce client-side query-size guards.
- 4Replace long tokens or serialized objects in the URL with compact identifiers or server-side state references.
Step-by-Step Diagnosis for URI Too Long
- 1Capture the full request target and measure exact URI length at rejection point.
- 2Inspect redirect chain behavior for repeated path or query growth.
- 3Audit client URL builders for unbounded filters, nested state, or duplicated parameters.
- 4Compare maximum request-target settings across CDN, proxy, and origin to find the real rejection boundary.
- 5Retest with compact query representation and confirm endpoint behavior stays equivalent.
Seen in Production
- -A search UI serializes hundreds of selected IDs and nested filters into the query string, pushing the request target past the ingress limit.
- -An auth redirect keeps appending
returnUrlto an already encodedreturnUrl, causing exponential URI growth until the edge returns 414. - -A legacy client moves a large form submission from POST to GET during a flow change and sends the entire payload as query parameters.
- -A JWT or serialized state blob is placed in the URL for debugging convenience and silently outgrows one proxy tier before the app ever sees the request.
Request Target Growth Analysis
- -Trace URI expansion from client builders (example: dynamic filter UI serializes entire app state into query string).
- -Inspect encoded size inflation effects (example: repeated percent-encoding and long token parameters exceed parser limits).
Redirect and Request-Target Hygiene
- -Audit redirection loops that keep appending path/query segments (example:
/searchredirects to itself with cumulativenextparam). - -Compare maximum request-target settings between CDN, proxy, and app server (example: edge allows 16 KB, origin allows 8 KB).
Decision Shortcut: Big Query vs Redirect Loop
- -If the same route grows longer with each hop, prioritize redirect-loop or repeated-append logic before tuning limits.
- -If a single initial request is already huge, move state out of the URI and into the body or server-side storage.
- -If only one environment fails, compare edge and origin request-target limits before changing application behavior everywhere.
Wrong Fix to Avoid
- -Do not blindly raise one proxy or server URI limit if the request target is still pathological or another hop rejects it sooner.
- -Do not stuff body-like data into the URI just to avoid changing an API method or form flow.
- -Do not debug 414 like a backend latency issue; the request target is being rejected before normal endpoint handling.
Implementation Examples
2026-04-18T13:10:44Z edge=ingress requestId=req_77bd1c
uriLength=18432 limitBytes=8192 status=414
message="request target too large before upstream routing"curl -IL 'https://app.example.com/search?...' 2>&1 | rg '< location:|> GET 'large_client_header_buffers 4 8k;Incident Timeline
13:08 UTC
A client or redirect path starts growing the URI faster than expected
Signal: Filters, nested returnUrl params, or a POST-to-GET conversion begin inflating the request target.
Why it matters: The first useful question is what is making the URI grow, not whether the backend is slow.
13:10 UTC
One hop rejects the request target with 414
Signal: Edge, proxy, or application server refuses the URI before normal route handling can continue.
Why it matters: At this point the incident is about request-target length and redirect hygiene, not business logic.
13:11 UTC
Retries and redirects keep reproducing the same oversized URI
Signal: Clients or redirect chains resend the same too-long target or make it even longer on the next hop.
Why it matters: 414 incidents do not clear until the request target is shortened or the growth logic is fixed.
13:18 UTC
URI growth is contained and routing recovers
Signal: Query state moves into the body, redirect loops are broken, or compact identifiers replace oversized tokens.
Why it matters: That confirms the failure lived in URI growth and request design rather than in the endpoint itself.
Seen in Production
Search UI serializes too many filters into query string
Frequency: common
Example: Advanced search appends hundreds of selected IDs to URL, exceeding gateway request-target limit.
Fix: Send filter payload in request body and keep URL to stable short identifiers.
Redirect bug creates self-appending URL loop
Frequency: common
Example: Auth redirect adds returnUrl to an already encoded returnUrl, causing exponential URI growth.
Fix: Normalize redirect parameters and add loop guards with max redirect depth.
Form submission is accidentally converted from POST to GET
Frequency: medium
Example: A large form payload gets appended to the URL after a flow change, and the next hop rejects the oversized request target.
Fix: Keep large state in the request body and block body-to-query conversions in redirect or form helpers.
Wrong Fix vs Better Fix
Raise one limit vs fix URI growth
Wrong fix: Increase a single proxy or server URI limit and assume the problem is solved.
Better fix: Find what is making the request target grow and shorten or redesign it first.
Why this is better: A larger limit on one hop does not help if another hop still rejects the same oversized URI or if growth is effectively unbounded.
Keep state in query vs move it into the body
Wrong fix: Serialize huge filter objects, blobs, or form data into query parameters because it is convenient.
Better fix: Move body-like state into POST payloads, compact identifiers, or server-side references.
Why this is better: URIs are a poor place for large or fast-growing state and tend to fail unpredictably across proxies and browsers.
Ignore redirects vs audit loop behavior
Wrong fix: Focus only on the final request target and miss the redirect chain that keeps appending parameters.
Better fix: Trace the full redirect path and stop repeated query/path growth at the first append bug.
Why this is better: Many 414 incidents are caused by self-feeding redirect loops rather than one legitimately long first request.
Debugging Tools
- -curl --trace-ascii for raw request framing
- -Ingress proxy and redirect logs
- -Browser network trace for redirect chains
- -Request-target length histograms by route
- -Header and query-builder contract tests
How to Verify the Fix
- -Resubmit representative long-filter requests and confirm they route without 414.
- -Run URI boundary tests at documented maximum lengths across all environments.
- -Verify redirects no longer expand request targets over successive hops.
- -Confirm compact identifiers or POST payloads preserve the original user-facing behavior.
How to Prevent Recurrence
- -Set explicit request-target length budgets and enforce them in client builders.
- -Add redirect-loop detection and query-growth safeguards in edge routing rules.
- -Prefer compact identifiers over serialized objects in query parameters.
- -Add tests that fail when form flows or redirects accidentally convert large body state into long GET URLs.
Pro Tip
- -log request-target length histograms by route and alert when p99 approaches infrastructure limits to catch regressions early.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.