Skip to content
WindowsDeep Dive Published Updated 7 min readViews unavailable

Windows HTTP Server API and HTTP.sys: Queues, URL Namespaces, and TLS

Diagnose and design Windows HTTP services with HTTP.sys request queues, URL reservations, TLS bindings, and targeted netsh inspection commands.

Windows applications can accept HTTP traffic without each process opening and owning a listening socket. The HTTP Server API delegates protocol work to the Windows HTTP service, commonly called HTTP.sys, and lets applications register URL prefixes, receive requests from queues, and return responses. IIS uses the same underlying HTTP stack, but the API is also available to services and server applications that do not run inside IIS.

That shared kernel-mode listener changes how operators should troubleshoot a port conflict. A process list may not show an application bound directly to port 443 because HTTP.sys owns the listening endpoint and routes requests to a user-mode request queue. The useful evidence is the URL namespace reservation, active URL registration, SSL certificate binding, and queue state - not only netstat output.

Separate reservation, registration, and routing

The HTTP Server API has a layered ownership model. An administrator creates a persistent URL namespace reservation and access control entry. When the application starts, it registers the specific URL prefix that it intends to serve. HTTP.sys then routes matching requests to the request queue associated with that registration. Reservations survive reboots; registrations are recreated by applications at startup.

These are different failures. A missing or incorrect reservation can prevent the service identity from registering a URL. A valid reservation does not prove that the application is running or that a request queue is bound to its URL group. A registration conflict or a more-specific competing prefix can route traffic somewhere unexpected. Prefix matching includes scheme, host, port, and path, and HTTP.sys applies category-specific matching rules and the longest matching prefix within a category.

Use narrow URL prefixes and grant only the service identity that needs to register them. A broad wildcard such as http://+:80/ covers far more namespace than a named host and application path. It also makes routing ownership harder to audit when multiple services share the host. Treat netsh http add urlacl as an access-control change, not a harmless way to make an error disappear.

Inspect HTTP.sys state before changing it

Run these read-only commands from an elevated command prompt when the symptoms involve a URL or TLS binding:

netsh http show servicestate
netsh http show urlacl
netsh http show sslcert
netsh http show iplisten

show servicestate exposes active HTTP service state, including URL registrations and request queues. show urlacl reports persistent namespace reservations and their access control. show sslcert displays certificate bindings configured for HTTP.sys, and show iplisten helps determine whether a restrictive listen list is in effect. Save the output with a timestamp before making changes so the before-and-after state can be compared.

If a service cannot register a prefix, compare the exact scheme, host form, port, path, and identity in its configuration with the reservation. An explicit host name and a wildcard host reservation are not interchangeable in every routing case. Check for conflicting prefixes and inspect the process or service that owns the active queue. Do not delete every URL ACL or certificate binding to “reset” HTTP.sys; those entries may belong to IIS, a management agent, or another production service.

When a reservation is genuinely missing, an administrator can create a narrow one for the service identity, then verify it before restarting the application:

netsh http add urlacl url=http://+:8080/contoso/ user="CORP\ContosoSvc" listen=yes
netsh http show urlacl url=http://+:8080/contoso/

Replace the example identity and prefix with the service’s documented values; do not copy the wildcard host or port into a production reservation without reviewing the namespace impact. The service must still register its URL at startup, and its request queue must still be bound to the URL group. A successful ACL change alone does not establish that the application is listening correctly.

Request queues separate the kernel listener from workers

The HTTP Server API request queue is the boundary between HTTP.sys and the application. A server can configure a server session, create a URL group, bind that group to a request queue, register a URL prefix, and then receive parsed HTTP requests from the queue. Multiple worker threads can consume the same queue. With asynchronous calls, the application can associate the queue handle with an I/O completion port and process completions through a worker pool.

This design means a request can reach the kernel listener while the user-mode service is unhealthy or no longer draining its queue. Queue length, queue state, application health, thread-pool saturation, and response latency are separate signals. If clients receive failures or slow responses, correlate the HTTP.sys view with application logs, process health, completion worker utilization, and the exact URL prefix being requested. A successful TCP connection proves only that the network endpoint accepted the connection, not that the application produced a valid response.

The API supports queue-length and timeout properties. Set these from workload measurements and document why the values differ from defaults. A very large queue can turn overload into long tail latency and consume memory instead of applying backpressure. A too-small queue can reject a short burst that a healthy worker pool could otherwise absorb. Monitor both queue depth and completion latency under representative load.

TLS bindings are machine-wide HTTP service configuration

HTTP.sys can terminate TLS for an application using a certificate binding in its persistent configuration store. The certificate hash, certificate store, IP or hostname binding, and port must match the service’s expected configuration. The private key must be accessible to the service as required by the chosen hosting model. Certificate expiration, an incorrect thumbprint, a hostname mismatch, or an unexpected binding can cause a TLS failure before an HTTP request reaches the application code.

Inspect bindings with netsh http show sslcert and verify the certificate in the appropriate certificate store. Do not confuse an application’s certificate configuration with IIS Manager state: both may interact with HTTP.sys, and a change made by one management tool can affect another service that shares the kernel listener. Before adding or replacing a binding, record the current certificate hash, application identifier, endpoint, and client-certificate policy. Use a planned rollback path, especially on a shared server.

URL namespace ACLs and TLS bindings serve separate purposes. An ACL controls which identity can register a URL prefix; an SSL binding associates a certificate with an HTTPS endpoint. Creating one does not create the other, and neither validates the application’s authorization or request-handling policy.

A disciplined incident workflow

  1. Reproduce with the precise URL, scheme, host header, port, and timestamp.
  2. Capture show servicestate, show urlacl, show sslcert, and show iplisten before mutation.
  3. Identify the expected service identity, URL prefix, request queue, and certificate endpoint.
  4. Compare configured namespace and binding data with the live HTTP.sys state.
  5. Correlate kernel HTTP evidence with application health, logs, and worker-queue behavior.
  6. Change only the reservation or binding that the evidence identifies, then re-test both the failing route and other services sharing the host.

For developers, follow the documented HTTP Server API lifetime: initialize the API, create the server session / URL group / request queue objects needed by the chosen API version, bind and register prefixes, process requests, and remove registrations before closing handles and terminating the API. Handle ERROR_IO_PENDING as an asynchronous operation whose OVERLAPPED state remains live until completion. Do not free request buffers or close queue handles while outstanding operations can still complete.

HTTP.sys is a shared Windows service boundary, not merely a hidden socket. The combination of kernel-owned endpoints, persistent reservations, URL routing, request queues, and certificate bindings explains why accurate inspection matters more than indiscriminate restarts or global configuration resets.

Related:

Sources:

Comments