Prompt and setting
The server refuses to interpret a request target because its URI is longer than the configured limit. The failure can originate in client serialization, redirect loops, cookies or a proxy boundary, so raising one server limit may not solve it.
What the interviewer tests
- Locating which request component exceeded which hop’s limit.
- Preserving HTTP method semantics when moving data from a URI to a body.
- Designing bounded, observable query contracts instead of accepting arbitrary URLs.
Clarifying questions before answering
- Is the length in the path, query, redirect location, or an encoded client state blob?
- Which hop returns 414: browser, CDN, load balancer, gateway, or origin?
- Is the operation safe and cacheable, or does it mutate state?
- Do clients need shareable URLs, bookmarkability, or privacy for the filter set?
30-second answer framework
I would capture the request target length and hop that generated 414, then inspect redirects, cookies, encoding, and filter serialization. For a read-only search with an oversized filter set, I would use a bounded POST search endpoint or a short-lived server-side query token, document limits, and preserve authorization. I would not simply raise one proxy limit without testing every hop and checking log and cache implications.
Step-by-step deep dive
1. Measure the actual request target
Log a safe length metric, route template, redirect count, and correlation ID without logging sensitive query values. Compare browser, CDN, gateway, and origin limits. A base64 state blob, repeated parameters, or an accidental redirect loop can grow the URI before application code runs.
2. Preserve method and cache semantics
GET is safe and naturally cacheable, but a URL is not an unlimited data transport. Moving a large filter set to POST changes cache and bookmarking behavior, so define an explicit endpoint, response cache policy, and idempotency expectations. Do not use POST merely to hide a mutation behind a search route.
3. Bound and normalize filters
Set limits on number of predicates, value length, nesting depth, and total encoded bytes. Reject malformed or duplicate parameters consistently. Canonicalize equivalent filters so caches and signatures do not treat trivial ordering differences as different requests.
4. Use a query token when shareability matters
Store a normalized filter object server-side with a short TTL, tenant and user authorization, and one-time or scoped retrieval. Return a short token that can be placed in a URL. Never put secrets or raw personal data into the token or query string; enforce expiration and revocation.
5. Treat 414 as an operational signal
Alert on rate by route, client version, and proxy hop. Track redirect chains and deploy changes that alter serialization. A safe fallback can ask the user to reduce filters or submit the form through the body endpoint; it should not silently truncate criteria.
High-quality sample answer
“I would first measure the target length and identify which hop produced 414, then inspect redirects, cookies, encoding, and repeated filters. For a read-only search whose filter set exceeds URL limits, I would add a bounded POST search endpoint or an authorized short-lived query token, with explicit cache and audit semantics. I would cap predicates and encoded bytes, never truncate silently, and monitor 414 rates by route and client version. Raising one proxy limit is only a coordinated, tested change across every hop.”
Common mistakes
- Increase the origin limit only → CDN or gateway may still reject → measure and configure every hop.
- Move data to POST without discussing cacheability → clients lose expected semantics → define cache, sharing, and idempotency behavior.
- Truncate oversized filters → the result no longer answers the user’s query → reject clearly or use a bounded alternate endpoint.
- Put secrets in a query token → URLs leak through logs and referrers → scope, expire, and authorize opaque tokens.
Follow-up questions and responses
Is 414 caused only by query strings?
No. The request target includes the path and query, and redirects can create an oversized target. Cookies affect header limits rather than the URI itself, so the diagnostic must identify the exact rejected component.
Should every large GET become POST?
No. Keep GET for ordinary safe, cacheable reads. Use POST for a deliberately defined search contract when the request representation cannot fit practical URI limits, and document the changed cache and sharing behavior.
Why not increase all limits dramatically?
Large targets consume parser, logging, cache, and security resources and may create inconsistent limits between hops. Raise limits only with measured need, coordinated configuration, and abuse testing.