HTTP 414 URI Too Long

HTTP 414 is URI Too Long: the target URI is longer than the server is willing to interpret (RFC 9110 section 15.5.15). It was Request-URI Too Long until RFC 7231. RFC 9110 calls it rare and names three causes: a client that turned a POST into a GET with long query information, a redirect loop whose URL grows with every hop, and an attacker probing for buffer overflows.

How long is too long

HTTP sets no maximum. RFC 9110 section 4.1 recommends that senders and recipients support URIs of at least 8,000 octets, and RFC 9112 section 3 recommends the same for the HTTP/1.1 request line. Each server picks its own limit, and they don’t all answer 414:

nginx          large_client_header_buffers 4 8k: request line over 8 KB    414
Apache httpd   LimitRequestLine 8190                                         414
IIS            maxUrl 4096, maxQueryString 2048                              404.14, 404.15
Node.js        16 KB for the request line and headers together               431
Go             MaxHeaderBytes, 1 MB by default, request line included        431

Node and Go count the URL toward their header limit, so an overlong URL gets a 431 Request Header Fields Too Large there. IIS reports its URL and query-string limits as 404 substatus codes.

Caching

414 is one of the few errors that is heuristically cacheable (RFC 9110 section 15.5.15): with no Cache-Control, a cache may store it and reuse it. The same URL is just as long next time, so that’s usually harmless, but after you raise the limit, a cache that stored the old 414 can keep serving it until it expires. Purge it, or send Cache-Control: no-store on 414s while the limit is in flux.

Fix the request, not the limit

• Long filters, ID lists or encoded JSON in a query string belong in a POST body. A search endpoint can accept POST /search with the filter as JSON.
• A URL that grows on each redirect is a loop, such as a login redirect that wraps its own ?next= parameter every time. Fix the redirect.
• Raise the limit only when long URLs are legitimate, and in every layer: the CDN, the proxy and the app each enforce their own.

large_client_header_buffers 4 32k;       # request line and each header field up to 32 KB

LimitRequestLine 16384

http.createServer({ maxHeaderSize: 32 * 1024 }, app).listen(3000);    // Node: request line plus headers

srv := &http.Server{Addr: ":8080", Handler: mux, MaxHeaderBytes: 64 << 10}

Search 414 431 in the tool below to compare the two.