Why is an XML Parsing Error generated when using a custom authentication module

Question

I have a .NET web service which is protected by a custom authentication module. The module returns a 403 status code and ends the response (see appendix.)

The authentication module is working as expected, valid authorised users are correctly able to see the properly rendered ASMX content. However, in IIS6 (or the Visual Studio Development Server) the following response is given for unauthorised users;

IIS express (correctly) gives;

(I've not tested this in IIS7, I assume the response would be similar to directly above, I'd be grateful if someone could verify this.)

Looking at the HTTP headers, the 403 status code is being returned to the client alongside the XML Parsing error. I'd like understand why the parsing error is generated (after the response should have been flushed and ended) and how to force the web server to serve a simple 403 response instead.

Appendix

public class IPAuthentication : IHttpModule {

    public void Init(HttpApplication application) {
        application.AuthenticateRequest += new EventHandler(Application_AuthenticateRequest);
    }

    private void Application_AuthenticateRequest(object sender, EventArgs e) {
        if (!allowed) { //pseudo-code
            HttpContext.Current.Response.ClearHeaders();
            HttpContext.Current.Response.Clear();

            HttpContext.Current.Response.StatusCode = 403;
            HttpContext.Current.Response.StatusDescription = "Access denied.";

            HttpContext.Current.Response.SuppressContent = true;

            HttpContext.Current.Response.End();
        }
    }

    public void Dispose() { }

}

Answer 1

The XML error is being caused by HttpContext.Current.Response.End();.

Try using HttpContext.Current.ApplicationInstance.CompleteRequest(); or HttpContext.Current.Reponse.Redirect(url, false); instead.

More information about using CompleteRequest was provided in this StackOverflow answer.

From the StackOverlow posted answer above,

• "use CompleteRequest() to end a normal request. CompleteRequest causes the ASPNET 'pipeline' to jump ahead to the EndRequest event, after the current HttpApplication event completes. So if you call CompleteRequest, then write something more to the response, the write will be sent to the client."

And here is another good post that I found, describing why Response.Close and Response.End should never be used except in rare error conditions.

Info from that link that I found useful is that "You might consider calling CompleteRequest instead if you want to jump ahead to EndRequest and send a response to the client."

And in one of the comments to the blog post at that link, "CompleteRequest causes the 'pipeline' to jump ahead to the EndRequest event, but this only happens after the current HttpApplication event completes. Frequently the code that runs in the current HttpApplication event, after you call CompleteRequest, does not harm anything. In the case here, the page handler continues to run, so all the page events will fire. If that is causing harm, and you can’t mitigate that by remembering whether or not you called CompleteRequest, then you may need to use Response.Redirect(url, true) instead."

However, on the MSDN Response.Redirect page it says, "When you use this method in a page handler to terminate a request for one page and start a new request for another page, set endResponse to false and then call the CompleteRequest method. If you specify true for the endResponse parameter, this method calls the End method for the original request, which throws a ThreadAbortException exception when it completes. This exception has a detrimental effect on Web application performance, which is why passing false for the endResponse parameter is recommended. For more information, see the End method.", which indicates to me that Response.Redirect(url, false) should be used in most cases instead of passing true, and is safer than using CompleteRequest.