易栈网-膘叔

以下遇到的问题我没有遇到过，不过我经常用IE6打开网站后，突然间就显示该页无法显示，不知道是否类似原因 。。。

症状【并非我自己的问题】：最近发现自有产品的试用系统有些页面在提交时无反应，等了很久之后显示“Internet Explorer 无法显示该网页”错误；类似的还有一些链接点击之后无反应，等了很久之后显示“Internet Explorer 无法显示该网页”错误。更为离奇的是：

1. 这个错误无法在开发电脑上重现，试用完全相同的程序和数据，在开发电脑上就完全不会出现错误。
2. 使用IE8访问出错，使用IE6或IE7访问时偶尔出现错误，而使用Firefox和Chrome则完全不出错。

牛刀小试

尝试一：是不是IE浏览器脚本兼容性问题？

错误只发生在使用IE浏览器的情况下，是不是IE浏览器和页面上的脚本不兼容造成的？在开发电脑上无法重现错误，可能是因为局域网内使用IE8访 问，实际是运行在IE7模式下，在IE7只偶尔出现错误，因此无法重现。基于这个假设，开始尝试找出是什么脚本导致错误，首先怀疑IE8的XSS过滤机 制，手工关掉IE8的XSS过滤，错误依旧。仍然不死心，也许XSS很顽固，没有真正关掉。所以又将QueryString传递的参数进行编码解码，避免 被浏览器误认为存在XSS攻击，还是没解决。

尝试二：是不是IE浏览器无法处理长路径？

老是怀疑IE浏览器也是有原因的，因为使用Firefox和Chrome时完全不出错，各种证据下IE的嫌疑最大。出错的页面和链接都有一个共同的 特点就是页面的路径比较长，大都在500字符以上，因此怀疑IE8浏览器处理长路径是不是有问题。通过调整程序缩短了页面路径后，错误暂时解决，但仍然有 几个疑点尚未弄明白：

1. 为什么IE8必然出错，而IE6和IE7只是偶尔出现错误？
2. 为什么在开发电脑上无法重现错误？同样是使用IE8浏览器访问，页面路径长度相同。为了尽可能模拟访问外部服务器的情况，特地修改了本机hosts文件，采用与外部服务器完全一致的域名来访问，仍然不会出现错误，为什么会这样？

重新分析问题的真正原因

上面虽然没有找出问题的真正原因，但也还是有两个收获：通过尝试一可以排除XSS方面原因，而通过尝试二发现了这个错误与页面路径长度有一定的联系。

这个错误仅出现在IE浏览器上，是否是IE浏览器发生错误，导致请求没有发出？通过Fiddler侦听发现，请求其实是发送出去了，但一直没有收到服务器的响应，因此将怀疑的目标转移到服务器上。

在服务器上通过分析IIS日志，发现IIS并没有收到请求，反复测试确认，在服务器上确实没有收到请求。

浏览器发出了请求但服务器端没有收到请求，那么问题一定就出在传输环节，这时突然想起机房前段时间搞了一个白名单过滤系统，问题是不是就出在这个白 名单系统上。如果真的是机房的白名单系统出了问题，那么之前的很多疑团就可以解释清楚了。比如：本地无法重现，是因为本地并没有白名单系统；浏览器发出了 请求，而服务器端没有收到，是因为白名单过滤系统将请求过滤掉了；白名单过滤系统有BUG，导致IE浏览器的长路径请求无法正确处理，而被错误过滤等等。

分析了这么多，疑点都集中到机房白名单过滤系统（以下简称白系统）上，但终归只是猜测而已，还需要更确切的证据来证实。机房不会配合我来调查，更不会透露关于白系统的任何细节（这种系统见不得光），唯一的办法就是找到白系统出错的规律，通过反证的方式来找出证据。

黑盒分析白名单过滤系统

设想一下，如果让我来写一个白系统的话，应该这样来实现：过滤所有的HTTP请求头，分析请求头中的Host属性值（主机头+端口），如果该主机头 在白名单里，则允许通过，否则不允许通过。HTTP请求头可能很长，白系统不需要全部读完请求，只要读取到Host属性值即可。为了提高过滤效率，当 HTTP请求头很长时，白系统可能只读取分析开始的N个字节长度内容，剩下的内容就被丢弃，不进行分析。在这种情况下，如果开始的N个字节长度内没有找到 Host属性值，则该请求就会被白系统过滤掉。

所以白系统是根据HTTP请求头中的Host属性值来进行过滤的，IE浏览器的HTTP请求头格式与Chrome的Http请求头格式不同，特别是 Host属性的位置不同。IE浏览器中Host属性的位置靠后，大约在第七位；而Firefox和Chrome中Host属性的位置靠前，大约在第二位。 当页面路径很长时，Http请求头就会变得很大，这时候如果Host属性在Http请求头中的位置比较靠后，就可能超出了白系统的固定读取的N个字节的范 围，导致该请求被忽略。下面列出几个浏览器的Http请求头内容，供参考：

