这两天网上开始疯传一个“nginx文件类型错误解析漏洞”，这个“漏洞”是这样的：
假设有如下的 URL：http://phpvim.net/foo.jpg，当访问 http://phpvim.net/foo.jpg/a.php 时，foo.jpg 将会被执行，如果 foo.jpg 是一个普通文件，那么 foo.jpg 的内容会被直接显示出来，但是如果把一段 php 代码保存为 foo.jpg，那么问题就来了，这段代码就会被直接执行。这对一个 Web 应用来说，所造成的后果无疑是毁灭性的。
关于这个问题，已有高手 laruence 做过详细的分析，这里再多啰嗦几句。
首先不管你是否有用到正则来解析 PATH_INFO，这个漏洞都是存在的。比如下面这个最基本的 nginx 配置：
漏洞同样会出现，如 laruence 所说，实际上这个漏洞和 nginx 真的没什么关系，nginx 只是个 Proxy，它只负责根据用户的配置文件，通过 fastcgi_param 指令将参数忠实地传递给 FastCGI Server，问题在于 FastCGI Server 如何处理 nginx 提供的参数？
比如访问下面这个 URL：
那么根据上面给出的配置，nginx 传递给 FastCGI 的 SCRIPT_FILENAME 的值为：
也就是 $_SERVER['ORIG_SCRIPT_FILENAME']。
当 php.ini 中 cgi.fix_pathinfo = 1 时，PHP CGI 以 / 为分隔符号从后向前依次检查如下路径：
直到找个某个存在的文件，如果这个文件是个非法的文件，so… 悲剧了~
PHP 会把这个文件当成 cgi 脚本执行，并赋值路径给 CGI 环境变量——SCRIPT_FILENAME，也就是 $_SERVER['SCRIPT_FILENAME'] 的值了。
在很多使用 php-fpm （<0.6） 的主机中也会出现这个问题，但新的 php-fpm 的已经关闭了 cgi.fix_pathinfo，如果你查看 phpinfo() 页面会发现这个选项已经不存在了，代码 ini_get(“cgi.fix_pathinfo”) 的返回值也是 “false”。
原因是似乎因为 APC 的一个 bug，当 cgi.fix_pathinfo 开启时，PATH_TRANSLATED 有可能是 NULL，从而引起内存异常，造成 php-fpm crash，所以 php-fpm 关闭这个选项。
前几天把工作平台从 Ubuntu 9.10 Karmic 更新到了 10.04 Lucid，由于 Lucid 官方源自带了 PHP5.3.2，以前使用的 dotdeb 的源就没法用了，一直很喜欢这个源的，不但提供了 PHP5.3 而且还有 php5-fpm 这个很实用的 fcgi 进程管理器，这个在官方源里面是没有的。强行上了 dotdeb 虽然也可以，不过必然有很多包会出现依赖问题，处理这些依赖关系是件很烦心的事情。哥啥都不怕，就怕麻烦～ 
对于 PHP 来说，php-fpm 还是最合适的，spawn-fcgi 这类东西就不用考虑了，我宁愿用 PHP5 内置的 FastCGI Server。
Read more…
在 cygwin 中编译 PHP 时遇到下面的问题：
解决方法：
重新运行 ./configure 后，问题解决。
XP 和早期的 Windows 中，你可以通过系统新增或者修改某些类型的文件图标，但是自 Vista 以后，这个功能就被 "Default Programs" 替代了，要修改图标只能依赖一些第三方软件。如果不想使用第三方软件，则可以通过修改注册表来手动更改文件的图标，以下以 PHP 文件为例：
按照配置文件，我的项目地址是：http://localhost/myproject/public，项目是部署在子目录 /myproject/public 里面的，如果你把 document_root 直接设置为 /myproject/public，使用 http://localhost 来访问，那么上述配置删除掉 index.php 前面的目录部分，也就是 rewrite ^/(.*)$ index.php last;
Nginx 不支持 Apache 的 .htaccess 文件，所以需要在 Nginx 配置文件中编写重写规则。Apache 的绝大部分 RewriteRule 命令都可以不做修改的放到 Nginx 中直接使用。你只要把 RewriteRule 改成 rewrite，[L] 改成 last 之类的就可以了，具体可以看一下 Nginx 的 Rewrite 文档。
http://wiki.nginx.org/NginxHttpRewriteModule
题外话，Zend Framework 越来越强大，越来越复杂了，很多追求“简洁”的 Coder 们都已经开始信誓旦旦的说要放弃 ZF 。有点搞笑，这就好像我在说：飞机太快了，价钱太贵了，不适合我，还是自行车好啊！有些人对待问题的看法极端又片面，就好像看电视剧的时候，也总是要把人分为好人和坏人一样，他们的想法很单纯——我不喜欢 ZF，因为臃肿、复杂，所以它是垃圾。
Nginx 是一个轻量级的高性能 Http WebServer，以事件驱动方式编写，因此相比 Apache 而言，Nginx 更加稳定、性能更好，而且配置简单，资源占用较低。以下是我在 Windows 7 安装中 Nginx 和 PHP5.3 的步骤。
安装 PHP5
首先，从 http://windows.php.net/download/ 下载最新的 PHP 5.3 Windows 版本，这里 PHP 以 FastCGI 模式运行，所以请下载 None Thead Safe 版本。
解压至 C:\php5，把压缩包中的 php.ini-recommended，更名为 php.ini，然后打开修改几个选项：
在 Akra’s DevNotes 看到的这篇文章，刚好最近两篇文章都是将乱码的，于是也搬过来了。
问题：
存储多字节字符到 MySQL，或者从 MySQL 中读取类似的数据，出现乱码。
解决方法：
在任何地方都使用 UTF-8 编码。
> 浏览器
或者使用一个 meta 标签来设置HTTP协议的响应头报文：
这行 HTML 代码会通知客户端浏览器，文件类型为 html，且使用了 utf-8 编码。
header()函数所发送的 HTTP，从优先级上面看，由于先一步被浏览器所接受，所以优先级更高（不知道可不可以这么说）。
Read more…
基本思路就是向数据库发送 SQL “SET NAMES UTF8″，可根据不同的情况来编写代码。
如：
这是早期的解决方法，其实并不推荐这么做，因为并不是所有页面都需要 SQL 查询，上述代码放在 bootstrap 中，在不需要 SQL 连接的页面中也会开启一次数据库连接并发送 SET NAMES UTF8 ，这就浪费了资源。
Read more…
Zend_Filter_Input 可以用来获得安全可靠的用户数据，简单的来说这个类就像一个黑盒，原始数据输入后，经过过滤器过滤，然后再由校验器校验，若通过了原先设定的过滤及校验规则，则最后输出可用的数据，否则给出详细的错误报告。
为了数据安全，比如转义一些特定字符，默认情况下 Zend_Filter_Input 会使用 HtmlEntities Filter 过滤所有的数据，然而不幸的是，这个 HtmlEntities 使用默认编码 ISO-8859-1，如果是中文等多字节语种，那么最后数据就会出现乱码，面目全非。
最近我在自己的项目中就遇到这个问题，其实解决方法很多，多写几行代码而已，但是因为乱码的问题由来已久，而且造成乱码的原因也非常多，找不到问题所在，那就恼火的很了，这里简单总结了一下。
Read more…
以前在使用 xdebug 的时候，偶有崩溃现象，但并不是太频繁，但是自从换用 Apache2.2 以后，Apache 崩溃的频率大幅增加，换用了不同的 PHP 和 xdebug 的版本都是一样，不停的崩溃，正常的开发根本无法保证。
后来无意中发现是 php5apache2_2.dll 的问题，因为我一直使用 module 模式安装 PHP5，所以不管 PHP5 和 xdebug 换到什么版本，都没有意义，昨天将 php5 换到 CGI 模式后，配合 xdebug 一直使用到现在，Apache2 再也没有崩溃过。