ASP.NET application exhibits strange behaviour through firewall

Question

This problem has been solved thanks to your suggestions. See the bottom for details. Thanks very much for your help!

Our ASP.NET website is accessed from several specific and highly secure international locations. It has been operating fine, but we have added another client location which is exhibiting very strange behaviour.

In particular, when the user enters search criteria and clicks the search button the result list returns empty. It doesn't even show the '0 results returned' text, so it is as if the Repeater control did not bind at all. Similar behaviour appears in some, but not all, other parts of the site. The user is able to log in to the site fine and their profile information is displayed.

I have logged in to the site locally using exactly the same credentials as them and the site works well from here. We have gone through the steps carefully so I am confident it is not a user issue.

I bind the search results in the Page_Load of the search results page the first time it is loaded (the criteria is in the query string). i.e.

if (!IsPostBack) {
  BindResults();
}

I can replicate exactly the same behaviour locally by commenting out the BindResults() method call.

Does anybody know how the value of IsPostBack is calculated? Is it possible that their highly-secure firewall setup would cause IsPostBack to always return true, even when it is a redirect from another page? That could be a red herring as the problem might be elsewhere. It does exactly replicate the result though.

I have no access to the site, so troubleshooting is restricted to giving them instructions and asking for them to tell me the result.

Thanks for your time!

Appended info: Client is behind a Microsoft ISA 2006 firewall running default rules. The site has been added to the Internet Explorer trusted sites list and tried in FireFox and Google Chrome, all with the same result.

SOLUTION: The winner for me was the suggestion to use Fiddler. What an excellent tool that no web developer should be without. Using this I was able to strip various headers from the request until I reproduced the problem. There were actually two factors that caused this bug, as is so often the case with such confusing issues.

Factor one – Where possible the web application uses GZIP compression as supported by all major browsers. The firewall was stripping off the header that specifies GZIP decompression support (Accept-Encoding: gzip, deflate).

Factor two – A bug in my code meant that some processing was bypassed when the content was being sent uncompressed. This problem was not noticed before because the application is used by a limited audience, all of which supported GZIP decompression.

Answer 1

Is it possible the client has disabled Javascript and it's not picking up the _EVENTTARGET form value?

Answer 2

It might be some sort of proxy which creates a GET request out of a given POST request...

I am not sure how the IsPostBack is calculated, but my guess would be that it checks the HTTP request to see if it's a POST or a GET...

Answer 3

Ohh, yeah. It's definitely NOT "_EVENTTARGET" BTW...

I know this since Ra-Ajax does NOT pass any of those parameters to the server and they (Ra-ajax requests) are processed as IsPostBack requests...

Answer 4

If they're at all tech-savvy, I would have them download Fiddler or something similar, capture the entire HTTP session, and then send you the saved session. Maybe something in there will stick out.

Meanwhile, see if you can get an install of ISA Server (an evaluation install, if you have to, or one from MSDN if you have or know anyone with a sub) and see if you can replicate it locally.

Answer 5

Could you create a test Post Page that passes the same things that your search page does, and in the Page_Load write back all of the post to make sure they are getting passed, particularly the __VIEWSTATE.

foreach (string key in Request.Form)
{
    Response.Write("<br>" + key + "=" + Request.Form[key]);
}

Then ask one of the users to forward back what they see on that test page.

EDIT: There is documentation that some firewalls can corrupt the VIEWSTATE and some methods to get around it: View State Overview

Answer 6

Location, location, location. Check the user's culture. Normally that causes issues.

Answer 7

Check the IIS logs to see if the request even makes it to your server. The ISA setup might be caching the initial request and serving that up in the succeeding requests.