Yesterday I installed VS 2017 RC which quite messed up my previous environment (.NET Core was generally not working).
Most of the issues could be fixed by uninstalling the new .NET 1.1.0 SDK and reinstalling 1.0.1 but I have one issue remaining with Kestrel.
I have a Service Fabric application (with .NET Core Web API microservices) which ran without an issue previously but now I cannot get my REST API to work again. The request is taking really long and ends and I get this error in the debug console:
Microsoft.AspNetCore.Server.Kestrel: Information: Connection id "0HL0FNU42QORF" bad request data: "Malformed request: MethodIncomplete"
Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException: Malformed request: MethodIncomplete
Also sometimes I get this error:
Microsoft.AspNetCore.Server.Kestrel: Information: Connection id "0HL0FO6PO8FQ9" bad request data: "The input string contains non-ASCII or null characters."
Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException: The input string contains non-ASCII or null characters.
at Microsoft.AspNetCore.Server.Kestrel.Internal.Infrastructure.MemoryPoolIteratorExtensions.GetAsciiString(MemoryPoolIterator start, MemoryPoolIterator end)
at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame.TakeStartLine(SocketInput input)
at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame`1.<RequestProcessingAsync>d__2.MoveNext()
Microsoft.AspNetCore.Server.Kestrel: Warning: Connection processing ended abnormally
After a while I got the idea to create a new Service Fabric and later a Web API application by using the VS templates. Both result in the same error.
I have no clue what exactly is causing the error...
Maybe I had .NET Core 1.0.0 and not 1.0.1 installed before and this is causing the issue but I cannot imagine everyone having 1.0.1 installed having this issue. Strangely I couldn't find anyone else having the same issue.
Would suggest you are referencing Kestrel 1.1.0 which has stronger request validation?
I'm referencing 1.0.0 and I didn't change the Kestrel or any other references since the last time it worked.
Even when creating a new Web API project without modifying it I get this issue.
Referencing 1.0.1 or 1.1.0 doesn't help, same issue.
I guess it has to be an issue with my local machine somehow...
But I don't know which applications I could have to reinstall, I already removed VS 2017 RC by now.
@FelschR I've run into the same error with .NET Core WebApi and Kestrel, after installing VS2017 RC yesterday.
Surprisingly, the error only occurs if I call my API via localhost. If I use my external ipaddress (192.168.178.100) for requests against the API everything's working fine.
I also tried multiple .NET Core SDK as well as .NET Core Runtime versions. But, the error still stays.
My current assumption is that something is modifying the local requests. Also played around with fiddler and saw that request for localhost are always tried with https. The strange thing is that Kestrel got the encrypted message which obviously results in "Malformed request: MethodIncomplete". All request going to 192.168.178.100 are http as expected.
For now it's a workaround for me to just use my external ip-address instead of localhost for development and testing. But, I will investigate this as soon as I got some sparetime.
@reicheltp great (or not so much) to hear that I'm not the only one having this issue.
I didn't notice that external IPs work. Sounds like a great workaround for now!
Meanwhile I started to completely remove VS 2015 and all .NET development tools and reinstall it from scratch. I'll update this post once it finishes installing.
The "Repair" option for Visual Studio in "Programs and Features" also doesn't fix this issue.
UPDATE:
I've reinstalled everything (uninstalled via https://github.com/Microsoft/VisualStudioUninstaller) and very interestingly I still get this error.
Also I now noticed that the https behavior you described earlier also applies to normal .NET Web API projects running in IIS Express not just to .NET Core and Kestrel.
UPDATE 2:
OMG, this is so stupid. It seems that after the last Chrome update it redirects all localhost requests to https...
Unfortunately for testing my REST API I was using Postman which is a Chrome App and is thereby also affected... I could have noticed this much earlier...
Switching from localhost to 127.0.0.1 seems to work fine with Chrome.
UPDATE 3:
It seems to be a known Chrome behavior, although I'm not sure how this situation was caused for me:
https://bugs.chromium.org/p/chromium/issues/detail?id=444479
The trick is to delete "localhost" in "chrome://net-internals/#hsts".
Maybe Kestrel could throw a better error message for HTTPS requests when HTTPS is not enabled.
The better logging suggestion HTTPS requests when HTTPS is not enabled is a dupe of #1116. It was fixed in 1.1 by #1122.
Damnit Chrome! @FelschR thanks for the solution!
Most helpful comment
@reicheltp great (or not so much) to hear that I'm not the only one having this issue.
I didn't notice that external IPs work. Sounds like a great workaround for now!
Meanwhile I started to completely remove VS 2015 and all .NET development tools and reinstall it from scratch. I'll update this post once it finishes installing.
The "Repair" option for Visual Studio in "Programs and Features" also doesn't fix this issue.
UPDATE:
I've reinstalled everything (uninstalled via https://github.com/Microsoft/VisualStudioUninstaller) and very interestingly I still get this error.
Also I now noticed that the https behavior you described earlier also applies to normal .NET Web API projects running in IIS Express not just to .NET Core and Kestrel.
UPDATE 2:
OMG, this is so stupid. It seems that after the last Chrome update it redirects all localhost requests to https...
Unfortunately for testing my REST API I was using Postman which is a Chrome App and is thereby also affected... I could have noticed this much earlier...
Switching from localhost to 127.0.0.1 seems to work fine with Chrome.
UPDATE 3:
It seems to be a known Chrome behavior, although I'm not sure how this situation was caused for me:
https://bugs.chromium.org/p/chromium/issues/detail?id=444479
The trick is to delete "localhost" in "chrome://net-internals/#hsts".
Maybe Kestrel could throw a better error message for HTTPS requests when HTTPS is not enabled.