简单生活 -- Kevin Yang的博客 » IIS

IIS中使用子目录文件作为默认文档（Default Document）替代重定向

Kevin Yang — Tue, 14 Jun 2011 23:00:00 +0000

以前一直以为IIS应用程序的默认文档只能设置根目录下的文件，像index.html，default.aspx等，后来经同事指点，原来子目录或者子应用程序下的文件也可以添加到根应用程序的默认文档列表中。

之前为了实现这样的需求，当用户直接访问网站根目录http://www.example.com/的时候，将其重定向到子应用程序app的登录界面http://www.example.com/app/login.aspx，特意安装了IIS的重定向组件。其实也可以添加"app/login.aspx"到默认文档里头来实现。

不过对于子应用程序来说有一个限制，就是根应用程序和子应用程序需要使用同一个应用程序池，否则会出现跨应用程序池资源访问异常。

== Kevin Yang ==

标签：IIS, 工具技巧, 应用程序池, 技术随笔, 重定向, 默认文档

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

当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, 疑难杂症

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

（转）IIS6上启用Gzip压缩(HTTP压缩) 详解

Kevin Yang — Sun, 28 Jun 2009 13:07:00 +0000

摘要

本文总结了如何为使用IIS托管的网站启用Gzip压缩, 从而减少网页网络传输大小, 提高用户显示页面的速度.

前言.

本文的知识点是从互联网收集整理, 主要来源于中文wiki. 使用YSlow检测网站启用了哪些优化时, Gzip是十分关键的一项. 启动Gip压缩将立竿见影的减少页面的网络传输大小.

压缩概述

HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法。HTTP压缩采用通用的压缩算法如gzip等压缩HTML、JavaScript或CSS文件。压缩的最大好处就是降低了网络传输的数据量，从而提高客户端浏览器的访问速度。当然，同时也会增加一点点服务器的负担。Gzip是比较常见的一种HTTP压缩算法。

HTTP压缩工作原理

Web服务器处理HTTP压缩的工作原理如下：

1.Web服务器接收到浏览器的HTTP请求后，检查浏览器是否支持HTTP压缩；

在用户浏览器发送请求的HTTP头中, 带有"Accept-Encoding: gzip, deflate"参数则表明支持gzip和deflate两种压缩算法.

2.如果浏览器支持HTTP压缩，Web服务器检查请求文件的后缀名；

静态文件和动态文件后缀启动要所都需要在MetaBase.xml中设置.

静态文件需要设置: HcFileExtensions Metabase Property (单击跳转到MSDN说明)

动态文件需要设置: HcScriptFileExtensions Metabase Property (单击跳转到MSDN说明)

3.如果请求文件是HTML、CSS等静态文件并且文件后缀启用了压缩，则Web服务器到压缩缓冲目录中检查是否已经存在请求文件的最新压缩文件；

4.如果请求文件的压缩文件不存在，Web服务器向浏览器返回未压缩的请求文件，并在压缩缓冲目录中存放请求文件的压缩文件；

5.如果请求文件的最新压缩文件已经存在，则直接返回请求文件的压缩文件；

6.如果请求文件是ASPX等动态文件并且文件后缀启用了压缩，Web服务器动态压缩内容并返回浏览器，压缩内容不存放到压缩缓存目录中。

在IIS6中启用HTTP压缩

IIS默认并不支持HTTP压缩，需要进行简单的配置

1.打开Internet信息服务(IIS)管理器，右击"网站"->"属性"，选择"服务"。在"HTTP压缩"框中选中"压缩应用程序文件"和"压缩静态文件"，按需要设置"临时目录"和"临时目录的最大限制"；

2.提醒: 经试验此步骤在本人机器上没有作用, 可以忽略.

在Internet信息服务(IIS)管理器，右击"Web服务扩展"->"增加一个新的Web服务扩展..."，在"新建Web服务扩展"框中输入扩展名"HTTP Compression"，添加"要求的文件"为C:\WINDOWS\system32\inetsrv\gzip.dll，其中Windows系统目录根据您的安装可能有所不同，选中"设置扩展状态为允许"；

3.使用文本编辑器打开C:\Windows\System32\inetsrv\MetaBase.xml(建议先备份),

找到Location ="/LM/W3SVC/Filters/Compression/gzip用于设置gzip压缩，

找到Location ="/LM/W3SVC/Filters/Compression/deflate"用于设置deflate压缩.

上面两个节点紧挨着.并且设置的属性相同.

如果需要压缩动态文件，则将HcDoDynamicCompression设置为"TRUE"，并在HcScriptFileExtensions中增加您要压缩的动态文件后缀名，如aspx；如果需要压缩静态文件，则将HcDoStaticCompression和HcDoOnDemandCompression设置为"TRUE"，并在HcFileExtensions中增加您需要压缩的静态文件后缀名，如xml、css等；HcDynamicCompressionLevel和HcOnDemandCompLevel表示需要的压缩率，数值在0-10, 默认为0.

HcDynamicCompressionLevel属性说明:HcDynamicCompressionLevel Metabase Property

HcOnDemandCompLevel 属性说明:HcOnDemandCompLevel Metabase Property

说明: 这两个属性值一般推荐设置为9, 具有最佳性价比.但是在我的window server 2003上, 压缩率无论如何设置, jQuery和jQuery UI两个文件(58k/188k)压缩后的大小一直相同.(20k/45k).

下面是我的实例:

4.编辑完毕后保存MetaBase.xml文件；如果文件无法保存，则可能IIS正在使用该文件。打开"开始"->"管理工具"->"服务"，停止"IIS Admin Service"后，即可保存；

5.最后，重新启动IIS。可以到HTTP压缩测试网站验证结果.以jQuery为例, 核心类库和UI类库原始大小分别是57k和188k,压缩后分别是20k和45k:

我们通过Http头中的: Content-Encoding:gzip 属性判断返回后的数据已经启用了gzip压缩:

使用YSlow检测, 当只启动静态文件压缩时, Gzip压缩评级为B:

当同时启动了动态文件压缩时, Gzip压缩评级为A:

要点总结

1. 在修改MetaBase.xml文件时, 要停止"IIS Admin Service"服务. 否则无法保存.

2.静态压缩和动态压缩率最好设置为9.

3.上文的步骤2, 即使不添加Web服务扩展效果也是相同的.

4.压缩率设置对js文件不起作用, 压缩后大小总是相同的.

5.图片文件即使启用了gzip压缩大小也没有变化.

标签：GZip, HTTP, IIS, IIS6, 压缩, 技术随笔