I've discovered a bug, which results in truncation of the end of the response on gzipped stream.

Reponse content is cut when using gzipped (or deflated) stream on Response.Filter and calling both Response.Flush and Response.End.

To reproduce the bug following code may be used:

    public class FlushTestPage : System.Web.UI.Page
    {
        protected override void OnInit(System.EventArgs e)
        {
            base.OnInit(e);
            Response.Filter = new System.IO.Compression.GZipStream(Response.Filter, System.IO.Compression.CompressionMode.Compress);
            Response.AppendHeader("Content-encoding", "gzip");
            Response.Write("Hello number 1\n");
            Response.Flush();
            Response.Write("Hello number 2\n");
            Response.Flush();
            Response.End();
        }
    }
 

 The result gfrom above is:

Hello Number 1
Hello Number

As you can see last letter is cut from the response. In some cases it may be more characters truncated.

Above situationb happens only when you use both Response.Flush and Response.End on gzipped stream. If there was no flush or end, the result would be sent to browser properly. The same situation works with deflate stream.

regards,

Pawel Rogozinski
Technical Leader at Eracent

Hi,

   This is not a bug.I think you make a mistake."\r\n" in C# is a char,not only "\n".If you change your codes as the following,everything is OK.

   protected override void OnInit(System.EventArgs e)
        {
            base.OnInit(e);
            Response.Filter = new System.IO.Compression.GZipStream(Response.Filter, System.IO.Compression.CompressionMode.Compress);
            Response.AppendHeader("Content-encoding", "gzip");
            Response.Write("Hello number 1\r\n");
            Response.Flush();
            Response.Write("Hello number 2\r\n");
            Response.Flush();
            Response.End();
        }