IIS 7 and Above
Known Issues and Workarounds
Dynamic Compression and Response.Close Bug
Last post Jun 10, 2009 05:36 PM by anilr
Sep 29, 2008 10: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)
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.
Oct 03, 2008 09: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().
Mar 23, 2009 05: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.
Mar 23, 2009 05:10 AM|espresso|LINK
Mar 26, 2009 11: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?
Jun 10, 2009 12:46 AM|SeanH|LINK
I found Replacing Response.Flush(); Response.Close(); With Response.End(); Resolved a similar issue with dynamic compression for me.
Jun 10, 2009 05: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.