Reject upgrade requests that also have content-length specified

[cesarblum]

aspnet/Security#1121 (comment) for explanation and context.

1.0.x behavior:

https://github.com/aspnet/KestrelHttpServer/blob/rel/1.0.3/src/Microsoft.AspNetCore.Server.Kestrel/Internal/Http/MessageBody.cs#L130

1.1.x behavior:

https://github.com/aspnet/KestrelHttpServer/blob/rel/1.1.1/src/Microsoft.AspNetCore.Server.Kestrel/Internal/Http/MessageBody.cs#L245

Let's argue whether this is a regression fix or a breaking change 😄 But we're likely to see more people having issues like the one above.

It doesn't help that nginx's own guidance is to force the Connection: upgrade header:

http://nginx.org/en/docs/http/websocket.html

I don't know why that's the case since just forwarding the client's Connection header using the $http_Connection variable seems more reasonable than that.

cc @muratg @Eilon @davidfowl

[davidfowl]

We should try out a few servers to see what their behavior is here.

[muratg]

@natemcmaster please ping @halter73 for context on this issue.

[natemcmaster]

Discussed with team. Let's leave this for 2.0. Doesn't seem urgent enough for a 1.1.x patch. As noted aspnet/Security#1121, this bug only appears when the client is sending an unusual combination of Upgrade and Content-Length.