Using Kestrel stand-alone sometimes gives 404's

[Tragetaschen]

I thought I give Kestrel a try in beta8 on Windows. When I'm running from within Visual Studio through IIS Express, everything is fine, as is with running an Owin-based server stack on the command line. However, when I use Kestrel from the command line, I see reproducible 404's.

My application is as follows:

• An angular based SPA with static files being served to the browser
• A SignalR (the current 3.0.0 state) connection
• API requests to control the server and get additional data

After a refresh in the browser, everything is set up and the SignalR connection is running. The next POST request works and is handled correctly. If I "Edit and Resend" the request in Firefox, it will 404 as does any other request. This also happens in Edge.

When I'm in this state:

• If I navigate away in my SPA (which aborts the SignalR connection) and come back, the status is reset and I have one succeeding request
• If I refresh the page, I will also get a 404, but the next refresh succeeds normally
• If I wait long enough (keep-alive?) exactly one request again succeeds

I have included a middleware in the request pipeline both before and after the app.UseSignalR() call in Startup and this sees all the request and the valid and correct path (the first one that succeeds and the same second one that fails).

If it helps, here is the Request:

…POST http://localhost:5000/api/v1/U100/Spectrum/Stop
Host: localhost:5000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/json;charset=utf-8
Referer: http://localhost:5000/U100/Spectrum
Content-Length: 1
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

1

[kayle]

I'm seeing what is probably a related issue. dnx kestrel works fine from the command line, but when running through IIS inside Visual Studio I'm getting 404 responses. I debugged it to the point of finding that the HttpMethodConstraint was failing since the request Method was set to "{}GET". Not sure where the extra "{}" prefix came from. Guessing the problem is from Frame.TakeStartLine not being at the right position in stream.

Only started seeing this problem after upgrading from beta7 to beta8.

[Tragetaschen]

Yeah, that's it for me, too.

On further inspection on the HttpContext.Request.Method, it's POST for the first, succeeding request and 1POST for the non-succeeding second request (note the additional "1" before the POST).

[Tragetaschen]

This looks like the request body of the preceding POST.

Does Kestrel read the entire request body if it wasn't done by any component in the pipeline so the next request in a keep-alive connection starts fresh? My API method doesn't do any model binding, so there is no need for MVC to actually read any of the request body.

[HttpPost("Stop")]
public void StopAcquisition()

[GeorgeKnap]

When can we expect next release with this issue fixed?
Cheers

[Tragetaschen]

https://github.com/aspnet/Home/wiki/Roadmap

[aluitink]

Possible Workaround

[halter73]

@aluitink I just replied to your workaround with a more general one.