Skip to content
This repository has been archived by the owner on Nov 20, 2018. It is now read-only.

Quirk with MapMiddleware when exception propagates outside of the branch #510

Closed
tuespetre opened this issue Dec 14, 2015 · 6 comments
Closed
Assignees
Milestone

Comments

@tuespetre
Copy link
Contributor

Here is a sample project:

https://github.com/tuespetre/aspnet-map-quirk

The issue may be reproduced with that project with the following steps:

  1. Run the application, using either dnx web or the IIS Express option from Visual Studio
  2. Load the page in the browser
  3. Click the button to send a request to the page that will raise an exception
  4. Send further GET requests to the page

The symptom is that, after having raised the exception, the PathBase of the request will be intermittently doubled up, resulting in broken links. Having stepped through the MapMiddleware's Invoke method, I can see that the context.Request.PathBase is already set to /aspnet-map-quirk coming into the middleware, even though the request URI shows properly as /aspnet-map-quirk when inspecting the Features collection on the HttpContext. I am not sure if this is due to faulty context recycling on part of Kestrel or not, as I don't know much about Kestrel -- perhaps @davidfowl or @DamianEdwards would have something to say here.

The workaround is to uncomment the following line:
https://github.com/tuespetre/aspnet-map-quirk/blob/master/AspNetMapQuirk/Startup.cs#L21

This prevents the exception from propagating out of the branch and subsequently causing the issue with the doubled-up PathBase.

A try ... finally block within MapMiddleware's Invoke method would ultimately guard against this issue.

@Tratcher Tratcher added the bug label Dec 14, 2015
@Tratcher Tratcher added this to the 1.0.0-rc2 milestone Dec 14, 2015
@Tratcher
Copy link
Member

@BrennanConroy Add the try/finally.

@halter73 Is kestrel failing to reset the Frame for unhandled exceptions?

I would expect symptoms like this if you were using the UseErrorHandler middleware that re-executes the pipeline.

@BrennanConroy
Copy link
Member

I don't see this issue in RC2, but I saw it in RC1

@Tratcher
Copy link
Member

The original repro may have been caused by Kestrel. What if you use the ErrorHandler middleware that re-executes? It should still cause this.
https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNet.Http.Abstractions/Extensions/MapMiddleware.cs#L62
Add the try/finally.

@BrennanConroy
Copy link
Member

c41be75

@tuespetre
Copy link
Contributor Author

Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants