Yesterday our Product Manager faced a strange problem on his Windows 7 box. He created a site (which was a PHP application) but was not able to browse the site using http://localhost. He was getting HTTP status code 503 (Service not available). When I debugged his machine I found that following things hold true:
- Default Web Site was bounded to port 80.
- Virtual Directory for Default Web Site was configured correctly.
- Default Web Site was in START state.
- The application pool in which the Default Web Site was running was also in START state.
- IIS components like worker process, Windows Process Activation Service was running.
- PHP was installed.
- The handler mapping for PHP was correct.
- index.php was added to IIS Default Document list.
- IIS FastCGI was configured correctly.
- Browser settings for connecting within intranet was correct.
- Winodws hosts file at %windir%\system32\drivers\etc was having mapping from 127.0.0.1 to localhost.
- Site was getting displayed while using the URL http://127.0.0.1 as well as http://<machine_ip_address>.
This really surprised me and I scratched my head to figure out what the problem was. After lot of troubleshooting this is what I found:
- There is a concept of URL reservation in HTTP.sys. This means there is a way where you can reserve a URL with some security token. Now when a process tries to access the URL, the security descriptors of the process and one configured at the time of URL reservation are matched. if they do not match HTTP.sys denies access to the process. For details read the article at http://blogs.msdn.com/b/wndp/archive/2006/07/11/httpsys-reservations-and-service-sids.aspx.
- The next step was to find if the URL http://localhost:80/ was reserved or not. I ran the command ‘netsh http show urlacl’. Please run it from an elevated command prompt as an administrator. I did find that the URL http://localhost:80/ was reserved. The reason was because at some point of time (pre-Beta) IIS Developer Express used to reserve the URL. This bug has been fixed in WebMatrix Beta. However the point is that the URL was reserved with ACL which IIS process was not able to match and hence HTTP.sys denying access. The reason I am stating this is because it is important to understand which application is setting URL reservation and why before taking any corrective action.
- My next step was to delete the URL ACL as it is safe to do so in this situation (now that the bug is fixed in IIS Developer Express). Deleting the URL ACL was simple. From the same elevated command prompt just run the command ‘netsh http delete urlacl url=http://localhost:80/’. This commands deletes the URL reservation.
- Now open the browser and type http://localhost. Viola, one can see the IIS welcome page.
How it stuck me as a solution? Well, I was the one who filed this bug sometime back.
I hope this is going to help someone in a similar situation as hours of using various search engines didn’t yield any result. Thanks for the patient reading and till we meet again ‘Good Bye’.