It seems like IIS7 has a bug where if dynamic compression is enabled and you do a Response.Close() the last character of the response stream gets stripped off.
To test it just enabled dynamic compression in IIS7 and create a page with the following Page_Load method:
You should notice that the last "t" in the word "test" is missing when you display the page in a web browser. Disabling dynamic compression or commenting out "Response.Close()" eliminates the bug. If anyone has another work around or knows if this is truly
a bug I would appreciate any feedback. Thanks.
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.
In this particular case, compression involves looking for common patterns within the response and some amount of response has to be buffered by the compression code to increase the chance of finding longer repeating patterns - this part that is buffered
cannot be sent to the client once you do Response.Close().
In short, do not use Response.Close().
Anil Ruia
Software Design Engineer
IIS Core Server
Ok, then what DO you use? Recently I was getting timeout errors when making a bunch of API calls one right after the other. Until I put in response.Close() I was getting that timeout error after only the 3rd SOAP API call.
Ok then what DO you use? I had to put in response.Close or else I kept getting a timeout error right after request.GetRequestStream() in my code during a bunch of bulk API calls..one right after the other. On the first two API calls I made, they were fine.
It was always on that 3rd API call I got a timeout error until I put response.Close() in there.
It is not clear what issue you were hitting - was the timeout at the client or the server side? Resetting the connection to avoid a timeout seems like a band-aid and seems like you still have some bad problems lurking. Can you collect "failed request tracing"
for the request sequence resulting in a timeout?
Anil Ruia
Software Design Engineer
IIS Core Server
HttpApplication.CompleteRequest is the better one to use rather than Response.End - the latter results in a exception being raised which is going to cause performance problems, especially on x64.
Anil Ruia
Software Design Engineer
IIS Core Server
eerichmond
1 Post
Dynamic Compression and Response.Close Bug
Sep 29, 2008 09:07 PM|eerichmond|LINK
It seems like IIS7 has a bug where if dynamic compression is enabled and you do a Response.Close() the last character of the response stream gets stripped off.
To test it just enabled dynamic compression in IIS7 and create a page with the following Page_Load method:
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("test");
Response.Flush();
Response.Close();
}
You should notice that the last "t" in the word "test" is missing when you display the page in a web browser. Disabling dynamic compression or commenting out "Response.Close()" eliminates the bug. If anyone has another work around or knows if this is truly a bug I would appreciate any feedback. Thanks.
IIS7 ASP.NET
anilr
2343 Posts
Microsoft
Re: Dynamic Compression and Response.Close Bug
Oct 03, 2008 08:54 PM|anilr|LINK
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.
In this particular case, compression involves looking for common patterns within the response and some amount of response has to be buffered by the compression code to increase the chance of finding longer repeating patterns - this part that is buffered cannot be sent to the client once you do Response.Close().
In short, do not use Response.Close().
Software Design Engineer
IIS Core Server
espresso
8 Posts
Re: Dynamic Compression and Response.Close Bug
Mar 23, 2009 04:08 AM|espresso|LINK
Ok, then what DO you use? Recently I was getting timeout errors when making a bunch of API calls one right after the other. Until I put in response.Close() I was getting that timeout error after only the 3rd SOAP API call.
espresso
8 Posts
Re: Dynamic Compression and Response.Close Bug
Mar 23, 2009 04:10 AM|espresso|LINK
anilr
2343 Posts
Microsoft
Re: Dynamic Compression and Response.Close Bug
Mar 26, 2009 10:41 PM|anilr|LINK
It is not clear what issue you were hitting - was the timeout at the client or the server side? Resetting the connection to avoid a timeout seems like a band-aid and seems like you still have some bad problems lurking. Can you collect "failed request tracing" for the request sequence resulting in a timeout?
Software Design Engineer
IIS Core Server
SeanH
1 Post
Re: Dynamic Compression and Response.Close Bug
Jun 09, 2009 11:46 PM|SeanH|LINK
I found Replacing Response.Flush(); Response.Close(); With Response.End(); Resolved a similar issue with dynamic compression for me.
anilr
2343 Posts
Microsoft
Re: Dynamic Compression and Response.Close Bug
Jun 10, 2009 04:36 PM|anilr|LINK
HttpApplication.CompleteRequest is the better one to use rather than Response.End - the latter results in a exception being raised which is going to cause performance problems, especially on x64.
Software Design Engineer
IIS Core Server