简单生活 —— Kevin Yang的博客 » HTTP Watch

Silverlight启用Assembly Caching之后铁通用户无法访问

Kevin Yang — Sat, 13 Feb 2010 05:24:00 +0000

去年年底的时候，有客户向我们公司反映，他在自己公司内网（铁通ADSL）无法访问我们的Silverlight应用程序，而在他家里（网通ADSL）就可以正常访问。我们其他的客户并没有反映过类似的问题。

问题分析排查

由于他用的是笔记本，在家里和在公司访问时的系统环境是一样的，这样也就排除了系统环境的原因。那只能怀疑是网络环境的问题了。后来在现场使用HTTP Watch调试发现，当Silverlight在下载其中几个缓存程序集的zip包（我们的Silverlight应用程序启用了Assembly Caching）时，HTTP请求被302永久重定向到一个奇怪的IP上。

这样，由于zip包和Xap包地址的主机域不同，构成跨域，Silverlight会要求zip包所在的网站提供clientaccesspolicy.xml或者crossdomain.xml文件。而那个奇怪的IP所在网站下根本就没有这两个文件，所以请求失败。进而导致整个程序挂掉。

Assembly Caching程序集缓存

Assembly Caching（又称Application Library Caching）是Silverlight 3的新特性。以前Silverlight都是将所有用到的dll放到一个xap包之中，这样整个xap包会很大，下载相对比较慢。启用Assembly Caching之后，Silverlight工程用到的dll就可以在编译的时候自动打包到各自的zip包中，然后Silverlight在加载Xap包之后会自动下载这些zip包并解压出里头的dll，然后加载到应用程序域中。这样一来可以大大提高程序集下载的并行度，同时也可以使到不同Silverlight程序之间可以利用浏览器缓存而无需重复下载。

Silverlight在加载Xap包之后会去读取xap包中的appmanifest.xaml文件，然后下载该文件中指定的程序集文件。如果程序集文件Url和当前Xap包Url构造跨域（参考Silverlight SDK文档），则Silverlight会向该程序集所在网站的根目录请求跨域策略文件。

为什么会被重定向

这个问题困扰了我们很久。当时我们的第一反应是怀疑网关设置了什么规则。当用户访问特定Url的时候，触发了这个规则，导致HTTP请求被挟持。但是和客户公司网管沟通之后，对方明确表示并没有设置过类似的规则。

直到最近，客户和电信通（率属铁通）的人沟通之后，那边的技术人员说这是由于铁通的缓存加速服务器造成。据说是铁通为了让用户下载更快，就将某些HTTP请求进行重定向。后来电信通的技术人员告诉客户他们已经没问题了，但是他们并没有告知详细的问题所在，到底是由于我们的HTTP请求碰巧符合特定规则，还是怎么回事。也不知道他们是怎么解决的，是只将客户公司的IP列入禁止缓存列表，还是将我们Silverlight应用程序使用的域名加入禁止缓存列表，我们都无从知道。对于我们来说，这并没有真正解决问题。如果将来其他客户也通过铁通访问我们的产品，那么可能还是会出现类似的问题。由于我家里也是铁通的网络，所以我决定自己研究一下到底是怎么回事。

由于铁通那边没有任何可用的技术信息，Google也没有找到有价值的信息，唯一猜测的就是HTTP请求可能符合特定规则然后就被无辜重定向了。因此我只能采用最原始的人肉测试了。尝试不断的调整出问题的Url然后看是否被重定向了来发现规律。修改zip包所在目录，修改zip包文件名，修改zip包后缀，修改IIS的MIME类型，测试不同域名，等等。在历经100多次尝试之后，终于发现了当文件大小超过40K左右，并且后缀名是zip或者rar等常见的下载文件后缀，就会被铁通重定向。而且有时候第一、二次不会被重定向，刷新多几次的时候就才会被重定向。后面一点让我走了不少弯路，多少次我以为找到规律了，最后验证结论的时候还是错了。

