So if you're using someone else's app server, it may well be impractical to adapt it to use the preferred mechanism.) E.g., AFAIK, Tomcat is incapable of playing well with others, and insists on having port 80 all to itself. (And some popular app servers have this limitation. That may be fine - if you really don't want anything other than a particular process handling HTTP request on port 80, then it becomes tolerable to use an application server that fails to support the more flexible mechanisms offered by Windows. However, if an application server totally ignores this, then you're back in the less flexible old-school sockets world where only one process can receive requests destined for any particular port.
Each process can tell Windows which URLs it wants to handle. It's entirely possible to have any number of processes all receiving HTTP requests on port 80, because Windows has a built-in HTTP dispatch mechanism. This conflicts with a feature of Windows that is designed to enable multiple processes to handle requests on port 80. This problem arises when an application server wants total control of port 80. So it's worth understanding what's going wrong, because that leads to a better fix. If you just disable services that trigger the problem, chances are it will rear its head again in the future in a marginally different guise. the 'Web Deployment Agent Service'), this fails to address the root cause. Although people are pointing out specific services (e.g.
