Microsoft’s latest Patch Tuesday update, released on June 9, 2026, arms Windows administrators with a new registry setting that caps the number of HTTP/2 and HTTP/3 request headers the kernel-mode HTTP.sys driver will accept. The change—christened MaxHeadersCount—is the company’s answer to a class of denial-of-service attacks that weaponize the complexity of modern header compression. For anyone running IIS or another Windows-hosted web service, the clock is now ticking: know your traffic’s header shape before the platform enforces its new default of 200.

The New Registry Knob: MaxHeadersCount

The setting arrives as a REG_DWORD under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters. Microsoft documents a default of 200, a minimum of 50, and a maximum of 65,535. The value only affects HTTP/2 and HTTP/3 requests; legacy HTTP/1.1 traffic is not subject to the count limit. Critically, the server must be rebooted after you create or modify the value—this is a machine-wide firewall, not a per-app dial.

If you’ve already set the older MaxRequestBytes limit, be aware that HTTP.sys may further adjust the enforced header count. Microsoft’s advisory notes that “depending on another existing setting MaxRequestBytes, HTTP.sys may further increase this header limit that is actually enforced.” The interplay means you should treat the two settings as partners, not substitutes.

Why a Header Count Limitation Now?

Windows has long offered byte-based throttles: MaxRequestBytes caps the total size of the request line plus headers, while MaxFieldLength restricts an individual header field’s length. Those tools fit an era when risk scaled with the number of bytes on the wire. HTTP/2 and HTTP/3 changed the equation. Their compression schemes—HPACK and QPACK—shrink the raw bytes but introduce stateful lookup tables that can balloon server-side processing.

An attacker can craft a request with hundreds of tiny, seemingly innocuous headers. Because the wire footprint is small, the request sails past byte-based defenses, but the server still has to parse, validate, and store each name-value pair. In a multiplexed, long-lived connection, this asymmetric workload can drain CPU and memory without triggering traditional flood alarms.

MaxHeadersCount shuts that door. It tells HTTP.sys, “No matter how cleverly compressed, I’ll only read this many headers.” The 200-header default reflects Microsoft’s opinion that legitimate HTTP/2 and HTTP/3 traffic shouldn’t routinely exceed that number. For most web applications, that’s plenty.

How the Change Looks from the Trenches

For IIS administrators, the knob is both a gift and a homework assignment. The gift: a single registry key that can drop abusive requests at the kernel boundary, long before they reach an application pool. The homework: you must now understand your request envelope. If your servers sit behind load balancers, WAFs, identity proxies, or observability agents, those layers each tack on headers. A request that leaves a browser with 15 headers might arrive at IIS with 60. Multiply across different internal call chains, and the 200-header ceiling can suddenly feel tight.

For developers, the limit is a forcing function. Modern application stacks are notorious for accumulating header cruft—tracing IDs, feature flags, tenant selectors, client hints, authentication tokens—all added by different libraries and infrastructure components. Nobody owns the aggregate. When a request starts returning 400 Bad Request errors with no obvious cause, developers will need to audit every layer that inserts a header. The fix may be to reduce the count, not to blindly raise the cap.

For everyday Windows users, the impact is likely zero. HTTP.sys is a server-side component, not something that runs on a laptop browsing the web. Unless you’re hosting a local web server—for example, a development machine running IIS Express—the update will be invisible.

The Hidden Legacy of HTTP.sys Tuning

Windows administrators have been tweaking HTTP.sys registry parameters since the days of IIS 6.0. The driver’s position beneath application frameworks makes it a powerful, if blunt, instrument. Changes to MaxRequestBytes or UrlSegmentMaxLength have solved—and occasionally created—many a production fire. MaxHeadersCount fits squarely in that tradition.

The difference is that this new knob targets protocol complexity directly. HTTP/1.1’s plain-text headers are easy to reason about; they’re just ASCII strings. HTTP/2 and HTTP/3 headers, by contrast, undergo compression and decompression steps that are themselves vulnerable to algorithmic pressure. The industry learned this with request smuggling and resource exhaustion attacks against competing web servers. Microsoft’s move mirrors similar limits already present in NGINX, Apache, and cloud load balancers. Windows Server is catching up to a defensive posture the rest of the industry adopted years ago.

What to Do Before You Touch the Registry

  1. Audit real traffic first. Capture a representative sample of requests hitting your web tier. Count the number of headers per request. Tools like Wireshark, Fiddler, or IIS Failed Request Tracing can reveal the actual header set.
  2. Map all header contributors. List every proxy, gateway, authentication module, and monitoring agent that inserts headers on the path from client to server. This includes internal hops that may not be obvious.
  3. Test in a staging environment with a realistic mix of browsers, API clients, and authenticated users. Set MaxHeadersCount to a conservative value (say, 150) and observe. Raise gradually if needed.
  4. Coordinate with load balancer teams. If your edge device already limits headers, your Windows host may never see a high-count request. Adjust the Windows limit to match or slightly exceed the upstream cap.
  5. Document the setting. When auditors ask why your IIS servers don’t choke on exotic requests, you’ll want a configuration record—not just a shrug about defaults.

Avoid the instinct to set MaxHeadersCount to 65,535. A sky-high value defeats the purpose and normalizes pathological request shapes. Remember that the reboot requirement turns this into a planned change, not a panic button. A misconfiguration can cause downtime that rollback alone won’t fix immediately.

Outlook: More Protocol Roadblocks Ahead

MaxHeadersCount is a single data point in a broader trend. As HTTP protocols become more stateful and compressed, server platforms will keep adding explicit, count-based limits. We should expect Microsoft to follow up with similar restraints on frame counts, table sizes, and setting sizes—all tuned to keep the kernel’s work bounded.

For now, the June 2026 update is a litmus test. Administrators who measure their traffic and set a deliberate value will harden their servers with minimal friction. Those who ignore the knob and hope for the best might not notice a problem until an attacker—or an overzealous observability tool—slams against the 200-header wall. Either way, Windows Server’s HTTP stack has just gotten less patient with the bloat that modern software keeps trying to sneak in.