Chrome的Http请求（Host在第2行）

Firefox的Http请求（Host在第2行）

IE的Http请求（Host在第7行）

用Fiddler生成Http请求头来测试，并不断调整Host的位置，最终测试出漕宝机房白系统的读取长度为1470字节。如果Http请求头开 始的1470字节内没有包含Host属性的话，白系统会丢弃掉该请求，造成服务器端收不到该请求，客户端也因为收不到服务器端的响应而显示 “Internet Explorer 无法显示该网页”的错误。

一般来说，网页的Http请求头都不会太大，有些也只是最后的Cookie内容多一点，不会影响白系统的运行。但我们开发的这套企业管理软件的某些 页面使用QueryString方式在页面间传递参数，这样可能导致页面的url地址很长，虽然我们控制了url地址的最大长度（小于1024），但没有 想到这个长度已经超过了机房白系统的处理范围。

特别是页面回发的情况下，请求头中会包含两次Url地址（请求地址和Referer分别一次）。假设url地址有1000字节，Firefox和 Chrome的Host属性在第二位，从开始读取1470字节的话，一定可以读取到Host属性值。而IE则不行，Host属性前面还有Referer属 性（长度1000字节），加上页面路径本身有1000字节长度，Host属性前至少有2000多字节，所以白系统只读取开始的1470字节，是不可能读取 到Host属性，因此请求被白系统过滤，造成客户端点击按钮提交后长时间收不到响应，最后显示“Internet Explorer 无法显示该网页”的错误。

题外话-关于白名单过滤系统

为了提高过滤效率，机房的白名单过滤系统大都采用监听加干扰的方式，一旦发现某客户端有非法请求，就先于服务器给该客户端一个错误的响应，这种情况 下，客户端会很快显示错误信息。但这次的白系统似乎是采用水闸大坝的方式实现（这种方式很低效，以后要考虑换机房），发现非法请求后就丢弃该请求，导致客 户端长期等待响应，最后等待超时，才显示错误。正是这种长时间的等待，才误导我一开始就怀疑是浏览器的问题。

--EOF--

这个问题我没有遇到过，不过我想或许可以参照一样。。。原文来自：http://www.cnblogs.com/rrooyy/archive/2010/12/09/1901304.html，我从没注意过原来host的顺序还会影响网站的访问（白名单这个问题确实很让人痛苦。以前我的SERVER还被edong装过一个组件，用来处理白名单）

随便记录。。。

1、新站上线时，别忘了去几个重要搜索引擎的网站进行登录，以下是这些搜索引擎登录入口地址:

百度：http://www.baidu.com/search/url_submit.html

Google：http://www.google.com/intl/zh-CN/add_url.html

Google香港：http://www.google.com.hk/addurl/?continue=/addurl

网易-有道：http://tellbot.yodao.com/report

SOSO：http://www.soso.com/help/usb/urlsubmit.shtml

搜狗：http://www.sogou.com/feedback/urlfeedback.php

中国雅虎：http://search.help.cn.yahoo.com/h4_4.html

微软Live&Msn：http://search.msn.com.cn/docs/submit.aspx

2、一些常见的搜索语法，如：site:neatstudio.com ，link:neatstudio.com ， domain:neatstudio.com 等

一般来说，site指令是用于查看该域名下所有的网页数，大多数时候我们用来查看网站的收录 。

link指令几乎都是查看反向链接的，但百度好象不太一样，它认为link还是一个搜索的关键字，而没有任何意义

domain，百度是查网页内容中包含某关键词，GOOGLE无意义，YAHOO嘛和site指令一样。

因此，在这种情况下，几乎我们就用site指令和link指令了。。。不过百度怎么查外链呢？好奇怪 啊。

这是今天中午发生的事情，有人在群里求助，比如xml中如果标记是<xx:xxxx>content</xx:xxxx>这样的情况下，取不到 xx:xxxx 为下标的值。
看了这个问题，第一个反应就是namespace的关系，但我从来没有使用simplexml操作过namespace，于是就翻开手册查了一下资料，问题并没有解决，最终是通过google解决了该问题。

提问题的朋友贴出了数据源，来自于：http://code.google.com/intl/zh-CN/apis/contacts/docs/3.0/developers_guide_protocol.html#retrieving_without_query，数据结构大致如下：

这个结构在上面的地址里有，这个是我格式化过的XML数据，现在要取得类似于“<gd:phoneNumber rel='http://schemas.google.com/g/2005#home'        primary='true'>        456      </gd:phoneNumber> ”中的值。

最终代码如下：

当然，如果不象上面这样写，也可以写成这样：

