Open
Description
Describe the bug
On Asp.Net Core 2.2, httpsys server does not automatically remove response body on HEAD request. This means the server will respond with mal-formed response. In the particular case where the HEAD request comes with "Connection: Close" header, server will response with "Connection: Close" header but does not close the connection on the server end. This causes the server to have too many open connections.
To Reproduce
Steps to reproduce the behavior:
- Use Asp.Net Core 2.2
- Create hello world Asp.Net Core project using "dotnet new web"
- Use HttpSys instead of Kestrel, as demonstrated in edit in Program.cs below
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseHttpSys()
.UseStartup<Startup>();
- Build with "dotnet build"
- Start the server with "dotnet run --no-launch-profile"
- In another console, curl a HEAD request
curl.exe http://localhost:5000 --HEAD -H "Connection: Close" -v
- Server responses with a body & Server TCP connection will be kept in CLOSE_WAIT indicating the server did not close the TCP connection.
* Rebuilt URL to: http://localhost:5000/
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 5000 (#0)
> HEAD / HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.55.1
> Accept: */*
> Connection: Close
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Server: Microsoft-HTTPAPI/2.0
Server: Microsoft-HTTPAPI/2.0
< Date: Sun, 13 Jan 2019 17:19:45 GMT
Date: Sun, 13 Jan 2019 17:19:45 GMT
< Connection: close
Connection: close
<
* Excess found in a non pipelined read: excess = 17 url = / (zero-length body)
* Closing connection 0
C:\work> netstat -an | findstr 5000
TCP 0.0.0.0:5000 0.0.0.0:0 LISTENING
TCP [::]:5000 [::]:0 LISTENING
TCP [::1]:5000 [::1]:5640 CLOSE_WAIT
TCP [::1]:5640 [::1]:5000 FIN_WAIT_2
Expected behavior
Either HttpSys should handle HEAD request automatically like Kestrel or it should respect "Connection: Close" header by closing the connection. It is very easy to NOT handle HEAD request.
Additional context
This issue is related to the following issue: #5881