Response.Flush breaks IIS's "Custom Errors"RSS

10 replies

Last post Apr 18, 2019 08:15 PM by fredericDelaporte

  • Response.Flush breaks IIS's "Custom Errors"

    May 23, 2006 03:29 PM|goinoutwest|LINK

    [Yes, I know I'm complaining about ancient technology]

    After using Response.Flush, any errors encountered will not "trigger" IIS's configured "Custom Error" page.  I can't find any mention of this on MSDN.

    I find it frustrating that there are several articles that suggest using Response.Flush for all kinds of performance improvements on slow pages.  The articles always fail to mention this crippling "side-effect" of using it.

    Does anyone know why it fails?  Where's the KB article?

  • bills bills

    415 Posts

    Microsoft

    Re: Response.Flush breaks IIS's "Custom Errors"

    May 23, 2006 06:02 PM|bills|LINK

    Hi - could you post some sample code that reproduces the issue?

    thanks-

    bill

    ~~~~~~~~~~~~~~~~~~~~~~~~
    Bill Staples
    Product Unit Manager, IIS
    blog: http://blogs.iis.net/bills
  • Re: Response.Flush breaks IIS's "Custom Errors"

    May 23, 2006 06:44 PM|goinoutwest|LINK

    Yeah, here's some repro instructions:

    1) Configure a "Custom Error" using IIS mgr for the 500;100 error.  Choose a File or URL and point to the page you'd like to have as your error message.

    2) Create a Test.asp page, and make the contents the following:

    <%@ Language=VBScript %>
    <%

    ' TURN ON BUFFERING
    Response.Buffer = TRUE

    ' FLUSH THE CONTENT AND HEADERS TO THE CLIENT
    ' Response.Flush()

    ' CAUSE AN ERROR
    This_Function_Does_Not_Exist()

    %>

    3) Browse to the page and observe that your selected error page appears before you.  Finally, UNcomment the "Response.Flush()" line of code.  Reload page in your browser.  Your "error handling" page is not invoked.

    Thanks for taking a look!

  • Re: Response.Flush breaks IIS's "Custom Errors"

    Jun 01, 2006 09:56 AM|wwwcoder|LINK

    From my understanding of ASP, when you execute a flush you're basically sending the content of the processed  page to the Web browser. The HTTP headers have already been written and sent to the browser once you send the Response.Flush. Basically you shut off of the Buffer and sent out the response. Since the headers have already been sent to the browser you can longer issue a 500 http response code, and call your custom page. This isn't an error, it is just how HTTP works.
  • Re: Response.Flush breaks IIS's "Custom Errors"

    Jun 05, 2006 10:01 PM|goinoutwest|LINK

    You are correct, that after Response.Flush has been called the headers are sent to the client.  So, it is therefore impossible to change that 200OK into a 500 response code.  I have no issues with that.

    However, there seems to be no reason that the "Custom Error" page could not be invoked at the time of the error.  Often times, developers used code in the "Custom Error" page to alert them that an error had occurred on their web site.  If they use Response.Flush before the error occurs their alerting/logging mechanism will not be triggered.

    The only alternative (when using Response.Flush on a page) is to use the horrible OnError ResumeNext style error trapping.
  • Re: Response.Flush breaks IIS's "Custom Errors"

    Jun 13, 2006 09:02 PM|anilr|LINK

    goinoutwest

    However, there seems to be no reason that the "Custom Error" page could not be invoked at the time of the error.  Often times, developers used code in the "Custom Error" page to alert them that an error had occurred on their web site.  If they use Response.Flush before the error occurs their alerting/logging mechanism will not be triggered.

     

    The custom-error feature was not designed to logging/alerting when an error occurs but for sending a customized error message to the client - as it is too late to send a customized error message to the client at this point, no custom-error page is invoked.

    Anil Ruia
    Software Design Engineer
    IIS Core Server
  • Re: Response.Flush breaks IIS's "Custom Errors"

    Jun 13, 2006 09:44 PM|goinoutwest|LINK

    anilr

    The custom-error feature was not designed to logging/alerting when an error occurs but for sending a customized error message to the client

    I believe you are incorrect.  The custom-error feature was designed for both.  See this Microsoft article:

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/tips/custerr.mspx

    Just so we're clear, here is a relevant quote from the article:

    "The examples mentioned in this article are simplified to demonstrate the Custom Error feature for 404 errors. They can be easily extended to handle most other HTTP errors and modified to take immediate action, like sending administrative alerts."

  • Re: Response.Flush breaks IIS's "Custom Errors"

    Jun 26, 2006 06:36 PM|anilr|LINK

    Regardless of what that document says, that is not how custom-error behaved on any IIS version - it does not even get invoked in many cases when the error status is set before the response is flushed to the client - write an aspx page which generates a 404 response and no custom-error will be invoked for it.

    On IIS7, you may be able to write a module (native or managed) which registers for Log/EndOfRequest) notification and does any logging/administrative alert on failed requests.

     

    Anil Ruia
    Software Design Engineer
    IIS Core Server
  • Re: Response.Flush breaks IIS's "Custom Errors"

    Sep 14, 2006 03:37 PM|renniquer|LINK

    I've experienced the same error, and here's the workaround I came up with:

    1. Right after you call Response.Flush(), add this line of code:

    HttpContext.Current.Items["responseFlushed"] = true;

    2. In Global.asax, add the following to Application_Error:

    if (Convert.ToBoolean(HttpContext.Current.Items["responseFlushed"]))
    {
        HttpContext.Current.Server.Transfer("CustomErrorPage.htm");
    }

    That should do it. You can add additional code to get your actual customErrors settings from web.config using System.Web.Configuration instead of hard coding the custom error page file path. You might also want to make sure Server isn't null.

    Note that you should use HttpContext.Current.Items and NOT HttpContext.Current.Session, as the Items collection will reset itself on each request, resetting Items["responseFlushed"] to false in the process.
     

  • Re: Response.Flush breaks IIS's "Custom Errors"

    Oct 10, 2006 05:42 PM|legacycoder|LINK

    Goinoutwest, have you been able to resolve this issue?  We're having the exact same problem... 

    [quote user="goinoutwest"][quote user="anilr"]

    The custom-error feature was not designed to logging/alerting when an error occurs but for sending a customized error message to the client

    I believe you are incorrect.  The custom-error feature was designed for both.  See this Microsoft article:

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/tips/custerr.mspx

    Just so we're clear, here is a relevant quote from the article:

    "The examples mentioned in this article are simplified to demonstrate the Custom Error feature for 404 errors. They can be easily extended to handle most other HTTP errors and modified to take immediate action, like sending administrative alerts."

  • Re: Response.Flush breaks IIS's "Custom Errors"

    Apr 18, 2019 08:15 PM|fredericDelaporte|LINK

     @renniqer, The question here is about Classic Asp. Your answer is for Asp.Net, it does not apply.

    Otherwise, the best I have found for handling this case it to put all the rendering in a Render sub, and use

    On Error Resume Next

    Render

    If Err.number <> 0 Then

        ' Handle the error
        Response.Write "Error"
    End If

    When an error occur in the render, the render sub is immediately interrupted and you can handle the error with whatever custom code you wish, including coming from an include. So that is no more a catch all solution put only in one place, but for pages requiring that flush trick, well, just use one more trick for handling their errors.