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

当Google Analytics、Firefox和IIS走到了一起…

Kevin Yang — Sat, 29 May 2010 10:25:09 +0000

今天同事在投放AdWords广告的时候发现了一个诡异的现象：

使用Firefox点击AdWords广告跳转到客户网站上之后，再次刷新页面或者浏览其他页面均提示“Bad Request”的HTTP错误（错误码400）。
而IE、Chrome下则没有这个问题。

Cookie惹的祸

由于HTTP本身是无状态的，用来实现状态维持的技术一般都是Cookie。而之前我也遇到过几次因为Cookie导致的访问异常。一次是同事用Firefox死活访问不了新东方网站（参见我之前的文章：Firefox无法访问特定网站），一次是我自己死活登录不了Gmail帐号。这两个问题最终都是以清空Cookie解决的。所以这次有经验了，用web developer bar查看当前客户网站下都有哪些Cookie，一瞄，发现一个带乱码的Cookie。

不用想，也知道这是因为中文没有编码就直接塞到Cookie里头导致的乱码。看看Cookie的来头，__utmz，是Google Analytics（GA）植入的。删除此Cookie之后，访问正常。

Google Analytics的Cookie编码问题

同事测试的那个广告的Url添加了Google Analytics支持的跟踪参数，并且客户网站上也部署了GA的代码。

GA在执行时会检测当前Url中是否包含广告跟踪参数（至少必须包含utm_source），一旦发现，则认为是付费流量，这个时候它就会提取广告信息中的来源（utm_source），广告系列（utm_campaign）和广告媒介（utm_medium），对其进行解码（先尝试用decodeURIComponent函数，失败的话再用unescape函数），最后持久化存储到__utmz这个Cookie中。但是就在写入Cookie这一步，GA漏掉了编码操作。也就是说，如果我们的广告系列或者广告媒介的原始信息包含中文，那么GA就会直接往Cookie中塞入中文信息。

举个例子，我要为我的博客投一个宣传广告：

广告系列：Kevin博客宣传
广告来源：google
广告媒介：PPC
带跟踪参数的着陆页面Url：http://www.imkevinyang.com/?utm_source=google&utm_medium=ppc&utm_campaign=Kevin%E5%8D%9A%E5%AE%A2%E5%AE%A3%E4%BC%A0

那么GA在写Cookie的时候，会执行类似下面的代码（当然这里简化了__utmz的值）：

var data = "Kevin博客宣传";
// GA错误的Cookie操作
document.cookie = "_utmz=" + data;
// 正确的Cookie存储操作
document.cookie = "_utmz=" + encodeURI(data);

使用Javascript对Cookie进行存取，标准的操作应该是在存入的时候编一次码，取出的时候解一次码。这样保证存放在Cookie中的都是ASCII字符。早期JS使用escape/unescape进行编解码，现在通常使用encodeURI或者encodeURIComponent函数，这两个函数用的都是UTF-8编码。

中文Cookie潜在的问题

那么当我们直接将中文直接存到Cookie又会发生了什么事呢？IE和Firefox的行为有什么不一样的地方呢？我们在IE8和Firefox3.6下做几个实验。

IE8对中文Cookie的处理

实验步骤：

打开IE8，清空所有Cookie和缓存，建立干净的测试环境。
访问http://www.imkevinyang.com/
地址栏执行javascript:alert(document.cookie="mycookie=缂栫爜编码;expires=Mon, 25 May 2020 10:31:49 GMT")，写入一个持久化cookie。

这样就在我的博客上设置了一个2020年5月25号过期的cookie了。之所以要设置持久化cookie而不是会话Cookie，是因为IE会将持久化Cookie写入到硬盘上了，这样方便我们了解这个过程，而会话cookie我目前还不清楚他存储的位置。

细心的你会注意到，上面这个cookie的值很奇怪，有几个乱码。其实那段乱码是我把“编码”这两个汉字的UTF-8编码（6个字节）使用GB2312解码（每两个字节对应一个字符）后得到的字符。至于为什么要这样测试，一会我们就会知道了。

IE地址栏用的是ANSI编码，也就是说当你在地址栏输入中文的时候，IE会将中文字符以系统默认字符集进行编码。当你使用中文系统时，地址栏的“编码”字符，实际上最后会被编码为B1 E0 C2 EB四个字节，而在英文系统下，系统使用的是西方字符集作为默认字符集，没有中文字符，因此“编码”这两个字符会被替换成?，也就是3F。

