GFW 开始识别 WEB 代理 3 条评论

之前提到用 HTTP 中转的办法解决了评论的问题，今天发现 Blog 上所有的评论又失效了…… 开始以为是因为页面直接引用了 www.blogger.com 域名的某些内容而导致撞墙，但仔细分析后发现，我的 HTTP 中转直接不能访问了，而且之后我的 HTTP 中转程序所在的域名也会在一小段时间内无法访问…… 但同时，用该中转能够访问原本没有被封的内容，比如 Flickr……

考虑到传入的目标 URL 参数是用 Base64 和 URL Encode 方式处理的，不存在任何加密，而且这和大多数的　WEB 代理相同，所以推测是现在 GFW 能够识别用 Base64 编码的内容，如果该内容刚好是被屏蔽的网址，则阻拦该 HTTP 请求，并且屏蔽该请求所在的域…… 从而让公众无法通过 WEB 代理访问屏蔽内容。

当然，解决的办法也简单，如果不能简单通过 Base64 decode 得到一个 URL，那么它也就无从判断是不是被屏蔽的网址了……

我起先想直接把原网址按位取反再 Base64 就行了，结果同事说我作为一个 IT 人士这么干太低级了…… 他们说用 RSA 吧，但是也犯不着这么兴师动众吧……

还是 Liuming 小弟比较聪明，提供了一个比按位取反高级，又比 RSA 简单的办法，那就是……

两次 Base64…… >.<"e;

评论功能修复 2 条评论

刚刚发现 Blog 的评论功能不能用了，提交后一直显示等待。查了一下，发现是 GFW 的问题。

自 5 月 16 日，Blogger 及托管站 BlogSpot 再次被封，导致域名 blogger.com 以及 blogspot.com 全部无法访问。而我的评论系统，是靠通过 Blogger 的 Feed 地址，由 AJAX 和 Blogger 之间通讯实现读取；由 AJAX 直接向 Blogger 的评论表单处理 URL 发送 POST 请求实现提交。这两项功能都是基于 www.blogger.com 域名的。前者所用的 Feed 地址由于先前早已被封，并通过朋友在 DreamHost 的主机上放了一个 PHP 的中转程序，所以评论列表功能一直可以用，但是评论提交是直接 POST 的，www.blogger.com 被封，所以评论自然就失败了。

没办法，刚刚改进了一下我的 HTTP 中转程序，实现了 POST 的功能，现在评论功能已经修复了。只是整个数据流程要经历“本地网页 » blog.windia.net » DreamHost » www.blogger.com » DreamHost » blog.windia.net » 本地”这样漫长的路径，因此提交评论可能需要数十秒的时间，但聊胜于无吧。希望 GFW 早日放过 Blogger，这样功能就能完全恢复正常了。

另外，修改了一下模板，把 blogger.com 上引用的 CSS 以及 JS 文件的地址都改由 DreamHost 上的 HTTP 中转读取，这样在打开 Blog 页面时，浏览器不用再等待这些文件的 HTTP 请求超时，速度应该能快不少。

SAMSUNG 手机安装 MIDlet 出现“内容不匹配” 0 条评论

昨天通过 OTA 方式从 Apache 服务器上在一部 SAMSUNG SGH-L760 上安装 MIDlet，下载完 JAD 确认安装，开始下载 JAR 之前，手机报错说“内容不匹配 (Content mismatch)”。同样的 JAD 和 JAR 在另外一个主机上就能成功下载安装，而且这一组 JAD 和 JAR 在同服务器上另外一个 HTTP 服务应用上也能成功安装，一时觉得纳闷。

开始怀疑是端口问题，因为出现安装错误的 Apache 服务器是运行在 82 端口上的。但是同样是从这个 Apache 服务，另外一部 SonyEricsson K610i 就能正常下载安装，而且如果是端口问题，没道理 JAD 能下载而 JAR 不能。

然后开始怀疑是 JAR 文件的 Content-Type 问题，因为在确认安装的界面上，有显示应用类型是 application/vnd.sun.j2me.java-archive。打开 Apache 的配置文件 /etc/httpd/conf/httpd.conf，发现没有定义 .jad 和 .jar 文件的语句，于是添加如下两行：

