IIS7 - Known Issues and Workarounds

Re: Dynamic Compression and Response.Close Bug

anilr — Wed, 10 Jun 2009 16:36:38 GMT

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.

Re: Dynamic Compression and Response.Close Bug

SeanH — Tue, 09 Jun 2009 23:46:06 GMT

I found Replacing Response.Flush(); Response.Close(); With Response.End(); Resolved a similar issue with dynamic compression for me.

Re: Dynamic Compression and Response.Close Bug

anilr — Thu, 26 Mar 2009 22:41:42 GMT

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?

Re: Dynamic Compression and Response.Close Bug

espresso — Mon, 23 Mar 2009 04:10:30 GMT

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.

Re: Dynamic Compression and Response.Close Bug

espresso — Mon, 23 Mar 2009 04:08:42 GMT

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.

Re: Dynamic Compression and Response.Close Bug

anilr — Fri, 03 Oct 2008 20:54:46 GMT

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().

Dynamic Compression and Response.Close Bug

eerichmond — Mon, 29 Sep 2008 21:07:49 GMT

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.