IE在创建cookie文件，会自动选择最合适的编码。当我们写入“缂栫爜编码”（GB2312编码后得到二进制流E7 BC 96 E7 A0 81 B1 E0 C2 EB），由于最后四个字节无法用UTF-8解码，因此IE会将文件存储为GB2312。（如果你只测试“缂栫爜”的话，IE会将文件存储为UTF-8）。

好了，现在让我们来看看文件里头都是什么内容。

打开everything工具，搜索“www.imkevinyang txt”这样就会列出文件名包含www.imkevinyang和txt的所有文件。

打开这个文件，里头存放的就是IE持久化的cookie信息。

这个时候，我们再在地址栏通过javascript:alert(document.cookie)我们会发现，IE显示的Cookie值和我们一开始设置的是一样的。

看完了本地的Cookie信息，我们接下来看看IE发送给服务器的Cookie又是什么。

我们用Fiddler来监视整个HTTP通讯过程（这里不用HTTP Watch是因为HTTP Watch会将HTTP消息解码后显示出来，没办法看到原始二进制数据，不方便分析）。

我们再向我的博客首页发起一次访问，在Fiddler中我们会看到：

（文本形式）

（二进制原始数据）

我们很惊奇的看到，IE发送的并不是我们设置的那些字符“缂栫爜编码”（二进制是E7 BC 96 E7 A0 81 B1 E0 C2 EB），而是“编码��”（现在知道我为什么要用“缂栫爜编码”做测试了把）。对应的二进制是E7 BC 96 E7 A0 81 EF BF BD EF BF BD EF BF BD EF BF BD。注意到，IE将原始信息的后面4个字节替换成了EF BF BD.

这是因为IE发送HTTP消息的时候会检测字节流是否是能够以UTF-8解码，如果不行，那么会将相应的异常字节替换成EF BF BD（也就是对应�字符）。这有点类似于我们之前提到的，英文系统对于缺失的字符会使用?号替代。

Firefox对于中文Cookie的处理

Firefox不像IE那样把Cookie直接存储为文件的形式，所以我们研究起来没那么方便。

不过我们还是按照上面同样的步骤来做实验，不过这次为了简单起见我们修改一下测试的Cookie值。

打开Firefox，清空所有Cookie和缓存，建立干净的测试环境。
访问http://www.imkevinyang.com/
地址栏执行javascript:alert(document.cookie="mycookie=1编码1")

第一次Firefox弹出的对话框显示我们Cookie应该是设置成功了，返回“1编码1”字符串。

但如果你再次通过Javascript:alert(document.cookie)你会发现，这次弹出的内容变了：

我们通过Web Developer Toolbar查看当前域下的Cookie，发现，目前的Cookie确实是像上面第二个对话框所示的，是带乱码的：

我们现在关心的问题是，这个乱码是怎么来的？

我们先把这串文字拷贝到Notepad++中（注意，需要将Notepad++调到UCS-2编码状态下）看一下对应的字节是什么。

31是字符“1”的ASCII码。而16和01是哪来的呢？

其实是Unicode Code Point。“编码”的Unicode码是“7F16 7801”。上面显示的16和01就是截断了Unicode码高位得到的。为了证实这个结论，我又测试了好几个中文cookie，均是如此。

也就是说，Firefox的地址栏使用的是Unicode码，也就是说当你输入“mycookie=1编码1”这样的字符串的时候，Firefox看到的是：

\u006d\u0079\u0063\u006f\u006f\u006b\u0069\u0065\u003d\u0031\u7f16\u7801\u0031

在存储中文Cookie的时候，他会将Unicode的高位截断，保留低位。然后写入Cookie存储。这也是为什么我们会看到“编码”这个Cookie变成了“16 01”。

Firefox向服务端发送HTTP请求时对于http消息的编码处理方式和IE的一样，也是判断字节流能够以UTF-8进行解码，这里就不再赘述了。有兴趣的朋友可以按照上面的方法去测试。

为什么Firefox无法访问

