Most verbose HTTP 404 message I've ever seen.


     Screen scrape follows.

    Server Error in '/' Application.

            <h2> <i>'//App_Data/redirects/' is not a valid virtual path.</i> </h2></span>
            <font face="Arial, Helvetica, Geneva, SunSans-Regular, sans-serif ">
            <b> Description: </b>An

    unhandled exception occurred during the execution of the current web
    request. Please review the stack trace for more information about the
    error and where it originated in the code.

            <b> Exception Details: </b>System.Web.HttpException: '//App_Data/redirects/' is not a valid virtual path.<br><br>
            <b>Source Error:</b> <br><br>
            <table width="100%" bgcolor="#ffffcc">

    The source code that generated this unhandled exception can only be
    shown when compiled in debug mode. To enable this, please follow one of
    the below steps, then request the URL:

    1. Add a "Debug=true" directive at the top of the file that generated the error. Example:

      <%@ Page Language="C#" Debug="true" %>


    2) Add the following section to the configuration file of your application:

           <compilation debug="true"/>

    Note that this second technique will cause all files within a given
    application to be compiled in debug mode. The first technique will
    cause only that particular file to be compiled in debug mode.

    Running applications in debug mode does incur a memory/performance
    overhead. You should make sure that an application has debugging
    disabled before deploying into production scenario.

            <b>Stack Trace:</b> <br><br>
            <table width="100%" bgcolor="#ffffcc">
                      <code></code><pre>[HttpException (0x80004005): '//App_Data/redirects/' is not a valid virtual path.]<br>   System.Web.VirtualPath.Create(String virtualPath, VirtualPathOptions options) +213<br>   System.Web.HttpServerUtility.MapPath(String path) +33<br>   RSATemplate.TranslateSiteURL(Uri uri) +212<br>   ASP.error404_aspx.Page_Load() +287<br>   System.Web.Util.CalliHelper.ArglessFunctionCaller(IntPtr fp, Object o) +5<br>   System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +826911<br>   System.Web.UI.Control.OnLoad(EventArgs e) +99<br>   System.Web.UI.Control.LoadRecursive() +47<br>   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061<br></pre>
            </font></p><hr size="1" width="100%" color="silver">

    <font face="Arial, Helvetica, Geneva, SunSans-Regular, sans-serif "> Version Information: Microsoft .NET Framework Version:2.0.50727.832; ASP.NET Version:2.0.50727.832


  • The only real WTF is that someone left that stuff showing on a live website rather than having a custom error handler (Although it looks like their error handler is what crashed given it's from 404_aspx.Page_Load, personally I've always made sure there's a static HTML fallback if everything else fails).

    That's not actually just a 404 either, that's an exception from a function in .NET due to it not being a valid URL, not just there not being a file in it.

  • Winner of the 2016 Presidential Election

    So where's the WTF? Looks like a standard ASP.NET exception to me. Is it that they tried to Server.MapPath an invalid path?

  • I remember once getting such a page when accessing an internal site's homepage.

    I looked at index.asp and nothing seemed to justify the exception I was seeing. Took me a while until I noticed the URL ended with '.html' rather that '.asp'.

    Somebody had saved the output of index.asp - when it was actually giving out an exception - as index.html in the same directory, an IIS was serving that page instead of the .asp

  • It's not just a 404, but it is indeed a 404.

  •  Indeed.

  • @henke37 said:

    It's not just a 404, but it is indeed a 404.

    404 really only apply to HTTP requests, which the failing call is not. It is a call to a .NET function for formatting URL.

    Even if it was over HTTP I'd think it's more of a 400 than a 404, the problem is that the URL is in fact not even a valid URL not just a file that doesn't even exist. In fact the function being called, unless I'm mistaken, doesn't even care whether the file exists. It just formats the path for special path values (Starting with a ~/ for webroot is the only one I know off top of head).

Log in to reply

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.