This project is read-only.

Returning an empty page

Dec 16, 2010 at 1:55 AM
Edited Dec 16, 2010 at 2:16 AM


Adding "Response.BufferOutput= false;" after Response.Clear() fixed it. That line of code isn't present in the chm C# sample, but it is present in the GenerateZip-Csharp.aspx file sample, which also happens to have an error on line 148. It's trying to pass 4 parameters, but no overload takes 4 as far as the compiler was concerned.


I'm trying a variation of the sample code on a .NET 3.5 web site project (not a wap), but all I'm getting in return is an empty document or 404.

Here's the code that executes as a response to a button click:

    protected void ImageButtonDownload_Click(object sender, ImageClickEventArgs e)

        System.Web.HttpContext c = System.Web.HttpContext.Current;
        String ReadmeText = String.Format("README.TXT\n\nHello!\n\n" +
        "This is a zip file that was dynamically generated at {0}\n" +
        "by an ASP.NET Page running on the machine named '{1}'.\n" +
        "The server type is: {2}\n",

        Response.ContentType = "application/zip";
        Response.AddHeader("Content-Disposition", "");
        using (ZipFile zip = new ZipFile())
            zip.AddEntry("Readme.txt", ReadmeText);


Anyone have any ideas?

Dec 16, 2010 at 1:56 PM

Instead of Response.Close you should use HttpApplication.CompleteRequest. In short, Response.Close *doesn't* flush the response buffer, but see the links below for more technical info...

"Hmm, it seems that neither Response.Close() nor Response.End() is the appropriate thing. What we really want is HttpApplication.CompleteRequest. Pretty ugly.
I'll make the changes."

"Response.End() will stop the page execution/rendering at that point. No code following Response.End() will be run. The response is terminated at that point with no further output added to the stream. Response.Close() is similar to Response.End(), but allows code to be executed after it is called (but no further output can be sent in the page response)."

"Response.Close sends a reset packet to the client and using it in anything other than error condition will lead to all sorts of problems - eg, if you are talking to a client with enough latency, the reset packet can cause any other response data buffered on the server, client or somewhere in between to be dropped."



Dec 16, 2010 at 6:39 PM

Thanks for the tip, Mike!

For anyone looking for your httpapplication instance, it can be found at