Is there an existing issue for this?

• I have searched the existing issues

What happened?

There is a public static setting DnnMvcHandler.DisableMvcResponseHeader (that resembles the MvcHandler.DisableMvcResponseHeader from ASP.NET MVC), but its value is used improperly and not always taken into consideration.

Steps to reproduce?

1. Set the value of DnnMvcHandler.DisableMvcResponseHeader to true at startup (e.g. in a IDnnStartup implementation).
2. Access a page that has a module that renders using MVC.
3. Look at the response headers from the page request, X-AspNetMvc-Version header will be present.

Current Behavior

There is no way to completely hide the X-AspNetMvc-Version header.

The value of DnnMvcHandler.DisableMvcResponseHeader is passed in to the ModuleApplication.DisableMvcResponseHeader private static property through its ModuleApplication(RequestContext, bool disableMvcResponseHeader) constructor, called from the DnnMvcHandler.GetModuleRequestContext(HttpContextBase). This would mean that it will be taken into consideration when making a direct HTTP request to an MVC route (not tested).

At the same time the ModuleApplication() : this(null, disableMvcResponseHeader: false) constructor is used by MvcHostControl to instantiate ModuleApplication objects to be used when MVC modules are rendered as part of the page. Because the disableMvcResponseHeader is hardcoded to false the value of ModuleApplication.DisableMvcResponseHeader static field is constantly pinged between the two values (false from MvcHostControl and DnnMvcHandler.DisableMvcResponseHeader from DnnMvcHandler).

Expected Behavior

I would expect, similar to how MvcHandler.DisableMvcResponseHeader works in ASP.NET, that the value of DnnMvcHandler.DisableMvcResponseHeader is always taken into consideration throughout the MVC rendering stack.

Relevant log output

Anything else?

I see two options:

1. Remove proprietary DnnMvcHandler.DisableMvcResponseHeader and ModuleApplication.DisableMvcResponseHeader properties and use MvcHandler.DisableMvcResponseHeader to decide. This would make DNN MVC be configured the same way standard ASP.NET MVC is. (Could be considered a breaking change if a 3rd party vendor tried to use the proprietary setting to disable the header).
2. Change public ModuleApplication() : this(null, false) { } to public ModuleApplication() : this(null, DnnMvcHandler.DisableMvcResponseHeader) { } to always default to whatever DnnMvcHandler.DisableMvcResponseHeader is set to. I would also make ModuleApplication.DisableMvcResponseHeader not static to avoid overwriting the value for other concurrent threads.

Let me know which of the solutions would you like more (or any other solution you can think of) and I will be able to create a PR with the fix.

Affected Versions

Current development branch (unreleased), 10.0.1 (latest v10 release)

What browsers are you seeing the problem on?

Chrome, Firefox, Safari, Microsoft Edge

Code of Conduct

• I agree to follow this project's Code of Conduct