AddType text/vnd.sun.j2me.app-descriptor .jad
AddType application/vnd.sun.j2me.java-archive .jar

然后重启 Apache 服务，问题解决。MIDlet 成功在 SAMSUNG SGH-L760 上安装了。

你博客的 ping 列表真的全在工作吗？ 4 条评论

我们知道在博客发表文章时，可以利用 XML-RPC 技术将更新通知到各种 Blog 的服务商、搜索引擎等，好让它们主动来抓取，从而提高博客文章被收录的速度和范围。

Google 的 Blogger 不像 WordPress，后者提供了一个方便的 Update Service，只要将 Blog 服务商公布的 XML-RPC 接口地址填进去就可以方便的在发布的时候 ping 这些地址。Blogger 只是在 Settings » Basic 有一个“Add your blog to our listings?”的选项，解释说选择了“Yes”，Google Blog Search 以及 Weblogs.com 就会来收录，除此之外并没有一个可以设置 ping 接口地址列表的地方。

我强烈怀疑 Blogger 这个选项的作用，因为曾经有很长一段时间 Google Blog Search 都没有收录我的文章，后来为了确保收录效果，每次发布文章后我都手工 ping，于是通常 5 分钟内文章就会被收录，而 10 分钟左右，Google 的网页搜索也会收录这篇文章（观察到的最快纪录为 8 分钟）。但是每次都要手工去 ping 确实很麻烦，于是今天就琢磨着自己用 PHP 写一个简单的 XML-RPC 客户端来做这个工作，顺便还可以把其它主流的 ping 服务地址加进去，批量执行。

结果是不试不要紧，一试吓一跳。我参考 Weblogs.com 和 Google Blog Search 提供的标准 ping 操作 API 文档写了一个 XML-RPC 的客户端，测试了一下主流的 ping 服务地址列表，发现其中有很大一部分都不能正常工作。

http://blogsearch.google.com/ping/RPC2
http://rpc.pingomatic.com/
http://api.my.yahoo.com/RPC2
http://api.moreover.com/RPC2
http://rpc.newsgator.com/
http://rpc.weblogs.com/RPC2
http://www.feedsky.com/api/RPC2
http://ping.feedburner.com/
http://rpc.technorati.com/rpc/ping
http://ping.blog.qikoo.com/rpc2.php
http://blog.iask.com/RPC2
http://www.xianguo.com/xmlrpc/ping.php
http://www.zhuaxia.com/rpc/server.php

以下就来一一看一下 ping 这些地址得到的具体结果。

以上这些地址中，能够完全按照标准 API 正常工作的有：

http://blogsearch.google.com/ping/RPC2
http://api.my.yahoo.com/RPC2
http://api.moreover.com/RPC2
http://rpc.weblogs.com/RPC2
http://rpc.technorati.com/rpc/ping

以下是其它有问题的 ping 接口的具体情况。

http://rpc.pingomatic.com/

这是一个十分有名，被博客界所有人争相 ping 之的地址，但是，真的有人见过它返回正确的结果吗？我试了很多次，无论是请求 weblogUpdates.extendedPing 方法，还是weblogUpdates.ping 方法，无论是提供两个参数还是三个、四个参数，它返回的 HTTP 头永远只会是“501 Not Implemented”，正文部分没有任何内容。我另外还试了 http://rpc.pingomatic.com/RPC2 和 http://pingomatic.com/ 两个地址，得到的结果一样。

http://rpc.newsgator.com/

这个地址存在大家的列表中，我感到非常诧异，因为这个域名都已经不存在了，我换了很多个 DNS 服务器都不能解析出它的 IP 地址。后来发现了 NewsGator 的另一个 ping 接口：

http://services.newsgator.com/ngws/xmlrpcping.aspx

经过测试，这个是可以正常工作的。

http://ping.feedburner.com/

起先 FeedBurner 的接口很长时间都不返回，纳闷了很久；细查之下，发现 ping.feedburner.com 这个域名做成了 feeds.feedburner.com 的 CNAME 纪录，而众所周知后者已经被墙，所以实际上这个 ping 接口是没有办法直接通知到的，除非发起 ping 动作的客户端在国外运行。