基于上面对IE和Firefox对中文Cookie的处理方式的了解，我们现在可以知道，对于中文Cookie，IE是用ANSI编码，也就是说Cookie中永远不会出现ASCII字符集中的不可打印字符（GB2312编码每个字节也都是从A0开始的），而Firefox采用Unicode码，却又对其进行了高位截断，导致Cookie有可能会出现ASCII字符集中的非打印字符。

IE和Firefox在构造HTTP消息的时候对于字节流序列编码问题的处理方式一样。无法使用UTF-8解码的字节流序列，将其替换成EF BF BD，这个我们在Fiddler中已经看到了。而对于ASCII字符集的非打印字符则不做任何处理，直接发送到服务器端。

所以用Firefox访问，服务端收到的HTTP Request有可能包含非打印字符，而IE访问的话，则不会出现这样的情况。

例如Firefox上设置了一个中文Cookie，“我”，Unicode码是62 11，被Firefox高位截断了，就剩下11了，对应着ASCII码表中的Device Control 1，也就是控制字符。那么当你带着这个Cookie向服务端发起请求的时候服务端有可能就会直接抛出Bad Request的异常，告诉客户端，你发过来的请求不符合HTTP规范。

所以实际上不只是Cookie不能出现这样的非打印字符，其他HTTP Header中也不能出现这样的非打印字符。我们可以直接使用WFetch来构造这样的“非法”请求：

服务端一样会抛出400 Bad Request。

IIS和Apache的不同处理方式

当客户端发起的请求存在问题时，服务端的处理方式是取决于不同服务器的实现的。我们上面讨论的这个问题，实际上只会对IIS造成影响，对那些后台采用Apache或者LiteSpeed这类的服务器不会有影响。这说明IIS的容错性还是稍微差一点，不知道从安全的角度来考虑是好事还是坏事。

总结回顾

上面讲了那么多，你可能听着有点乱了。我们重新来整理一遍整个故事。

广告代理商投了一个广告，着陆页面Url中添加了google的广告参数，其中带有中文信息，客户网站上部署了GA代码，GA读取到此中文信息之后直接扔到Cookie中而没有经过编码。Firefox内部将此中文的Unicode码高位截断保留低位存下来。当你再次刷新页面的时候，Firefox把这个截断的字符发给IIS服务器，而刚好这个截断之后的字符是一个非打印字符，IIS觉得自己无法处理，就抛出一个Bad Request，告诉客户端此请求非法，我无法处理。

整个故事就这样。

怎么办呢？建议为了保险起见，如果客户网站服务器用的是IIS，那么你还是不要在Firefox上投放那些Url跟踪参数带中文（即使是UTF-8编码过）的广告了，否则可能浪费钱，因为用户来了，再点一次可能就无法访问了，而且以后可能都无法访问了（现在终于知道为什么我那同事当时用Firefox始终访问不了新东方了...）。(update:2010-7-2)或者你在投放广告的时候，Url参数中的广告系列、广告媒介以及广告来源这三个跟踪参数不要包含中文信息（即使是UTF-8编码过的），全部使用英文，这样也不会有问题。

希望整个分析过程对你有所帮助。

——Kevin Yang

标签：Bad Request, Cookie, Fiddler, Firefox, Google Analytics, HTTP, IE, IIS, WFetch, 中文, 疑难杂症, 非法请求

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

64位系统下IIS7 ISAPI处理器加载失败

Kevin Yang — Tue, 04 May 2010 16:01:18 +0000

症状

公司一台数据库服务器上部署了IIS网站（IIS7），利用Sql Server Analysis Services的msmdpump.dll组件，实现了通过HTTP层来访问Analysis Services（MSAS不支持HTTP远程访问，非HTTP的远程访问也一直没成功过）。运行状况一直良好，最近突然罢工。Debug发现在建立连接的时候总是抛出“The Connection either timed out or was lost”。

诊断

尝试用企业管理器直接连接Analysis Services，成功，数据访问也正常，说明Analysis Services服务运作正常。那看来问题是出在了IIS这一层。

直接在浏览器中通过http://machinename/olap/msmdpump.dll去访问的时候，会弹出一个保存文件的对话框。正常情况下，服务器会返回500，因为没有数据输入。现在弹出保存文件的对话框，说明IIS把这个dll资源当作一个普通文件来对待了，而不是调用ISAPI处理器来处理。

