# 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.

Product: content-central · Versions: 7.x · Audience: system-administrator · Time: 15 minutes · Last verified: 2026-09-05

Canonical: https://help.ademero.com/content-central/administration/fix-request-url-too-long-http-414

**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).

## What's next

- [The login page won't open](https://help.ademero.com/content-central/administration/login-page-wont-open)