o(︶︿︶)o

怎么解决

知道具体问题所在之后，我们几个技术人员就开始讨论如何解决这个问题。由于Silverlight对于缓存程序集打包之后的文件后缀没有要求，不管什么后缀，都会以zip文件流的格式去解析。因此可以修改打包文件的后缀来“逃过”铁通的魔掌。

修改文件后缀也有两种方法。

一种是在部署的时候，通过自动化脚本，修改所有zip文件后缀，然后修改xap包中appmanifest.xaml里头程序集的Url。这种方式的好处是一劳永逸，通用性强，以后部署的时候只需要执行一次脚本即可，其他应用程序可以共用。缺点是脚本编写比较复杂，并且部署的时候需要多加一步。

另外一种方法是将用到的Silverlight系统程序集放到工程底下，然后修改同名的xml配置文件，使其打包的文件使用其他后缀名。好处是这样编译完之后就可以直接部署了，无需执行什么操作，也不需要写脚本。坏处就是首先需要修改所有现有的工程，而且以后如果要开发新的Silverlight应用，也要记得这么做。

不管怎么样，这两种方法都不简单。后来我就想，既然客户可以和电信通联系，为什么我不可以直接和铁通联系呢。我就上网搜了一下北京铁通客户中心，找到申诉通道，填写完整的申述理由。然后第二天又打他们的客服电话去骚扰他们。结果过了两天，申述结果就下来了，“问题已解决”。对方客服还本着能自己动手决不麻烦别人的精神，帮我填写了用户满意度一栏：“非常满意”。

更深层的东西

其实最终解决问题的办法非常简单，就是投诉。我不满意你的服务，我就有权利投诉你。可是为什么一开始没有意识到这种解决办法呢？

我觉得这是和我们接触的社会环境有很大关系。我们潜意识里头已经习惯了各种中国式的流氓。运营商喜欢往你访问的网站中插播广告，访问我自己的博客偶尔还有弹窗广告；上Google搜索技术资料，一不小心点了blogspot的链接就导致Google被重置了，然后就10分钟不可用。没有明文规定告诉你什么是被禁止的，我们只能人肉测试。我们除了接受、适应并绕过这种事实之外还能做什么？也许我们还可以发出几声“中国式的抗议”吧。

言多必封，不多说了。

——Kevin Yang

标签：Assembly Caching, HTTP, HTTP Watch, Silverlight, Silverlight, 跨域, 重定向, 铁通

你可能对下面的文章感兴趣

Asp.Net页面的编码问题

Kevin Yang — Fri, 27 Nov 2009 06:13:00 +0000

莫名其妙的问题

这些天，一个客户的网站遇到了一些莫名其妙的问题。先是首页在Firefox下看正常，但是在IE上看，同个样式表文件，却有部分样式没能加载，导致导航菜单没有背景并且走位了。后来样式的问题解决了，但是又出现了一个页面上，部分文字乱码部分正常的诡异问题。

字符编码导致的样式文件解析错误

对于第一个问题我的第一反应是CSS样式表中部分样式存在不兼容性。但是检查了导航菜单样式的写法，没有看出来有什么特别的，都是常见的属性常见的值。但是用IE自带的开发者工具看了一下出问题的元素的样式，发现和在Firebug中看到的样式居然不同。后来无意中在HTTP Watch中看了style.css文件的内容，发现注释有乱码，当即联想到以前写过的文章《文档字符集导致的脚本错误》。当一个文档（HTML文档或是CSS文档）的文件存储字符集和浏览器解码使用的字符集不一致的时候会出现类似的问题，特别是utf-8编码过的文档却以gb2312去解码的时候，出现的问题就更诡异了。

于是我在IE上改用UTF-8去解析网页，结果果然，导航菜单的样式正常了，背景图片也正常加载了（虽然其他地方出现了一些乱码情况）。这证明了我的思路是对的。但是具体是哪个地方出了问题呢，为什么Firefox、Opera和Chrome下都没问题，偏偏就IE有问题呢？

