ASP.NET应用程序通过防火墙展示奇怪的行

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.

我们的ASP.NET网站可从几个特定且高度安全的国际位置访问。它一直运行良好,但我们添加了另一个客户端位置,表现出非常奇怪的行为。

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.

特别是,当用户输入搜索条件并单击搜索按钮时,结果列表将返回空。它甚至没有显示'0结果返回'文本,因此就好像Repeater控件根本没有绑定。类似的行为出现在网站的其他部分,但不是全部。用户可以正常登录该站点并显示其配置文件信息。

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.

我在第一次加载时将搜索结果绑定在搜索结果页面的Page_Load中(条件在查询字符串中)。即

if (!IsPostBack) {
  BindResults();
}

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

我可以通过注释掉BindResults()方法调用来在本地复制完全相同的行为。

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.

有人知道IsPostBack的价值是如何计算的吗?是否有可能他们高度安全的防火墙设置会导致IsPostBack始终返回true,即使它是从另一个页面重定向?这可能是一个红鲱鱼,因为问题可能在其他地方。它确实复制了结果。

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.

附加信息:客户端是运行默认规则的Microsoft ISA 2006防火墙的后面。该网站已添加到Internet Explorer受信任的站点列表中,并在FireFox和Google Chrome中尝试过,所有这些都具有相同的结果。

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.

解决方案:我的赢家是使用Fiddler的建议。没有Web开发人员应该没有的优秀工具。使用这个我能够从请求中删除各种标题,直到我重现问题。实际上有两个因素导致了这个错误,因为这种混乱的问题经常发生。

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

因素一 - Web应用程序尽可能使用所有主流浏览器支持的GZIP压缩。防火墙正在剥离指定GZIP解压缩支持的头部(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.

因素二 - 我的代码中的一个错误意味着在未压缩发送内容时绕过了某些处理。之前没有注意到这个问题,因为应用程序被有限的受众使用,所有这些都支持GZIP解压缩。

7 个解决方案

#1

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.

如果他们精通技术,我会让他们下载Fiddler或类似的东西,捕获整个HTTP会话,然后发送保存的会话。也许那里的东西会突然出现。

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.

同时,看看你是否可以安装ISA Server(一个评估安装,如果你需要,或者一个来自MSDN,如果你有或知道任何人有子),看看你是否可以在本地复制它。

#2

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

是否有可能客户端已禁用Javascript并且它没有获取_EVENTTARGET表单值?

#3

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

它可能是某种代理,它从给定的POST请求中创建GET请求......

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

我不确定如何计算IsPostBack,但我的猜测是它检查HTTP请求以查看它是POST还是GET ...

#4

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

哦耶。这肯定不是“_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...

我知道这一点,因为Ra-Ajax没有将任何这些参数传递给服务器,它们(Ra-ajax请求)被处理为IsPostBack请求...

#5

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

位置,位置,位置。检查用户的文化。通常会导致问题。

#6

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.

您是否可以创建一个测试帖子页面,它传递与您的搜索页面相同的内容,并在Page_Load中写回所有帖子以确保它们被传递,尤其是__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

编辑:有文档说某些防火墙可以破坏VIEWSTATE以及一些解决它的方法:查看状态概述

#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.

检查IIS日志以查看请求是否已将其发送到您的服务器。 ISA设置可能正在缓存初始请求并在后续请求中提供该请求。

#1