Sitecore Upgrade Headaches: EnsureServerUrl

Upgrading from Sitecore 6.5 to 6.6 generated one really cryptic error that was almost impossible to understand.  If you have seen this application error thrown before, you will know what I mean:

Machine = MACHINE1

UserAgent = Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) NOT Firefox/3.5

User Name = IIS APPPOOL\SiteCore Querystring = ?aspxerrorpath=/

======== EXCEPTION ========

Application error.

System.Net.Sockets.SocketException (0x80004005): The requested name is valid, but no data of the requested type was found

   at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)

   at System.Net.Dns.GetHostEntry(String hostNameOrAddress)

   at Sitecore.Web.WebUtil.GetHostIPAddress()

   at Sitecore.Globals.set_ServerUrl(String value)

   at Sitecore.Pipelines.HttpRequest.EnsureServerUrl.Process(HttpRequestArgs args)

   at (Object , Object[] )

   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)

   at Sitecore.Nexus.Web.HttpModule. [1](Object [1], EventArgs [1])

   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

 

If you look at the error carefully, you will learn that the error is related to the HttpRequest Sitecore pipeline and in the EnsureServerUrl process.  This process is new as it was not in this pipeline before 6.6.  If you look even deeper into the errors in the Event Viewer for this failure, you will see that the culprit is the call to System.Net.Dns.InternalGetHostByName().  Since this is a Microsoft Assembly, there is nothing we can do to fix it.  This new process basically verifies cross domain referencing so it is not crucial that it be left in.  The quick fix for me was to comment out the whole process.  Voila, worked like a charm.  It still bothers me to know that Sitecore decided to use this method even though it doe not fully work.  This process did not generate errors in my local environment but did once deployed to production so there must be a Windows server compatibility issue with that method/assembly.