Try our conversational search powered by Generative AI!

EPiServer CMS 7.6.3(7.5) Edit mode preview is redirected to 404 on IIS 8.5


Background - EPiServer CMS is recently migrated from 6 R2 to 7.0 an no to 7.5(7.6.3), database is shared, meaning it is one and the same. Configuration is exactly the same, as they all are development environment they have the same DNS and so, everything exactly the same except OS and IIS versions.

Edit-mode is working properly on IIS 8.0(Windows Server 2012) and IIS 7.5(Windows Server 2008 R2) but not on IIS 8.5(Windows Server 2012 R2 or Windows 8.1).

When hosted on IIS 8.5 - every time one opens any page in edit-mode as a preview always 404 page is displayed instead.

So in the end problem is with the Url that edit-mode uses to display in preview iframe:



First difference in logfile

From IIS 8.5 machine:

DEBUG; System.Web.HttpApplication+SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute(:0); 17.1.3 UrlRewriteModule rewrites from 'http://server/cms/CMS/Content/,,3/?epieditmode=True' to 'http://server/cms/CMS/Content/,,3/?epieditmode=True'


From IIS 7.5 or IIS 8.0 machine:

DEBUG; System.Web.HttpApplication+SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute(:0); Exiting with no rewrite, Url is http://server/cms/CMS/Content/,,3/?epieditmode=True


First question why did it rewrite from one url to exactly the same url, actually it did not, logging is not entirely accurate if you reflect EPiServer.Web.UrlRewriteModuleBase you will see following:

private void BeginRequestEventHandler(object sender, EventArgs e)
            HttpApplication application = (HttpApplication) sender;
            if (_log.IsDebugEnabled)
                _log.DebugFormat("Starting request with Url {0}", application.Request.Url);
            RequestContext requestContext = GetRequestContext();
            if (string.Equals((string) requestContext.UrlInternal, (string) requestContext.UrlExternal, StringComparison.OrdinalIgnoreCase))
                if (_log.IsDebugEnabled)
                    _log.DebugFormat("Exiting with no rewrite, Url is {0}", requestContext.UrlInternal);
                if (string.IsNullOrEmpty(requestContext.UrlInternal.Path))
                    ExceptionManager.RenderHttpRuntimeError(new HttpException(404, "Not Found"));
                application.Context.RewritePath(requestContext.UrlInternal.Path, string.Empty, UriSupport.RemoveQueryStringDelimeter(requestContext.UrlInternal.Query), true);
                if (_log.IsDebugEnabled)
                    _log.Debug(string.Format("17.1.3 UrlRewriteModule rewrites from '{0}' to '{1}'", requestContext.UrlExternal, requestContext.UrlInternal));



_log.Debug(string.Format("17.1.3 UrlRewriteModule rewrites from '{0}' to '{1}'", requestContext.UrlExternal, requestContext.UrlInternal));


is not entirely correct, as both UrlInternal and UrlExternal are EPiServer.UrlBuilder when they are converted to object they are url decoded so in log they look the same.

so actually what happens is that following logfile line should have been produced instead(note that it should have shown change from ',,3' to '%2C%2C3'):

DEBUG; System.Web.HttpApplication+SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute(:0); 17.1.3 UrlRewriteModule rewrites from 'http://server/cms/CMS/Content/,,3/?epieditmode=True' to 'http://server/cms/CMS/Content/%2C%2C3/?epieditmode=True'


And all that could be fine only if following line would not be as follows:

if (string.Equals((string) requestContext.UrlInternal, (string) requestContext.UrlExternal, StringComparison.OrdinalIgnoreCase))


Now comes the tricky part when the same EPiServer.UrlBuilder instances are cast to string they dont url decode, so obviously previous if statement retuns false as both strings are different if you ask string.Equals method and therefore 404 error messages in edit-mode.


So I somehow doubt that its IIS 8.5 becouse others are runing EPiServer 7.5 on it without this problem.

What could it be any ideas?






Apr 01, 2014 22:06

My quick fix is to reflect both EPiServer.Web.UrlRewriteModule and EPiServer.Web.UrlRewriteModuleBase and use reflection to set some internal properties and change EPiServer.Web.UrlRewriteModuleBase method BeginRequestEventHandler if statement to following:

if (string.Equals(


Ofcourse I could have gone and changed EPiServer.Web.UrlRewriteModuleBase method GetRequestContext so that UrlInternal is url decoded right away:

private static UrlRewriteModuleBase.RequestContext GetRequestContext()
            HttpContext current = HttpContext.Current;
            UrlRewriteModuleBase.RequestContext requestContext = current.Items[(object)"EP:urlRewriteContext"] as UrlRewriteModuleBase.RequestContext;
            if (requestContext == null)
                requestContext = new UrlRewriteModuleBase.RequestContext();
                Uri url = current.Request.Url;
                requestContext.UrlInternal = new UrlBuilder(url);
                requestContext.UrlExternal = new UrlBuilder(new Uri(url, current.Request.RawUrl));
                current.Items[(object)"EP:urlRewriteContext"] = (object)requestContext;
            return requestContext;


but I changed previously mentioned if statement instead.


I also needed to change web.config now to:

    <modules runAllManagedModulesForAllRequests="true">
      <add name="UrlRewriteModule" type="My.Web.UrlRewriteModule, My.Web" preCondition="managedHandler" />



So now edit-mode preview works, but this is a workaround only I still need to have proper solution instead.


PS. full reflected and modified code:


Edited, Apr 01, 2014 22:22

Spelling mistake: on my initial post: Background - EPiServer CMS is recently migrated from 6 R2 to 7.0 and now to 7.5(7.6.3)

Apr 01, 2014 22:35

Response from EPiServer support was that configuraton for friendly url most likely is wrong after migration from 6 to 7.5


<urlRewrite defaultProvider="EPiServerFriendlyUrlRewriteProvider">
      <add name="EPiServerFriendlyUrlRewriteProvider"
           description="EPiServer standard Friendly URL rewriter"
           type="EPiServer.Web.FriendlyUrlRewriteProvider,EPiServer" />
      <add name="EPiServerIdentityUrlRewriteProvider"
           description="EPiServer identity URL rewriter"
           type="EPiServer.Web.IdentityUrlRewriteProvider,EPiServer" />
      <add name="EPiServerNullUrlRewriteProvider"
           description="EPiServer bypass URL rewriter"
           type="EPiServer.Web.NullUrlRewriteProvider,EPiServer" />

but what can be wrong here can someone shed light?


Or there is some more configuration that I need to look at regarding friendly url configuration in EPiServer CMS

Apr 29, 2014 12:10

To use routing in CMS 7 the UrlRewriteProvider to use should be EPiServer.Web.HierarchicalUrlRewriteProvider (you can remove the whole urlRewrite section from config, since that is the default one).

Also the UrlRewriteMethod to use is RoutingUrlRewriteModule as below:

<add name="UrlRewriteModule" type="EPiServer.Web.RoutingUrlRewriteModule, EPiServer" preCondition="managedHandler"/>

Apr 29, 2014 14:48

So as some time had passed since I started to investigate this problem, I configured everything back to original(meaning removed my modified reflected code and configuration mentioned in previous posts).
I had to do it, because now it's running on 7.6.4 version, who knows maybe its changed and/or fixed.

So I changed back to original:

<add name="UrlRewriteModule" type="EPiServer.Web.UrlRewriteModule, EPiServer" preCondition="managedHandler" />


And No, I still got nice 404 error again in edit mode(On IIS 8.5 only)

Then as Johan Björnfot suggested switched to RoutingUrlRewriteModule instead of UrlRewriteModule:

<add name="UrlRewriteModule" type="EPiServer.Web.RoutingUrlRewriteModule, EPiServer" preCondition="managedHandler" />


And it worked, what a simple solution, also if one carefully reads: then its written that RoutingUrlRewriteModule must be used and not UrlRewriteModule.

Also this problem had noting to do with friendly Urls configuration. It did not affect 404 problem.

EPiServer support tried to reproduce this with clean site and they had no problems and obviously why would they have problems, if you install clean then by default RoutingUrlRewriteModule is used and no problem occur.

So, thank you Johan!

Apr 30, 2014 11:59
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.