http://www.feedsky.com/api/RPC2

Feedsky 趁着 FeedBurner 被封在国内很是火了一把，可是做事情的态度和质量还是和人家有差距。首先是没有实现 weblogUpdates.extendedPing 方法，而在请求 weblogUpdates.ping 方法时，返回的结果也很不稳定。有时是正常的结果，有时会以错误码 304 将整个 Feed 的内容放在 message 字段中返回，有时又干脆什么都不返回。

http://ping.blog.qikoo.com/rpc2.php

这个似乎是奇虎官方给出的地址，而几乎网上搜到的所有 ping 列表中都有它。奇怪的是，这个地址根本打不开，HTTP 状态码为 404。我曾经猜测是不是大家在传抄过程中不小心弄错了大小写，于是也试了 RPC2.php, RPC.php, rpc.php，结果都是 404。

http://blog.iask.com/RPC2

新浪这个表面看起来很不错，相应速度很快，返回的 XML 格式也很标准。可是无论怎么提交，返回结果都是 flerror: 1; message: sorry,failing。以至于让我怀疑，这个接口背后的后台程序真的有在运作吗？

http://www.xianguo.com/xmlrpc/ping.php

发出请求大约 5 秒钟后，返回如下内容：

Fatal error: Call to undefined function xmlrpc_server_create() in /opt/lamp/code/common/rssreader-common-2008-11-12-14-31-18/topgene/feed/xmlrpc/server.php on line 15

怎么？PHP 的扩展库都还没配置好就当公共运营的服务器了？而且还直接把错误信息输出到页面上，服务器路径信息一览无余。鲜果啊鲜果，让我说你什么好哇！

http://www.zhuaxia.com/rpc/server.php

抓虾比鲜果好点，至少还返回了，只不过不知道返回的是啥。返回结果如下：

<?xml version="1.0" encoding="utf-8"?>
<methodResponse>
<params>
 <param>
  <value>
   <boolean>0</boolean>
  </value>
 </param>
</params>
</methodResponse>

如果说你看不懂 Weblogs.com 的英文文档倒也情有可原，但是照着 Google 的中文文档依葫芦画瓢总会吧？自己想当然的随便弄一下就完事了？

由以上可以看出，大公司终究还是大公司。令人深思的是，这些不能正常工作的接口中，几乎全是国内的服务商，其中有些暴露出来的问题，更是令人汗颜。

测试手机的 User-Agent 2 条评论

由于最近工作中需要得到一些手机的 User-Agent 以及 X-Wap-Profile 两个 HTTP 头的值，于是写了个简单的 PHP 程序，检测 HTTP 头，输出到 Response，然后放到网站上，让手机用 WAP 浏览器打开查看。

开始这个程序只是简单的输出纯文本，结果是 NOKIA、Sony Ericsson 以及 Samsung 手机都能正确读出，而 Motorola 却不行（实际测试过程中用的是 Motorola RAZR V3i），仅显示白页。

后来把程序改成输出标准 WML 页面，HTTP 头的 Content-Type 设置成 application/vnd.wap.xhtml+xml，NOKIA、Sony Ericsson 以及 Samsung 仍然能够正确显示而 Motorola 还是不合作。

最后找到答案，Content-Type 要设置成“text/vnd.wap.wml”，这下 Motorola 终于老实了…… 可是结果中只有 User-Agent，没有 X-Wap-Profile。

另外，在用中国移动的 SIM 卡测试的时候，发现 HTTP 请求中并没有 User-Agent 和 X-Wap-Profile 这两个头，而有个奇怪的

VIA: HTTP/1.1 SCCD-PS-WAP-GW02 (infoX-WISG, Huawei Technologies)

开始以为是手机的问题，但看到“Huawei”字样，觉得很蹊跷，后来换成 Orange France 的 SIM 卡，则一切正常了。

看来拦截 HTTP 请求是中国运营商的“优良传统”啊！

Update 2009/08/03:

最近发现中国移动这个问题只存在于 cmwap，用 cmnet 则正常。