Snooda

    今天博客新迁移，由于对静态化url的改动非常大，难免有遗漏的地方，所以非常关注access日志，看看爬虫们遇到了哪些困扰。

    在看日志的时候发现一个有意思的现象，google和百度的蜘蛛今天很不活跃，对于站点的大规模改变似乎并不感兴趣，对css，js不屑一顾，而soso的spider非常活跃，把每个链接都详细爬了一遍，但发现一个问题：

     新博客的url是采用base设置+相对url的模式，soso的spider似乎并不识别base标签，直接把相对url附加到当前url之后进行抓取，导致了很多404请求。查了一下，base属性是html标准属性，soso不支持这个属性应该算是个bug了。

    今天测试lighttpd是否支持delete请求，发现webdav模块可以实现此功能。不过发现http返回码是204，查了一下，原来此状态码的意思是说请求成功了，但是没有结果返回来。搜到鸟哥一篇文章，讲的很不错，转载一下：


http://www.laruence.com/2011/01/20/1844.html

之前和人讨论过这个问题,,, 今天感冒在家休息, 就回忆了一下, 整理如下.

我们很多的应用在使用Ajax的时候, 大多数情况都是询问型操作, 比如提交数据, 则Ajax只是期待服务器返回:

{status: 0, message:""} //status 0代表成功, 非零的时候, message中包含出错信息.
我们知道HTTP的状态码, 2xx都是表示成功, 而HTTP的204(No Content)响应, 就表示执行成功, 但是没有数据, 浏览器不用刷新页面.也不用导向新的页面.

在HTTP RFC 2616中关于204的描述如下:



类似的还有205 Reset Content, 表示执行成功, 重置页面(Form表单).



于是, 当有一些服务, 只是返回成功与否的时候, 可以尝试使用HTTP的状态码来作为返回信息, 而省掉多余的数据传输, 比如REST中的DELETE和如上所述的查询式Ajax请求.

最后说说205, 205的意思是在接受了浏览器POST请求以后处理成功以后, 告诉浏览器, 执行成功了, 请清空用户填写的Form表单, 方便用户再次填写,

总的来说, 204适合多次对一个Item进行更新, 而205则适合多次提交一个系列的Item.

但, 请注意, 目前还没有一个浏览器支持205, 大部分的浏览器, 都会把205当做204或者200同样对待.

    最近几天监控频频爆出dns无法解析问题，群里关注了下，发现godaddy的dns服务器现在开始被和谐了，于是决定换一个。dnspod国人用的比较多，不过在国内总感觉比较扯。还是用he的比较可靠一点。

    修改很快，将解析记录都导入he的管理页面后去godaddy切换ns记录，本地nslookup了一下，切换了。

    在此期间注意到godaddy有了DNSSec记录功能，看了下，应该是防止dns欺骗的，暂时用不到，没有搞。

    经历了很长时间的准备后，终于把blog迁移了。哈哈，庆祝一下。

    考虑了很长时间，最后还是决定还在老服务器上开博客，先不动地方，因为新服务器最近网络变得非常差，失去了信心，而老服务器基本稳定，还能接受，稳妥起见，并且为了避免给搜索引擎带来太大的困扰，所以没有换服务器。


    迁移前先升级了下php，之前php还是5.1，实在太老了，加入了centos-test源，yum update提示我几个php依赖错误，卸掉那几个包后重新安装，好了，还有几个包源里没有，比如filter，查了下，原来从5.2起整合进php了，自然也不需要了。还有eaccelerate似乎也找不到，下了源码编译。然后把自己写的模块重新编译一遍，一切正常，restart php。哈哈，升级了。

    之前已经修改、测试好了博客，一些配置也配置好了，所以迁移显得非常简单，直接从代码库中拉出代码到指定位置，代码就部署完成。使用昨天编写的数据导入脚本，把数据导入（期间出了个小插曲，php会对同样连接条件的连接请求进行复用，导致数据库use错乱，后来一个用localhost一个用127.0.0.1才好了，这个是始料未及的，因为之前是在两台机器间迁移的）。然后根据之前写的rewrite规则修改nginx配置文件，重启~ok了。

    心情不错，写博客又有动力了。