Any known issues regarding empty *.aspx pages with IIS7?

I have an IIS7 web application which primarily serves web service requests. As part of our solution we have two web servers and a load balancer, and the load balancer requests a page from each of its load balanced boxes periodically. The page the load balancer loads is named "Health.aspx", it does not have a code behind, and the entire contents of the file Health.aspx is:

OK

However we are observing occasional 400 errors from the load balancer when requesting this page throughout the day which causes the load balancer to eject the machine from its rotation for a period of time.

While there are potentially a number of things which could be causing a problem here I wanted to start at the web boxes themselves and determine whether a nearly empty *.aspx page with no code behind could cause periodic problems.

From stackoverflow

• You should create Health.html and just use that instead. That will also give you some idea of whether it's ASP.NET giving you the 400 problems or IIS.

  cfeduke : I have suggested this and hopefully we'll use this method to troubleshoot.

• "400 errors" covers a wide range of potential issues, from a simple not found 404 to bad request 401, and forbidden 403.

  Some of these could be caused by bad network cables, nics, lousy load balancer, overloaded server(s), etc.

  Incidentally, no, a web page with no code behind is not going to throw that. Also, I'd probably do a little something more in the health.aspx to verify that the server is actually functioning. Like run a calulation or make a simple database request. After all, IIS could simply be caching the file.

• Turns out that the problem was just the sheer number of requests and an untimely response time (or really request time - our client connections are very slow) for handling the requests. Requests for Health.aspx were getting caught up with slow client connections and the default MaxConcurrentRequestsPerCPU of 12 was artificially limiting our actual number of requests/second. Increasing this number to 100 - based on carefully testing our hardware against load for our particular application - solved the problem.