search

aspnet / AspNetWebStack

ASP.NET MVC 5.x, Web API 2.x, and Web Pages 3.x (not ASP.NET Core)
Other
858 stars 354 forks source link

Bug: Rendering a layout of a layout causes lost HttpContext.Current.Session dictionary entries #186

Closed DerDreschner closed 6 years ago

DerDreschner commented 6 years ago

Hey guys,

I think I discovered a bug in the AspNetWebStack.

We use sitecore and would like to define a global skeleton for all pages for easier handling. Before that, we had to copy the layout several times instead of having one page.

To achive that, one example layout.cshtml looks like this: Layout.txt

and our _skelton.cshtml, which is included in several other layouts, look like this: _Skeleton.txt

We now have an issue with HttpContext in controllers and renderings in the skeleton. For example, the following line @Html.Sitecore().Rendering(Renderings.Metadata.PageTitle) starts a sitecore pipeline, in which we set the page title which is rendered in this place then. One of our processors check the HttpContext.Current.Session, if there is a value for the key "FormError". This works like charm as long as the rendering is rendered in the layout.cshtml. When we put it in the skeleton file, the dictionary entry of in the HttpContext.Current.Session isn't there anymore.

I checked the stacktraces and see that the only difference is the call of some WebPageBase methods, which look like they kill the HttpContext somehow. I'm not sure, but especially the PopContext() method looks suspicious to me.

image

Could you have a look at it if it's a bug or desired behavior?

Thanks!

Best reguards

dougbu commented 6 years ago

@dreschner what adds the FormError entry to the Session dictionary? That's definitely not MVC.

One possibility is your application has an ordering issue i.e. the FormError entry is added after _skelton.cshtml runs e.g. it's caused by something later in layout.cshtml. Another is that sitecore introduces some issues in this area.

Finally, ASP.NET MVC may intentionally save and restore HttpContext.Current around invoking the code where FormError is added. To remove that (if it's the problem here) would be a breaking change we cannot make at this point in the lifecycle.

mkArtakMSFT commented 6 years ago

Thanks for contacting us. We believe that the question you've raised have been answered. If you still feel a need to continue the discussion, feel free to reopen it and add your comments.