Touch Web.config/application restart = first request "500 - Internal server error"
This is a weird one that I've not run into before:
- Umbraco 4.0.2.1 - Windows Server 2008 x64 - IIS 7 under Integrated Pipeline
Whenever the Web.config is touched or the application starts up, the first request leads to a 500 internal server error. Refresh and no problems until the next Web.config touch/application restart. Has anyone else experienced this issue?
We want to go live, but this one is problematic to say the least!
I will do so, but it's actually to do with the Splash Page having a compilation issue. I'll look into it further as I just assumed that I had a bad copy of it.
I will continue to look into it further, but basically with IIS7, IIS7 overrides customErrors settings if you're using integrated pipeline. Therefore, for the splash page config/splash/booting.aspx:
Used to be fine for setting the status code, but now, with integrated pipeline, IIS7 overrides with it's own error 500 page instead of the booting.aspx, which has a meta refresh for every 10 seconds which no longer gets called. In other words, it's entire point for being there is negated, and you won't want to remove the 500 status code for SEO reasons.
Windows Server 2008 with IIS7 (with integrated pipeline) by default hijacks responses with status
codes apart from 200 OK and replaces the response with the specified
built-in error pages. This does not apply on Vista or Windows 7, and I
assume many hosts switch this behaviour by default. Therefore, only a
smaller segment of users would typically run into this.
As setting the Response.TrySkipIisCustomErrors = true; everywhere is
not very feasible, there is a work around that appears to work: flip a
switch in your applicationHost.config file that passes your response
through without IIS hijacking it. This is the sledgehammer approach,
but works as required for Umbraco as it goes back to for i.e. IIS 6
default approach. Non-200 status code responses now are handled within
Umbraco without being hijacked (i.e. NotFoundHandlers, booting screens,
etc.).
Touch Web.config/application restart = first request "500 - Internal server error"
This is a weird one that I've not run into before:
- Umbraco 4.0.2.1
- Windows Server 2008 x64
- IIS 7 under Integrated Pipeline
Whenever the Web.config is touched or the application starts up, the first request leads to a 500 internal server error. Refresh and no problems until the next Web.config touch/application restart. Has anyone else experienced this issue?
We want to go live, but this one is problematic to say the least!
<add key="umbracoConfigurationStatus" value="4.0.2.1" />
<add key="umbracoReservedUrls" value="/config/splashes/booting.aspx,/install/default.aspx,/config/splashes/noNodes.aspx" />
<add key="umbracoReservedPaths" value="/umbraco/" />
<add key="umbracoContentXML" value="/data/umbraco.config" />
<add key="umbracoStorageDirectory" value="/data" />
<add key="umbracoPath" value="/umbraco" />
<add key="umbracoEnableStat" value="false" />
<add key="umbracoHideTopLevelNodeFromPath" value="true" />
<add key="umbracoEditXhtmlMode" value="true" />
<add key="umbracoUseDirectoryUrls" value="false" />
<add key="umbracoDebugMode" value="false" />
<add key="umbracoTimeOutInMinutes" value="20" />
<add key="umbracoDisableVersionCheck" value="true" />
<add key="umbracoDisableXsltExtensions" value="true" />
<add key="umbracoDefaultUILanguage" value="en" />
<add key="umbracoProfileUrl" value="profiler" />
<add key="umbracoUseSSL" value="true" />
<add key="umbracoUseMediumTrust" value="false" />
Nothing in the server error logs.
Well, look at that!
<!-- Show the /config/splashes/booting.aspx page while initializing content -->
<EnableSplashWhileLoading>False</EnableSplashWhileLoading>
Solves this issue!
When set to "True", first request results in a 500 internal server error (although under Classic Pipeline it does not).
Ted,
Can you log this on Codeplex as well, think it should get resolved in future releases.
TIA,
/Dirk
I will do so, but it's actually to do with the Splash Page having a compilation issue. I'll look into it further as I just assumed that I had a bad copy of it.
I will continue to look into it further, but basically with IIS7, IIS7 overrides customErrors settings if you're using integrated pipeline. Therefore, for the splash page config/splash/booting.aspx:
Used to be fine for setting the status code, but now, with integrated pipeline, IIS7 overrides with it's own error 500 page instead of the booting.aspx, which has a meta refresh for every 10 seconds which no longer gets called. In other words, it's entire point for being there is negated, and you won't want to remove the 500 status code for SEO reasons.
The solution is probably along the lines of:
as per http://www.west-wind.com/weblog/posts/745738.aspx. This ties into another post that has yet to be resolved as well at http://our.umbraco.org/forum/developers/extending-umbraco/4216-404-handler---Doesn%27t-work
For more information, see:
Posted to CodePlex: http://umbraco.codeplex.com/WorkItem/View.aspx?WorkItemId=24786.
Solved. Please see Please see http://www.andornot.com/about/developerblog/2009/10/errors-sending-right-message.aspx for more information.
http://umbraco.codeplex.com/WorkItem/View.aspx?WorkItemId=24786
But should documented:
Windows Server 2008 with IIS7 (with integrated pipeline) by default hijacks responses with status codes apart from 200 OK and replaces the response with the specified built-in error pages. This does not apply on Vista or Windows 7, and I assume many hosts switch this behaviour by default. Therefore, only a smaller segment of users would typically run into this.
As setting the Response.TrySkipIisCustomErrors = true; everywhere is not very feasible, there is a work around that appears to work: flip a switch in your applicationHost.config file that passes your response through without IIS hijacking it. This is the sledgehammer approach, but works as required for Umbraco as it goes back to for i.e. IIS 6 default approach. Non-200 status code responses now are handled within Umbraco without being hijacked (i.e. NotFoundHandlers, booting screens, etc.).
<location path="Site Description">
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</location>
Thanks to Fabian Heussser's comment on Rick Strahl's post that helped with this (http://www.west-wind.com/weblog/posts/745738.aspx#829305).
is working on a reply...