Our Umbraco CMS has a redirect template/document type that allows the editor to set up a redirect to another site. Eg. they can create a page called /webmail which redirects to www.some-corporate-webmail-system.com, to make it more convenient for the user to access.
In the template, we simply have a Razor macroscript that uses Response.Redirect to redirect the user to the destination Url.
Things were working fine until we started to get some error reports suggesting that the redirect process was taking ages and causing Internet Explorer to hang - often with 100% CPU usage.
As always, there were no problems in Chrome, Android, iOS, Safari or Firefox... just Internet Explorer - but since everyone insists on using Internet Explorer in the corporate world, we definitely needed to see what was going on and fix it ;-)
We did some debugging and logging, and it seemed that together with the 302 redirection page that Response.Redirect generates, a stack more data was being transmitted to the client. This turned out to be our Umbraco debug trace, and the trace in some cases was fairly large. We guess Internet Explorer was the only browser to actually read this content, and process was causing it to hang/crash.
But why, when we had already set umbracoDebugMode to false, and disabled trace in <system.web> in web.config, was it sending the trace information in the first place?
The answer lies in default.aspx in the top level of the Umbraco site. Every page on your site is served using this aspx, and the page directive looks like this:
In the template, we simply have a Razor macroscript that uses Response.Redirect to redirect the user to the destination Url.
Things were working fine until we started to get some error reports suggesting that the redirect process was taking ages and causing Internet Explorer to hang - often with 100% CPU usage.
As always, there were no problems in Chrome, Android, iOS, Safari or Firefox... just Internet Explorer - but since everyone insists on using Internet Explorer in the corporate world, we definitely needed to see what was going on and fix it ;-)
We did some debugging and logging, and it seemed that together with the 302 redirection page that Response.Redirect generates, a stack more data was being transmitted to the client. This turned out to be our Umbraco debug trace, and the trace in some cases was fairly large. We guess Internet Explorer was the only browser to actually read this content, and process was causing it to hang/crash.
But why, when we had already set umbracoDebugMode to false, and disabled trace in <system.web> in web.config, was it sending the trace information in the first place?
The answer lies in default.aspx in the top level of the Umbraco site. Every page on your site is served using this aspx, and the page directive looks like this:
<%@ Page language="c#" Codebehind="default.aspx.cs" AutoEventWireup="True"
Inherits="umbraco.UmbracoDefault" trace="true" validateRequest="false" %>
<%@ Page language="c#" Codebehind="default.aspx.cs" AutoEventWireup="True"
Inherits="umbraco.UmbracoDefault" trace="false" validateRequest="false" %>
Good to know! But very strange that we cannot trust the settings in our configuration files (like web.config). Btw, good posts Steve!
ReplyDelete