Intermittent receive failure using mvc webgrid on server only

Question

I am using the System.Web.Helpers.WebGrid extensively throughout our application, and for the most part it is fine and in fact running locally it is always fine or with a self SSL on the server it is also fine. So I don't know if the problem could actually be with IIS or a firewall, or the actual grid, or what I need to do to fix it.

On all browsers, although the result is slightly different, successive ajax sorting and paging on the WebGrid will eventially cause it to hang, and when I inspect the response in Fiddler I get

[Fiddler] ReadResponse() failed: The server did not return a response for this request.

If I copy and paste the url directly into a browser it will load but if I continually hit F5 I will eventually get a message stating "This webpage is not available" in chrome (with Error 103 ERR_CONNECTION_ABORTED) or "Internet Explorer cannot display the webpage" in IE.

The url is quite long and convoluted, something like http://app.myapp.com/mygrid/9e3b2ae5-cbe1-4a4a-a355-a14f00d26e24?mylayout=true&myid=634982439599769687&readonly=False&search=-&__=634982439708207187&sort=Name&dir=ASC

and this problem seems to go away if an SSL certificate is installed on the server, and doesn't happen at all locally.

Any ideas?

Renwick

Are you using any session or other shared variables on your server side code? – Shoebill

In general yes but for the grid controller I have [SessionState(SessionStateBehavior.ReadOnly)] so it's readonly and in fact nothing is retrieved from the session for this particular grid – Renwick

Even if you have [SessionState(SessionStateBehavior.ReadOnly)] set it acquires a lock to the session although the lock will be non-exclusive (i.e. another thread/request can request write access too). If there are any other requests that get a write lock your read-only request can pend indefinitely and can result in the condition described in your question if the request getting the write lock does not complete and release lock. – Shoebill

Also, depending on the technique used, even when you are not reading or writing to the session it might sill be read/resolved/fetched to you in the ASP page life cycle (or any framework equivalent). Remember that modern browsers make multiple requests simultaneously with the same session identifier/cookie/whatever resulting in possible problems when one of the calls is not going through. – Shoebill

I'm not sure this is the problem because the error happens immediately, rather than there appearing to be a lock – Renwick

Just a thought, with regards to the WebGrid, "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.", whilst this is a 'catch-all' statement there is the real possibility that by pressing F5 continually the ajax calls are not completing before you attempt another read that you are attempting to perform two reads at the same time without a queuing system ? Depending on the SSL stream in use theres a good chance you will have thread safety through it. – Unipod

When I paste the url into the browser that is just the same url called via ajax, so there are no further calls at that point. It will then eventually cause the error if I repeatedly hit f5 – Renwick

Which implies that ajax is potentially complicating the issue and that perhaps your use of webgrid is not threadsafe – Unipod

The problem never ever occurs via localhost though and no exceptions are logged on the server so I don't think it's even reaching my code – Renwick

Are you using ESET, Sophos or similar ?, i.e. something like ESET Firewall can poison your dns cache – Unipod

Yeah I think AVG business edition locally and I think a version of it is installed on the server. Could this be causing issues? – Renwick

In some cases, the firewalls will detect internal IP traffic from a network peripheral such as a router or printer as a possible threat. To determine this work out the safe IP ranges that calls could possibly be made on and make a rule in your firewall to allow these internal IPs. P.S. You haven't been fiddling with your hosts file have you? – Unipod

Did you check application logs, event logs etc ? – Glauconite

can you provide a sample application with your implementation how you put it together? – Ogpu

@TitalWave thanks that actually seems to have done the trick! - just disabled "Enable dynamic content compression" and "Enable static content compression" in IIS (probably didn't need the second – Renwick

@TildalWave sorry got your name wrong - that seems to have fixed it thanks! I can't award your comment however, and I think the time limit might have run out to award an answer but if you post an answer I will accept it. – Renwick

Answer 1

Your last paragraph of your question

and this problem seems to go away if an SSL certificate is installed on the server, and doesn't happen at all locally.

immediately made me think of possible issues with DEFLATE and GZIP problems, knowing they would be disabled on encrypted connection, and quite possibly also for local connections, as you can't really move the same certificate from the server environment to your local development environment (that would beat their purpose), and would have to create a new self-signed certificate for testing purposes, if that was a requirement.

I also happen to have stumbled across infinite loop may occur in GZipStream or DeflateStream issues before with one of previous .NET 4.0, version 4.0.30319.236 to be precise. These problems have been solved in later .NET 4.0 builds and can be avoided by installing .NET 4.5 on top of you 4.0 installation as well. If that's what was causing your problems, it's still rather difficult to say and some other server-side settings might have caused it, such as now discontinued IIS Lockdown Tool, or even URLScan not accepting lengthy URL requests when the compression for them is enabled.

TL;DR - Either case, the obvious conclusion was to try disabling IIS server's urlCompression for these requests (and/or httpCompression) in your Web.config file, and see if the issues still persist:

<configuration>
   <system.webServer>
      <urlCompression doStaticCompression="false" doDynamicCompression="false" />
   </system.webServer>
</configuration>

This is obviously a hack solution that should be looked into further, by comparing differences between server's and your local environments, if that is at all possible. It is also quite possible that the server wasn't updated with all the latest libraries, and doing so could resolve it as well.

DISCLAIMER: I realize this isn't really a 100% bullet-proof answer, however OP suggested in the comments that it did the trick. I have also posted this question and a possible answer to it on DMZ yesterday, asking if anyone else would know of a better answer and knowing these issues would be immediately recognized by our IT Security wizards, but the St. Patrick's day seems to have taken its toll :)

Cheers!

Previdi