只是象第二种写法就属于硬编码了，这样不太好，万一哪天有变化，还得再更改N多代码。
问题接踵而来，比如象下面这段：

这种非标准的XML，没有定义命名空间，怎么办？在这种情况下，其实SimpleXmlElement就已经直接可以解决了，但是会报warnging,因为他认为event这个命名空间不存在。
解决方法是：

目前看来，这种解决方法比较好。

在转这篇文章之前，我先说一点项目中遇到的问题，公司的主页最近改版上线，但是上线后出了一点问题，是CSS方面的问题。

CSS文件很多，前端把它分的很细，每一个小的widget部位就是一个单独的CSS文件，这样确实方便了有重复内容时的工作量减轻。于是我们在上线后，对CSS文件进行了合并，用的是Yii的插件 EclientScript（@hightman开发的一个插件）。CSS和JS都顺利合并了，但结果却不太正常。经过仔细检查发现是每个文件头的@charset=utf-8导致了这个问题。合并后，所有的文件内容都被引用到一起，所以造成了合并后的文件中“@charset=utf8”有好几个，但是为了保证文件是按utf-8格式被加载于是保留了最上面的@charset=utf8，其余的都删除了。OK，这时候所有的流量器都正常了。

结果第二天，老板过来说，在IPAD下不正常，于是继续排查，最终发现还是这个@charset=utf8的原因。前面说过，我们只保留了第一个文件的UTF8的判断，其他的都清空了，那为什么还会出错呢？经过测试，发现@charset=utf-8只能在第一行才有效，在其他行时，safari不认，而EClientScript在压缩文件后，会在文件第一行加上这个文件对应实际文件的地址，于是就让@charset=utf8到了第二行。所以IPAD上面显示就不太正常了。。

接下来就转载了：CSS通用元素选择器的都市流言，原文来自：http://shawphy.com/2010/11/css-universal-selector.html

本文尚未有测试数据支持，以下结论仅是根据现有情况的一种解释。

关于 * 这个选择器，一直有个疑惑，到底是否影响效率。在先前的观念中，这由于要匹配所有的元素，让每一个元素都带上这个属性，所以会影响页面的效率。但近来的思考，觉得这应该不会影响效率。为此还特地写过一篇博文，里边提到了这点：真的还需要reset.css么？

而这篇文章中我打算着重阐述为何 * 这个选择器不会影响效率。

上周六去参加了 web标准化交流会，席间 winter 从浏览器（webkit）的角度分享了关于页面渲染的过程。其PPT也可以在前面的链接中下载到。

其中一个很重要的过程是，当页面载入过程中，CSS 和 HTML 是并行下载的。并且通常CSS是在HEAD中引入的，并且体积不如HTML大，所以CSS会先下载完。下载的过程中浏览器就已经开始对CSS中的规则进行 索引，也就是已经确定哪一个元素呈现的样式是如何的了。同时，浏览器根据HTML构建出的DOM树，其中的每一个元素会直接去CSS规则索引中去比对，构 建出渲染树。这个过程都是并行的，并且CSS规则是进行了索引的，因此速度非常的快速。

那么我们看看CSS规则的来源主要有2个，一是浏览器内置的元素样式，Firefox 3.x版是放在目录下的res文件夹内，4.0版和Chrome中没找到（这里是我的主观臆断不太可靠，大家自行辨别），另一个就是页面提供的。根据查看 放在 res 文件夹下的 CSS 文件就可以得知，就是是什么样式都不写，已经为每一个HTML元素设定好了基本样式了。

那么看看我们所忌讳的事情，不用*{margin:0;padding:0}，而是使用

看看这一大坨东西啊，难道不是跟上面的 * 选择器一个用途么？对每个元素（至少是常用元素），添加样式。其实作用是一样的，并且就算没有这一坨，浏览器内置样式也在对每个元素设置样式。之后 HTML 文件中的每一个元素，可以很容易找到自己应当呈现的样式了。

那么，对于之后添加的，会不会有性能影响呢？也不会，由于CSS规则已经确定并索引了，所以今后增加的元素也不过就是简单比对一下而已，不会多走一步的。

所以，由此得出结论，只要有需要，大胆的使用 * 吧，他不会给你从性能上增加额外的麻烦。

最后补两个前端优化小知识：
1，由于CSS规则和HTML是并行载入的，因此把CSS放在HEAD中是非常有必要的。
2，少使用 :last-child 。因为这个选择器无法索引起来，必须等DOM构件完，才能知道他是不是父元素中最后的那个 元素。这种就非常慢了，慎用。

----EOF--

注：文中@charset=utf-8我格式可能写的不对，只是表达一个意思，因为我没有dreamwaver，而所说DW在写CSS的时候，默认会在第一行加上这个玩意。。。