细看了网站的配置，似乎没有问题，重新部署了一个网站，重新配置了ISAPI处理器映射，问题依旧出现。

自己探索了很久，未果，Google了很久，一篇文章（IIS7 - Running 32-bit and 64-bit ASP.NET versions at the same time on different worker processes）提醒了我。这篇文章讲的是如何在不同的应用程序池进程上同时使用32位和64位的Asp.Net。

公司服务器出于性能考虑，用了64位系统。相应的msmdpump.dll文件也是64位的，但IIS的应用程序池进程是多少位的，我倒还真没考虑过。任务管理器一看，只有一个"w3wp.exe * 32”，果然是32位的。那问题的原因应该是，32位的应用程序池无法加载64位的Isapi处理器。

知道了问题所在，解决方法也很简单，启动一个64位的应用程序池就行了。打开应用程序池的高级设置，找到了“启用32位应用程序（enable32bitAppOnWin64）”的设置，将其从原来的True改成False（默认值为False）。这个选项的作用就是允许在64位操作系统上，以32位的应用程序池去加载32位的程序。

之所以会突然出现这个问题，是因为IIS的机器配置文件ApplicationHost.config文件中，全局应用程序池的enable32bitAppOnWin64默认值被意外修改为True。而我部署的IIS网站，由于没有显式设置此选项，因此会继承ApplicationHost.config文件中的默认值。

举一反三

64位系统下经常会出现一些莫名其妙的问题。因为64位系统允许运行32位应用程序，但是32位程序却无法加载64位程序集。所以如果你发现你的32位程序无法正常启动，查一查是否因为目标程序集是64位的缘故。例如最近安装了微软的StreamInsight，发现是32位的，但是本地的Sql Compact Framework是64位，结果启动的时候抛出了个DllNotFoundException。

——Kevin Yang

标签：Analysis Services, HTTP, IIS, IIS7, ISAPI, 疑难杂症

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

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, 跨域, 重定向, 铁通

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

【推荐】两款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, 实用工具, 工具, 流量分析

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

使用相对Url无缝切换HTTP-HTTPS

Kevin Yang — Thu, 17 Sep 2009 18:05:40 +0000

概述

在HTTPS的网站下，如果要访问HTTP资源，那么一般浏览器会弹出窗口询问用户是否允许加载不安全内容，云云。为了避免出现这样干扰用户的情况，所有网页下请求的资源都都必须是HTTPS资源。如果你的站点支持HTTP和HTTPS两种方式访问，而实际网站只有一份的话，这种情况下，你可以使用相对Url的方式改写网页内资源的请求Url。

省略Scheme的相对Url语法

Url相对路径我们并不陌生，下面这样的写法非常常见。

<img src='/images/myphoto.jpg' />
<img src='myphoto.jpg' />

如果该HTML代码放在http://myexample.com/myblog/index.html上，那么第一幅图片的实际完整地址就是http://myexample.com/images/myphoto.jpg，而第二幅图片的实际地址是http://myexample.com/myblog/myphoto.jpg。

但是省略Url中的Scheme部分这样的相对路径写法却比较少见。例如：

<img src='//myimagehosting.com/images/myphoto.jpg' />

这行代码如果放在HTTP的网页上，那么请求的资源就是HTTP://myimagehosting.com/images/myphoto.jpg，如果放在HTTPS上，则访问的资源就是HTTPS的。这样一来我们就无需为HTTP和HTTPS各自准备不同的网页了。

标准规范

RFC1808文档是专门针对相对URI的，其中提到，除了URI中的Scheme部分，其他部分均可以做适当的省略。也就是说，这样的写法是不符合规范。RFC1808文档是95年的时候定稿的。后来的RFC3986文档对URI做出了更为详细的规范，废弃了RFC1808对相对URI引用的建议规范（4.2 Relative Reference一节）。

以Scheme:开头的（如http:、file:、ftp:）均为绝对URI引用。否则为相对URI引用。

相对路径 = 相对部分 [ "?" 查询参数] [ "#" 锚点]

其中相对部分可以有以下几种情况：

1. //主机域绝对路径或者留空

2. 绝对路径

3. 相对路径

4. 留空

也就是说，以下几种情况均是合法的相对URI引用：

<script src='//myscript.com/script.js?cid=abcd'>script>