Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

502 From Redirects on WebAPI/MVC On Same IIS Server #1954

Closed
RobertMcCoy opened this issue Mar 7, 2017 · 7 comments
Closed

502 From Redirects on WebAPI/MVC On Same IIS Server #1954

RobertMcCoy opened this issue Mar 7, 2017 · 7 comments

Comments

@RobertMcCoy
Copy link

RobertMcCoy commented Mar 7, 2017 •
edited

For the past few days I've been trying to solve this issue, but I can't ever seem to nail down what the exact problem is...

I have an MVC application and a Web API application hosted on the same IIS Website on a server. I have RedirectToAction() calls within the MVC application that are throwing 502 errors:

502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.

I have Integrated Windows Authentication enabled on the applications, and I am running WindowsIdentity.RunImpersonated() for all of the WebAPI calls so that the authentication is forwarded properly. I upgraded to 1.1.1 SDK today (I was using 1.1.0), as well as from VS17 RC2 -> VS17 Enterprise but that still hasn't fixed the problem.

The 502s are ONLY happening in my Create/Update actions on the MVC application (E.g. someone creates a new incident, and then is redirected to the view to see that specific incident, or that incident is updated and redisplayed). You can find code samples on my Stackoverflow thread (here), which has sadly died out and thus why I am here. I have exhausted all google searches to find issues not relevant to my specific case, or unrelated to IIS specifically.

I also can't even identify if this is a framework issue or an IIS issue, because the AspNetCore Module Logging says that the 302 Redirect goes through fine, and then a GET request to the view returns a 200 response. I have another 1.0.3 ASP.NET Core application running on the server that has never had this issue before.

If you need any more information please ask, this issue is driving me insane, and is the one thing holding this system back from going into production.

EDIT: I sat down and looked through the logs a bit closer and tracked an entire request from the Home/Index page all the way to the error. This is where I think the request is failing out. In a normal ControllerActionInvoker to the TIM.MVC.Controllers.IncidentsController.View, there is a ViewResultsExecutor that would execute ViewResults running at the View, but here after the 302 redirect, that doesn't seem to be happening. Any thoughts on why that may be?

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 POST http://snaptest.fwcs.k12.in.us/tim/Incidents/SaveIncident?incidentId=58 application/x-www-form-urlencoded 763
info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[1]
      Authorization was successful for user: FWCS\mccora01.
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
      Executing action method TIM.MVC.Controllers.IncidentsController.SaveIncident (TIM.MVC) with arguments (58, TIM.API.Models.Incident) - ModelState is Valid
info: Microsoft.AspNetCore.Mvc.Internal.RedirectResultExecutor[1]
      Executing RedirectResult, redirecting to /tim/Incidents/View/58.
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]
      Executed action TIM.MVC.Controllers.IncidentsController.SaveIncident (TIM.MVC) in 1397.8175ms
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 2097.562ms 302 
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://snaptest.fwcs.k12.in.us/tim/Incidents/View/58  
info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[1]
      Authorization was successful for user: FWCS\mccora01.
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
      Executing action method TIM.MVC.Controllers.IncidentsController.View (TIM.MVC) with arguments (58) - ModelState is Valid
@RobertMcCoy
Copy link
Author

I wanted to follow-up on this. I finally found the solution. I believe this is a bug within the framework. Local functions cannot be asynchronous if you use WindowsIdentity.RunImpersonated(). I converted my controller over to be 100% synchronous, and all issues went away with 502's.

@Tratcher Maybe you can confirm or deny if this is the case?

@Tratcher
Copy link
Member

Yeah, RunImpersonated is not async aware. It kills the impersonation as soon as you return the first Tasks, complete or otherwise.

@romansp
Copy link
Contributor

romansp commented Mar 16, 2017 •
edited

@Tratcher, so is there an opened issue in some dedicated repo that tracks this problem?

@Tratcher
Copy link
Member

@romansp no, it's not a bug in the API, it's a mis-use of the API. https://msdn.microsoft.com/en-us/library/dn906219(v=vs.110).aspx

It accepts a Func<T> and returns you the resulting T. In @RobertMcCoy's case the T was an incomplete Task, but he'd left the impersonation scope by returning.

You can file a feature request in https://github.com/dotnet/corefx for Task WindowsIdentity.RunImpersonatedAsync(SafeAccessTokenHandle, Func<Task>) and Task<T> WindowsIdentity.RunImpersonatedAsync<T>(SafeAccessTokenHandle, Func<Task<T>>)

@aspnet-hello
Copy link

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.

@davidalpert
Copy link

davidalpert commented Dec 30, 2017 via email

@davidalpert
Copy link

davidalpert commented Dec 30, 2017 via email

dougbu pushed a commit to dotnet-maestro-bot/AspNetCore that referenced this issue Sep 11, 2019
@analogrelay
add issue templates (dotnet#1954)
c1fc0c5
@ghost ghost locked as resolved and limited conversation to collaborators Dec 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@davidalpert @Tratcher @RobertMcCoy @romansp @aspnet-hello