易栈网-膘叔

以前，我说过有关于QR CODE的博客（QR CODE），也推荐了google的开源工具，事实上我的每篇博客右侧也都生成了二维码。

我这里是介绍的别人的文章 ，来自于：http://www.mikespook.com/index.php/archives/793

一些页面的宽高值，来自风干的果子。

前端对于这些值应该会比较关注吧。对于我这种虽然不从事前端，但了解一下也是很必要的。

 这是周爱民的文章，真的从来没有研究过这个会URL应该会有多长，http://blog.csdn.net/aimingoo/archive/2010/12/17/6081964.aspx，我这里不多贴多少，还是请看原文吧。

不过最后周爱民提出了几点：

五、技术成熟性与价值

1、twritter中早就使用这样的技术了。

2、与arale项目类似的，YQL(Yahoo! Query Language)项目也有类似的需求，因此他们将“在URL上传入一个sql”通过上述技术变成了一个短名，例如：
http://y.ahoo.it/iHQ8c0sv
相当于
http://developer.yahoo.com/yql/console/?q=select%20woeid%20from%20geo.places%20where%20text%3D%22san%20francisco%2C%20ca%22

3、微软还“傻傻说不清楚”，所以你看他们的官网很慢。^^.

4、当我们有条件将http头部减小到456字节以下时，应尽力为之。例如旺旺因为有独立客户端，所以可以定制http request head，以缩减User-Agent等字段。

5、当我们总是从浏览器端发出最小化的HTTP请求时，网络总是可以最快速的将请求提交到服务器，无需等待多个包并组合。这在慢速网络，以及存在大 量丢包的网络中效果将为极为明显。简单地说，如果有人在局域网中用迅雷或BT，那么最小化HTTP请求将会使网页的浏览体验提升得相当相当明显。

6、我们应该做脚本等静态资源的版本管理了。

--EOF--

可以看一下他为什么 这么分析的。。

yii在nginx下的配置好象有点麻烦，搜索一下how to hidden index.php file on nginx，可以搜索到官方的wiki。默认在guide里面是使用apache的，也就是里面的配置是针对.htaccess的。

然后我把官方wiki的内容复制到了nginx.conf里，却一直发现不成功，所以，只有等 明天再试了。
问了烂桔，他说的方法和官方的wiki里不太一致。在index.php后面没有$1，所以准备明天试一下。。
官方原文在这里：http://www.yiiframework.com/wiki/15/how-to-hide-index-php-on-nginx/

烂桔说，官方的这个：

location /yiiGuestbook {
    if (!-e $request_filename){
        rewrite (.*) /yiiGuestbook/index.php/$1;
    }
}

可以改成：

location /yiiGuestbook {
    if (!-e $request_filename){
        rewrite ^/(.*) /yiiGuestbook/index.php last;
    }
}

事实上，我在测试的时候，nginx的检测配置里好奇怪，如果我写 if(!-e xxx)，这样就报错，非要if 后面加一个空格 。还要(后也有空格。不然就报 !-e 是语法错误 。。
明天再测试 一下

以下遇到的问题我没有遇到过，不过我经常用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装过一个组件，用来处理白名单）