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.
vovin
Member
10 Points
2 Posts
bug in GzipStream on Response.Filter after Response.Flush
Nov 09, 2006 10:07 AM|LINK
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
Jasson_King
Star
8057 Points
1520 Posts
Re: bug in GzipStream on Response.Filter after Response.Flush
Nov 16, 2006 09:34 AM|LINK
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();
}