Fix 'Request URL Too Long' (HTTP 414)
Why huge multi-select operations can hit HTTP 414, the two registry values that actually fix it — the web.config limits everyone raises first are not the problem — and why current installers make this rare.
At the end of this guide the 414 is gone — because you changed the two registry values that govern it, instead of the web.config limits that look responsible and aren't.
What's happening
Operations that carry many documents in one request — a Power Search selection of hundreds of items, legacy multi-select URLs with one parameter per document — can build request lines beyond what Windows' kernel HTTP driver (http.sys) accepts by default: 16 KB for the whole request line and headers. Exceed it and http.sys answers HTTP 414 before Content Central ever runs.
That "before Content Central ever runs" is the diagnostic gold: nothing appears in the ContentCentral event log, because the request never arrived. A user-reported 414 with a silent application log is this problem.
The fix — registry, not web.config
On the Content Central server, in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, set two DWORD values:
| Value | Set to |
|---|---|
MaxRequestBytes | 65534 |
MaxFieldLength | 65534 |
Then restart the HTTP service for http.sys to pick them up — practically, a server reboot at the next window (the HTTP service underpins all of IIS).
Why not web.config?
Because Content Central ships with the IIS/ASP.NET request limits (maxUrl, maxQueryString) already effectively maxed out — those settings govern a different layer, and http.sys rejects the request before that layer sees it. Raising them further is the natural first move and a guaranteed dead end; skip it.
Why you may never see this
Current Content Central installers set both registry values automatically. A 414 today usually means an older install that predates that, or a hardened server where policy management reset the HTTP parameters — in which case set them back as above, and mention the values to whoever owns the hardening baseline so the fix survives the next policy pass.
Success check: after the restart, re-run the operation that produced the 414 — it completes, and if you're collecting evidence, the request now reaches Content Central (the application log sees it).