The problem you've got is HTTP is at a lower level within the solution architecture than ASP.Net.
Hyper Text Transport Protocol - The key word is transport. The transport begins within the client internet browser and ends in your ASP.Net application.
ASP.Net is only aware of requests which make it all the way from the client, across the internet, into you hosting network, to your web server and then from your web server to the ASP.Net engine.
HTTP - 500 Internal Server Error
This is often caused by a bad configuration of IIS. If IIS is poorly configured then there's no way the request is going to get from the client to the ASP.Net engine. In which case the request life cycle won't begin, the relevant modules and handlers won't execute and your ASP.Net application including it HttpWebResponse object are going to be completely ignorant.
In IIS you can enable Failed Request Tracing. This will report any bad status codes returned by IIS even if they don't make it to the ASP.Net engine.
http://learn.iis.net/page.aspx/488/using-failed-request-tracing-rules-to-troubleshoot-application-request-routing-arr/[
^]
Once you've developed an understanding of the structure of this log you could write code to automatically read the log and report bad statuses in a more convenient way.
IIS also supports a technology called ISAPI (Internet Server Application Programming Interface). ISAPI layers are lower in the solution architecture than the ASP.Net engine.
The following outlines how to write a simple ISAPI layer. It is possible that adding your own ISAPI layer would allow you to capture HTTP status codes which would be missed by the ASP.Net engine but this is not a catch all.
http://blogs.msdn.com/b/rakkimk/archive/2007/03/01/writing-a-simple-isapi-filter.aspx[
^]
There are HTTP status codes for timeouts. If the timeout is caused by the clients local ISP then there's no way you're ever going to know about the request or the returned status code.
In a nutshell. You will never get all of the valid statuses listed for a HTTP request/response within the ASP.Net engine as HTTP covers area's well beyond the scope of responsibility of ASP.Net.
For this very reason, the enumerator doesn't need to contain all the HTTP status codes.