Web API throws BadHttpRequestException #1217

Closed
FelschR opened this Issue Nov 18, 2016 · 6 comments

Comments

Projects
None yet
5 participants
@FelschR

FelschR commented Nov 18, 2016

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.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Nov 18, 2016

Contributor

Would suggest you are referencing Kestrel 1.1.0 which has stronger request validation?

Contributor

benaadams commented Nov 18, 2016

Would suggest you are referencing Kestrel 1.1.0 which has stronger request validation?

@FelschR

This comment has been minimized.

Show comment
Hide comment
@FelschR

FelschR Nov 18, 2016

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 commented Nov 18, 2016

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.

@reicheltp

This comment has been minimized.

Show comment
Hide comment
@reicheltp

reicheltp Nov 19, 2016

@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.

@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.

@FelschR

This comment has been minimized.

Show comment
Hide comment
@FelschR

FelschR Nov 19, 2016

@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.

FelschR commented Nov 19, 2016

@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.

@halter73 halter73 added the duplicate label Nov 21, 2016

@halter73

This comment has been minimized.

Show comment
Hide comment
@halter73

halter73 Nov 21, 2016

Member

The better logging suggestion HTTPS requests when HTTPS is not enabled is a dupe of #1116. It was fixed in 1.1 by #1122.

#1119 provided a clearer error message ("An SSL/TLS handshake might have been attempted on an HTTP endpoint.") based on the first byte of the request being 0x16, but we decided that wasn't generic. Now our error message is more in line with what you would see from nginx.

Member

halter73 commented Nov 21, 2016

The better logging suggestion HTTPS requests when HTTPS is not enabled is a dupe of #1116. It was fixed in 1.1 by #1122.

#1119 provided a clearer error message ("An SSL/TLS handshake might have been attempted on an HTTP endpoint.") based on the first byte of the request being 0x16, but we decided that wasn't generic. Now our error message is more in line with what you would see from nginx.

@halter73 halter73 closed this Nov 21, 2016

@EdgarSalazar

This comment has been minimized.

Show comment
Hide comment
@EdgarSalazar

EdgarSalazar Dec 4, 2017

Damnit Chrome! @FelschR thanks for the solution!

Damnit Chrome! @FelschR thanks for the solution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment