20

Our Linux Docker ASP.NET Core container server logs are getting filled by the following 'Informational' log entries since we've updated from .NET Core 2.0 to .NET Core 2.1 (SDK 2.1.302):

INFO|Microsoft.AspNetCore.Server.Kestrel|Connection id "0HLFG42JUAORG" bad request 
data: "Invalid request line: 
'CNXN\x00\x00\x00\x01\x00\x00\x04\x00\x1B\x00\x00\x00M\x0A'" 
Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Invalid 
request line: 'CNXN\x00\x00\x00\x01\x00\x00\x04\x00\x1B\x00\x00\x00M\x0A'

INFO|Microsoft.AspNetCore.Server.Kestrel|Connection id "0HLFG42JUAORH" bad request 
data: "Invalid request line: 
'CNXN\x00\x00\x00\x01\x00\x00\x04\x00\x1B\x00\x00\x00M\x0A'" 
Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Invalid 
request line: 'CNXN\x00\x00\x00\x01\x00\x00\x04\x00\x1B\x00\x00\x00M\x0A'

The connection ID is incrementing by 1 alpha/digit every second or so. The hex doesn't seem translate to anything meaningful (NUL NUL NUL SOH NUL NUL EOT NUL ESC NUL NUL LF).

Things we've ruled out:

  • It's not originating from WAN/LAN (disabled network access to the containers and the entries are still being generated).
  • It doesn't occur in our development environment (windows w/ Visual Studio)
  • Redeploying the docker container doesn't fix the issue.
  • We don't believe it to be an SSL issue since kestrel is configured for http only. We can access the app and it's websockets (SignalR) over https and wss
Vy Do
  • 46,709
  • 59
  • 215
  • 313
Yang
  • 483
  • 1
  • 5
  • 9
  • 4
    *kestrel is configured for http only* maybe that's the problem, something trying to talk to it with HTTPS on port 80? https://github.com/aspnet/KestrelHttpServer/issues/1321#issuecomment-274893813 – ta.speot.is Jul 23 '18 at 03:14
  • We've ruled that out by disabled all network connectivity to the container, but it's still appearing. – Yang Jul 23 '18 at 03:24
  • Look at a Proxy or Firewall you have set up between your “WebClient” and “WebServer” . think about the typical browser to server communication lifecycle such as OpenConnection GET – Response Comes back – close Connection. Look for a firewall or a very common protocol assumption that would be true 90% of the time – but is not true in your case that is failing. For example – HTTP2.0. The problem is probably below your code in the common Network Lifecycle. Some Firewalls are stricter by default then you may need – you may have to allow the “bad” command at a proxy or firewall level. – Sql Surfer Jul 23 '18 at 04:04
  • How confident are you that your Windows Dev infrastructure and containers build process is also working in your LINUX Container Environment. Do you have a primitive hello world scenario that proves your two environments are building working containers for the full network round trip path in both environments - using .Net Core 2.1 and or 2.0 – Sql Surfer Jul 23 '18 at 04:10

3 Answers3

32

It looks like you're hitting an HTTP endpoint over HTTPS.

Gurgen Sargsyan
  • 1,087
  • 15
  • 22
5

Turns out it was an issue with the docker host (debian) and hanging sockets (netstat showing a lot of TIME_WAITs). Changed the app port to a different one and the malformed requests stopped.

A reboot or restart of the docker daemon would probably also fix it, but the uptime of our other containers is vital so we weren't able to test that.

Yang
  • 483
  • 1
  • 5
  • 9
1

I had same problem and in my case solution was in nginx configuration - I had proxy_pass set to https://localhost:4000 instead of http://localhost:4000

Radosław Adamczewski
  • 11
  • 1