I've been running into a similar issue when I tried to run a simple http web application listening on port 80 written in Go (golang) on Windows 10 Home.
After doing some research I found out that for some reasons the "World Wide Web Publishing Service" (W3SVC) was running. Stopping and disabling the service solved my issue.
I never used this service. I guess a Visual Studio Community 2013 installation in the past installed and enabled this service. When I encountered the problem for the first time I thought it's a privilege issue as it's the case on Linux systems where applications listening on ports < 1023 must be run with root privileges. But in Windows 1023 this is not the case.
After all, finding this trivial issue costed me about 2 hours, that's why I post this answer to this rather old thread.
Basically this is a summary of what I did:
1) Google for the error message (as fully contained in the question of this thread).
- To many issues not related to my specific issues have been returned.
- I didn't find a concrete answer that solved my problem.
- However, I found hints for further analysis.
2) The first hint was using netstat.
netstat -o -n -a | findstr 0.0.0.0:80
netstat -o -n -a | findstr 127.0.0.1:80
It turned out that the process with Id 4 was listening on port 80.
3) Lookup Process #4 on the Details tab in the Taskmanager.
This showed that System (NT Kernel & System) is involved.
4) Trying to access port 80 on localhost using PUttY with Telnet to port 80.
(make sure to set **Closing on exit* to never)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Verb</h2>
<hr><p>HTTP Error 400. The request verb is invalid.</p>
</BODY></HTML>
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Thu, 05 Oct 2017 13:13:29 GMT
Connection: close
Content-Length: 326
5) The information collected so far didn't provide a concrete hint but allowed me to do more specific searches on Google. Now the information returned from Google indicated that most likely some kind of system services listening on port 80 might be the source of the issue.
6) Now it was easy to look for such running services in the service manager. The first one I found that could likely be the source of the issue (as it contained WWW in its name) was "WWW-Publishingdienst" (on my computer in German) which stands for "World Wide Web Publishing Service" on systems with English language settings. I stopped the service and - Voila! It was the cause of the issue.