4

When running DD4T on my local development machine I can access the pages that I have published.

  • www.mywebsite.com - Works
  • www.mywebsite.com/index.html - Works
  • www.mywebsite.com/aboutme.html - Works

When I deploy my website to the server, I can only access www.mywebsite.com as soon as I put index.html at the end I recieve a 404.

  • www.mywebsite.com - Works
  • www.mywebsite.com/index.html - Does not work
  • www.mywebsite.com/aboutme.html - Does not work

In the event logs I don't see any other then the 404 and the Tridion logs on debug only say 404 can't find page index.html or aboutme.html In the web.config I can change the default page to aboutme.html that works but again if I go to it directly www.mywebsite.com/aboutme.html I recieve the 404.

When I create a helloworld.html on the server I am able to get that page without receiving any errors.

PageController:

public class PageController : TridionControllerBase
{
    public override ActionResult Page(string pageId)
    {
        try
        {
            pageId = UriHelper.ParseUrl(pageId);

            return base.Page(pageId);
        }
        catch (Exception)
        {
            return PageNotFound();
        }
    }

    private ActionResult PageNotFound()
    {
        Response.StatusCode = 404;
        Response.TrySkipIisCustomErrors = true;

        return base.Page("ErrorPage404.html");
    }
}

RouteConfig:

/* Route: TridionPage
 * Default route that being used for all Tridion pages.
 */
routes.MapRoute(
    name: "TridionPage",
    url: "{*PageId}",
    defaults: new { controller = "Page", action = "Page", id = UrlParameter.Optional },
    constraints: new { pageId = @"^(.*)?$" }
);

/* Route: Default
 * Overwritten the "Default" towards the TridionPage Route, this will then return a nice404.
 */
routes.MapRoute(
    name: "Default",
    url: "{controller}/{action}/{id}",
    defaults: new { controller = "Page", action = "Page", id = UrlParameter.Optional }
);
  • 1
    Sounds like something not quite right with how your handlers are configured on the server. I suspect it's hitting the static file handler. Is it an IIS 404 or an ASP.NET 404? Is there a different version of IIS or MVC between the two systems? Maybe post the exact error? Can you see anything in the cd_core.log? – Rob Stevenson-Leggett Sep 24 '14 at 15:34
  • @Rob Stevenson-Legget, Which static file handler do you mean ? Regarding the 404 its the IIS one and the difference is local iisexpress 7.5 and on the server iis7.5 Will add some logs tomorrow – user219 Sep 24 '14 at 18:01
  • As in the IIS Static File Handler. See Chris' answer for links to help resolve. – Rob Stevenson-Leggett Sep 24 '14 at 20:25
3

I resolved the issue after some trouble shooting, It was not in the IIS configuration or web.config. Instead the issue light within the Global.aspx,

**AreaRegistration.RegisterAllAreas();**

DependencyResolver.SetResolver(new UnityDependencyResolver(UnityHelper.Container));
BundleConfig.RegisterBundles(BundleTable.Bundles);

FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);

The areaRegistation was trying to resolve the page, so moving the AreaRegistration to the bottom resolved the issue. Thx everyone :)

| improve this answer | |
1

Looks like ASP is not handling requests to the .HTML file extension as Rob says in the comments.

See posts like:

to force ASP to handle .HTML files instead of the standard static file handler.

| improve this answer | |
0

The sledgehammer approach is to set runAllManagedModulesForAllRequests="true" inside the modules element in system.webServer. For later versions of IIS this is not such as bad thing, but you may want to refine it by reading around the subjects linked from Chris's answer.

| improve this answer | |
  • Thx Will, I runned this setup and it didnt resolve it. Here is more information about RAMMFAR, the part @Ant P mentioned: hanselman.com/blog/… – user219 Sep 26 '14 at 7:08
0

To throw another answer into the mix - you should be able to resolve this issue without resorting to the "sledgehammer" approach that Will mentions by removing the precondition from the UrlRoutingModule (the module that handles MVC routing):

<modules>
  <remove name="UrlRoutingModule-4.0" />
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>

This should achieve essentially the same effect as enabling RAMMFAR but without also enabling all of the other unnecessary modules that might cause performance issues or unusual side-effects when requests for static files are run through them.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy