By skyforbes 
To test log settings in a project, you often need to deliberately cause an error and generate an error log in the right location.
When I tried to test an HTTPERR log while setting up WSUS, I found it a bit challenging. Even when I specified an appropriate path and triggered a 404 error, no log was generated. I also wanted to avoid making unnecessary changes to server settings, which added to difficulty.
Conclusion
HTTPERR logs record errors from the HTTP requests that never reach thier intended application, such as when the request is malformed.
One of the easiest way to intentionally generate an HTTPERR log is to send a request with a header that exceeds the maximum allowed length for HTTP header.
The following Powershell script can send the malformed HTTP request with an oversized header, which will trigger an HTTPERR log.
$Headers = @{ "Large-Header" = ("A" * 100000) }
Invoke-WebRequest -Uri "http://<Wsus server ip addr>:8530/" -Headers $Headerspo
The maximum HTTP header length is not explicitly defined in the RFCs. Instead it depends on the specifications of the web server.
In IIS (or more specifically, HTTP.sys), this limit is controlled by registry keys.
By default, the total length of request line and header should not exceed 16 KB.
The primary goal of this article has been accomplished, but I would like to dive little deeper into what HTTPERR log is.
What is HTTPERR log?
As mentioned earlier, HTTPERR log is a log that records errors from HTTP requests that fail to reach the application (worker). These errors typically occur at an earlier stage of the request processing pipeline, often due to malformed or invalid HTTP requests.
This log is not specific for IIS itself, but more like one for HTTP.sys, which acts as the front end of IIS. As a result, the HTTPERR logs capture errors such as malformed HTTP requests that are dropped before they reach the IIS application layer.
This log records all errors that are not handed off to a valid worker process, typically responses to clients, connection time-outs, and orphaned requests.
What is HTTP.sys?
HTTP.sys is a Windows OS kernel-mode feature that handles HTTP requests and forwards them to the application running on IIS.
The reason why this configuration is managed through registry keys may be HTTP.sys is a core feature of operating system itself.
By default, IIS provides HTTP.sys as the protocol listener that listens for HTTP and HTTPS requests. HTTP.sys was introduced in IIS 6.0 as an HTTP-specific protocol listener for HTTP requests. HTTP.sys remains the HTTP listener in IIS 7 and later, but includes support for Secure Sockets Layer (SSL).
This feature is introduced in IIS 6.0 and its basic structure has not changed.
The architecture diagram below illustrates its functionality clearly.
IIS 6.0 includes a new HTTP listener (HTTP.Sys) that is implemented in the kernel. Requests are routed to one of the multiple worker process instances (W3wp.exe) that host ASP.NET applications and Web services.
HTTP.sys not only bridges HTTP requests to the application but also provides variety of convenient features as the front end for IIS, including caching, request queuing and filtering malformed HTTP requests.
This post is an English adaptation of my original Japanese blog post.