views:

149

answers:

1

We have some ASP.NET Web Services that fail under this perfect storm of conditions:

  1. IIS7
  2. Dynamic Compression is turned on
  3. Web Service call is Asynchronous

If it is IIS 6, or we turn Dynamic Compression off or call the web service synchronously, it works fine.

It fails in the call to SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult) with an 'Unexpected end of file' error.

Using Fiddler, I see that the response from IIS 6 has a transfer-encoding of 'chunked' and no content-length. The response from IIS 7 is NOT chunked and has a content-length. The end of file error occurs 1 character past the content length.

If I intercept the message in Fiddler and change it to chunked, there is no error. The answer could be to change it to chunked in IIS 7 (which I've tried to do and failed), but I don't feel like I should have to do this: I think it should just work!

A: 

I had to open an MSDN support ticket with Microsoft for this one, but got my answer.

The answer here is a simple client-side solution. My previous WebRequest method looked like this:

protected override WebRequest GetWebRequest(Uri uri)
{
    var request = base.GetWebRequest(uri);
    request.Headers.Add("Accept-Encoding", "gzip");
    return request;
}

The better way is this:

protected override WebRequest GetWebRequest(Uri uri)
{
    var request = (HttpWebRequest) base.GetWebRequest(uri);
    request.AutomaticDecompression = DecompressionMethods.GZip;
    return request;
}

I'm not entirely sure why this works: The headers on the request and response are exactly the same, but the client seems to be able to manage the response it gets back.

This seems to work with both IIS6 and IIS7, even though the IIS6 response is chunked and the IIS7 one isn't. If anyone can help explain exactly why this works, it might be helpful to the community.

pduncan