我又仔细查看了客户给出的网页和样式文件，又分析了相关的HTTP消息，发现请求.aspx文件（出问题的网页文档）的时候，服务端返回的Content-Type是text/html;charset=gb2312，那么所有浏览器自然会以服务器返回的字符集来解析文档，这个没问题，但是当网页中引用了外部资源的时候（在这里是css样式表），IE是使用当前网页的文档字符集去解析此外部资源，除非外部资源声明了编码格式（HTTP响应头中声明或是在文档最前方使用@charset声明），而Firefox、Opera和Chrome在CSS文件没有显式声明字符集的情况下，始终是以UTF-8来解码的。

问题既然和样式相关，也就是说在使用gb2312解析该样式表的时候出现了问题，那可以猜到，样式表文件实际的存储格式是utf-8的。

为了找到具体出问题的地方，我用Notepad++——貌似手头只有这软件可以自由编解码——模拟了一下使用gb2312解码此utf-8格式的样式表的场景，发现了其中一段出问题的样式，UTF-8解码后很正常，因为本身就是UTF-8编码的：

/*新导航*/
#new_nav ul{ width:672px; height:33px; margin:0px; padding:0px;  }

当使用gb2312解码之后得到如下:

/*鏂板鑸?/
#new_nav ul{ width:672px; height:33px; margin:0px; padding:0px;}

很明显的，下面的样式都被注释掉了。自然一切问题都得以解释了。

解决办法很多种，但目标都是一个，保证文档声明和实际字符集的一致。对于CSS样式表，我们可以在文件头显式设置@charset ‘XXX’来声明字符集。或者在使用link引用外部样式表的时候显式加上charset属性。

另外，如果所有文件都能保存为utf-8 with signature的话，也就是带BOM标记的UTF-8编码格式，那么所有浏览器都能自识别，而不会产生识别错误的问题。

Asp.Net中涉及到的编码问题

第二个问题虽然我知道还是编解码的环节出了问题，但还是分析了我半天才找到问题所在。

测试环境简化

为了简单，我把第二个问题中涉及到的页面简化成如下两个文件：

Default.aspx文件：

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
head>
<body>
    <p><%= Msg %>p>
    <p>
        Aspx页面中的中文
    p>
body>
html>

Default.aspx.cs后台代码文件：

using System;
public partial class _Default : System.Web.UI.Page
{
    public String Msg = "代码中的中文";
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

两个文件非常简单，从aspx文件中输出一段文字，从cs文件中输出一段文件。

Asp.Net页面涉及到的编解码环节

为了理解第二个问题，我们首先先来看一下在Asp.Net中一个页面究竟会涉及到什么编码环节。

1. 文件本身存储使用的编码（在Visual Studio中新建文件的默认编码是UTF-8 With BOM）

2. 文件被Asp.Net引擎转换处理时使用的编码

3. 文件写到HTTP响应流时使用的编码

4. 文件在HTTP头声明的编码（Content-Type=”text/html;charset=xxx”）

对于第一个环节就不需要说了，直接“Advanced Save As..”然后选择相应编码即可。对于2、3、4环节中涉及到的编码，asp.Net提供了全局配置还有页面级配置两种方式。

在web.config文件中可以管理全局编码配置。

<configuration>
    <system.web>
        <globalization responseEncoding="utf-8" fileEncoding="utf-8" />
    system.web>
configuration>

在system.web一节下添加globalization元素，它有几个可配置选项，具体参见MSDN。其中有两个属性和此次的问题相关，一个是fileEncoding（注意区分大小写），这个配置项决定了asp.net引擎在将aspx文件以及cs文件合并成html文档时使用的编码。如果aspx或者cs文件的格式和此属性配置的不一致，那么就有可能导致生成的html文档出现乱码。默认情况下，该属性的值为ANSI编码，也就是说中文系统下为GB2312。但是如果文档本身存储格式是UTF-8 with BOM，那么asp.net将始终以UTF-8编码来解析aspx和cs文件。这也是为什么默认情况下什么都不需要配置的缘故。

另外一个属性是responseEncoding，这个配置决定了上述的第3、4环节，也就是当asp.net生成好html文档之后，将其写入HTTP响应正文时使用的编码，同时会设置HTTP的Content-Type响应头中的charset域。如果前面的环节没有问题，html生成正常的话，那么这里无论设置什么编码浏览器均会正常解码，页面上都不会有乱码。但是如果前面的步骤出了问题，那自然就会有乱码产生了。

注意上面4个环节我分别用了两种颜色来标明，看了上面的解释之后你就很明白了，1和2环节编码需一致，否则中间生成的html文档就已经有乱码了。3和4环节的编码须一致，否则浏览器显示不正常。

客户网站出现的部分文字乱码问题的原因就是因为aspx文件存储的格式是不带BOM标记的UTF-8（天知道他是怎么给整成这个编码的）而CS文件没有改动过，还是UTF-8 with BOM，而全局的fileEncoding没有配置，因此在第二个环节的时候使用gb2312去解析一个utf-8的文档，自然有问题，因此aspx文件中的中文显示为乱码，而cs文件中指定的中文正常显示。

上面介绍的是asp.net中的全局编码配置，其实针对每个页面还可以进行特殊配置。例如在aspx页面中的Page指令中可以添加ResponseEncoding属性。

或者我们可以在后台C#代码中利用Response对象。

Response对象提供了两个和字符集编码相关的属性，Response.Charset和Response.ContentEncoding。这两个有什么区别呢？ContentEncoding和web.config中配置的responseEncoding是等价的，都是既影响HTTP响应流编码又影响Content-Type响应头，而Charset影响的只是响应头Content-Type而已。将其设置为null的话，Content-Type中就不会有charset域了。

——Kevin Yang

标签：AspDotNet, Content-Type, HTTP Watch, Response, 字符集, 样式表, 疑难杂症, 编解码

你可能对下面的文章感兴趣

【推荐】两款HTTP流量分析工具的比较

Kevin Yang — Sun, 08 Nov 2009 09:19:30 +0000

做Web开发或者Web分析经常需要查看Http通讯的过程，项目实践中，很多Web相关的各种各样稀奇古怪的问题，最后都能通过分析HTTP流量得以解决。我到现在用过的比较好用的两个Http流量分析工具，一个是HTTP Watch，另外一个是Fiddler。

HTTP Watch

HTTP Watch是我最早用过的HTTP流量分析工具。它只能用于IE和Firefox浏览器上。

它有两种使用界面，一种是以插件的形式附加在浏览器上面，供实时分析使用。你可以看到当前窗口中所有的HTTP请求/响应过程。另外它允许把实时分析的结果保存为后缀名为hwl的文件，然后用其自带的Http Watch Studio工具打开，这样既方便了以后对此过程再次进行分析，也方便与其他人共享，易于调试。下面是它的插件界面的截图，非常清新简洁：

它的界面非常简单，主要分成三部分：工具栏，HTTP消息概览，HTTP消息细节窗口。

工具栏主要是方便你快速过滤出你想要分析HTTP消息。

你可以按照HTTP流量内容类型去筛选，例如只查看图片相关的HTTP流量。或者根据Url是否包含某特定字符串进行过滤，等等。另外工具栏也提供了“清缓存”和“清Cookie”两个非常常见的操作。

HTTP消息概览栏可以让你快速查看当前窗口中的所有HTTP消息，每个HTTP消息花费的时间，以及服务器返回的状态码，请求的Url等等。默认它还会按照HTTP消息发起的页面进行分组，方便查看。

最底部就是每条HTTP消息的详细信息。最后面的Stream标签页显示的是最原始的HTTP请求/响应流。这里记录的信息是最详细的。

为了方便分析常见的需求，它将HTTP消息分成几个部分，也就是你上面看到的Headers、Cookies、QueryString、PostData等等标签页所展示的内容。下面的图展示了此次HTTP通讯涉及的Cookie，每个Cookie的键值，作用的主机域以及路径、过期时间等。

HTTP Watch Studio就不做介绍了，基本和插件版本的一致，只不过可以脱离浏览器直接分析以前保存的HTTP通讯过程。

HTTP Watch提供了基础版本以及专业版本，其中基础版本是免费的。事实上基础版本提供的功能已经能够适用于大多数的情况了。

官方站点：http://www.httpwatch.com

Fiddler

Fiddler是微软推出的一个免费的HTTP流量分析工具。一开始我以为他只支持IE——毕竟是微软的东西——加之常见的功能HTTP Watch都已经够用了，就没怎么关注。这些天因为要调试Chrome浏览器上的一些问题，而Chrome自带的开发者工具又非常糟糕，搜着搜着又再次找到了Fiddler。

Fiddler的界面和HTTP Watch差不多，都是分成三部分，工具栏+HTTP通讯总览+HTTP消息细节。只不过默认情况下它把HTTP消息细节窗口放到了右边。

用了一阵子发现，HTTP Watch能做到的，基本在Fiddler上都可以实现。不过Fiddler的界面显得比HTTP Watch要复杂一些，因为它提供了一些HTTP Watch没有的功能。下面主要介绍的是它和HTTP Watch不一样的地方，一样的功能就略过了。

Fiddler能够监视所有本地进程的HTTP消息，而不仅限于IE、Firefox这些浏览器。这比HTTP Watch适用范围更广。下图显示了google talk和Visual Studio发起的HTTP请求.

安装完Fiddler之后你会发现IE还有Firefox中都多了个Fiddler的插件，Fiddler的原理实际上是在本地启动HTTP代理服务器，因为除了Firefox以外，很多应用程序包括其他浏览器都会应用IE上设置的代理。所以Fiddler只需要设置IE和Firefox这两个浏览器的代理服务器即可。这个插件做的事情实际上就是起到动态切换代理服务器的作用。

选中左侧某条特定的HTTP请求，Fiddler会在右侧帮你统计一下当前选中的HTTP消息的一些性能指标，例如发送/接受字节数，发送/接收时间，还有粗略统计世界各地访问该服务器所花费的时间。

在右侧窗口中，你可以采用各种视图去解析同一个HTTP请求/响应。例如以纯文本视图，或者图片视图，十六进制视图等等。它还提供了一个压缩测试工具，告诉你如果启用了Gzip或者deflate等压缩之后能够节省多少传输字节。

Fiddler会记录下每次HTTP通讯的过程，然后允许你在不将请求发送给服务器的情况下返回之前记录的响应结果。

Fiddler还允许你对HTTP请求下断点，然后你可以根据情况来决定每个请求所返回的响应。

如果你想测试一些特殊的HTTP请求或者修改当前请求一些报头的时候，你不需要自己再写一个小程序去实现这样的功能，因为在Fiddler提供了直接编写HTTP请求的功能。你可以模拟浏览器去发送HTTP消息。

Fiddler支持插件机制，如果你觉得它提供的功能还不够用，那么你可以安装各种插件以增强它的功能或者编写自己的插件。官网上提供了几个不错的插件供免费下载。一个可以用于对HTML和Javascript代码进行语法着色，还有一个可以监视Web应用程序的安全隐患。

官方站点：http://www.fiddler2.com

总结

总的来说，HTTP Watch的使用相比Fiddler更简洁、容易上手。但是只适用于IE和Firefox。Fiddler功能更为强大，适用范围更广，而且还是免费的。具体用哪个就得看实际需求了。

——Kevin Yang

标签：Fiddler, HTTP, HTTP Watch, 实用工具, 工具, 流量分析