不知怎么搞的,系统的邮件发送系统突然失效

今天,我玩意中发现系统的邮件发送系统失效了。也就是说别人订阅了的邮件收不到。

我怀疑是申请的免费的邮箱对这种利用他们的邮箱发邮件有了限制。但是不确定。明天把学习日记自己的邮箱重新启用作邮件发送邮箱试试。

原来,因为学习日记发的邮件常被别的邮件系统当成垃圾邮件(不被其它大的邮件系统信任吧?),所以改用tom.com的邮箱。可是今天不管是tom.com和126.com的邮箱均不能完全的正常工作了。现在想起来,应该用自己的邮箱,就算是被识别为垃圾邮件,也是自己的东西。而且,如果真的有朋友愿意订阅我们的邮件,只要把我们的发送邮箱加入他们邮箱的白名单就行了吧。

*************************************************

补充,这时(距上面的发文半小时后),我才发现可能是tom.com的免费邮箱接收邮件系统出了故障,不能及时收取信件了。因为我把接收学习日记的邮箱改为另一个邮箱后就收到了。而且,我们这个系统的测试帐号的那个邮箱也能收到。明天再看看那些邮件会不会来。

javax.servlet.UnavailableException

今天,我改了几个类文件上传到虚拟空间,应用自动重启不能成功。在log中报告:


2006-12-07 21:25:37,578 - Initializing application data source dataSource

org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (User xyz has already more than 'max_user_connections' active connections)

at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:855)

at org.apache.commons.dbcp.BasicDataSource.setLogWriter(BasicDataSource.java:598)

at org.apache.struts.action.ActionServlet.initModuleDataSources(ActionServlet.java:808)

at org.apache.struts.action.ActionServlet.init(ActionServlet.java:335)

at javax.servlet.GenericServlet.init(GenericServlet.java:82)

at com.caucho.server.http.Application.createServlet(Application.java:3114)

at com.caucho.server.http.Application.loadServlet(Application.java:3065)

at com.caucho.server.http.Application.initServlets(Application.java:1923)

at com.caucho.server.http.Application.init(Application.java:1849)

at com.caucho.server.http.VirtualHost.startApplication(VirtualHost.java:1207)

at com.caucho.server.http.VirtualHost.getInvocation(VirtualHost.java:1007)

at com.caucho.server.http.ServletServer.getInvocation(ServletServer.java:1249)

at com.caucho.server.http.RunnerRequest.handleRequest(RunnerRequest.java:343)

at com.caucho.server.http.RunnerRequest.handleConnection(RunnerRequest.java:274)

at com.caucho.server.TcpConnection.run(TcpConnection.java:139)

at java.lang.Thread.run(Thread.java:595)

Caused by: java.sql.SQLException: User xyz has already more than 'max_user_connections' active connections

at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2928)

at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:771)

at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1229)

at com.mysql.jdbc.Connection.createNewIO(Connection.java:2558)

at com.mysql.jdbc.Connection.<init>(Connection.java:1485)

at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:266)

at org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:37)

at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)

at org.apache.commons.dbcp.BasicDataSource.validateConnectionFactory(BasicDataSource.java:877)

at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:851)

... 15 more

2006-12-07 21:25:37,593 - connect fail in CallHtml.callOnePage()!

2006-12-07 21:25:37,593 - excute manager.deleteExpiredRecords() 1 times.

于是,我连接mysql查看当前活动连接数(show porcesslist;)确实达到了空间的最大活动连接数。

然后,只要一进入*.do形式的链接均在页面上报告上面相似的错误。也不知道是我上传的类文件是否触犯了Struts框架哪根神经?

上网用出现错误的关键字查了一下,其中有一篇http://mail-archives.apache.org/mod_mbox/struts-dev/200312.mbox/%3C20031204011632.14053.qmail@nagoya.betaversion.org%3E 上面的话:“Struts missing commons-dbcp and commons-pooling jar files.”启发了我。于是,我把lib中的那个:commons-pool-1.3.jar移走了。然后,我再输入*.do的链接,错误信息变了,为:


2006-12-07 22:11:07,765 - Unable to initialize Struts ActionServlet due to an unexpected exception or error thrown, so marking the servlet as unavailable.  Most likely, this is due to an incorrect or missing library dependency.

java.lang.NoClassDefFoundError: org/apache/commons/pool/impl/GenericObjectPool

at java.lang.Class.getDeclaredConstructors0(Native Method)

at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)

at java.lang.Class.getConstructor0(Class.java:2640)

at java.lang.Class.newInstance0(Class.java:321)

at java.lang.Class.newInstance(Class.java:303)

at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:143)

at org.apache.struts.action.ActionServlet.initModuleDataSources(ActionServlet.java:805)

at org.apache.struts.action.ActionServlet.init(ActionServlet.java:335)

at javax.servlet.GenericServlet.init(GenericServlet.java:82)

at com.caucho.server.http.Application.createServlet(Application.java:3114)

at com.caucho.server.http.Application.loadServlet(Application.java:3065)

at com.caucho.server.http.Application.initServlets(Application.java:1923)

at com.caucho.server.http.Application.init(Application.java:1849)

at com.caucho.server.http.VirtualHost.startApplication(VirtualHost.java:1207)

at com.caucho.server.http.VirtualHost.cron(VirtualHost.java:1359)

at com.caucho.server.http.ServletServer.cron(ServletServer.java:1940)

at com.caucho.server.http.ServletServer.handleCron(ServletServer.java:1774)

at com.caucho.util.Cron$CronThread.evaluateCron(Cron.java:199)

at com.caucho.util.Cron$CronThread.run(Cron.java:163)

2006-12-07 22:11:07,812 - connect fail in CallHtml.callOnePage()!

2006-12-07 22:11:07,812 - excute manager.deleteExpiredRecords() 1 times.

看来,应用已经有反应了(先前是没有任何反应,改变类文件也没反应,log信息一点不变。我又不能手动重启位于虚拟主机上应用,因为他们还暂时不提供这个功能),于是,我再把那个commons-pool-1.3.jar加进去。然后,系统成功自动重启,log信息如下:


2006-12-07 22:12:16,187 - Enter updateCache!

2006-12-07 22:12:21,609 - connect success in CallHtml.callOnePage()!

2006-12-07 22:12:21,609 - excute manager.deleteExpiredRecords() 1 times.

我也不知道是什么原因,就这样糊里糊涂的出问题,又糊里糊涂的解决了问题:)

也许,我中了seo的毒了?

从理论上讲,www.javaeye.com的静态文件列表对搜索引擎来说有内容复制之嫌疑。

如:这篇帖子:confluence不支持群集,是因为hibernate吗?

在静态文件列表中是:http://www.javaeye.com/t/20169.html

而在动态文件列表中是:http://www.javaeye.com/topic/20169

也就是说,相同的内容在他们页面有两个版本,一个动态的,一个静态的。

我不知道这对它们在搜索引擎中的收录有什么影响?

也许,我现在考虑搜索引擎考虑得太多了。

像这两天又想在虚拟主机提供商端实现彻底的301重定向,但是到现在为止也还没有成功。

做网站,或者更坦白的说,学习知识的我不应该在为迁就搜索引擎而折磨自己了。

还有,我发现一个著名的linux个人站linux.vbird.org,他有两个域名:http://linux.vbird.orghttp://www.vbird.org,进入都是同样的返回200 ok状态码;还有他的文章如: DNS 伺服器設定 两个域名都返回的是200码

http://www.vbird.org/linux_server/0350dns.php

http://linux.vbird.org/linux_server/0350dns.php

也就是说,也有内容复制之嫌。

但是以“DNS 伺服器設定”为关键字检索site:linux.vbird.org有结果,而site:www.vbird.org却没有这篇文章的影子,只有这篇文章的老版本:http://www.vbird.org/linux_server/0350dns/0350dns.php存在,而且,这篇老文章被标记成了补充材料。

另外,另一篇文章(Enterprise Linux 实战讲座前言DNS 反解( Reverse Lookup )原理)的pdf文件:

http://linux.vbird.org/somepaper/20050630-dns-1.pdf分在了linux.vbird.org,

而同样文章的第二部分却分在了:www.vbird.org/somepaper/20050630-dns-2.pdf

但是他还不是照样很红火?

我想,是google根据判断把本来是一个站的内容分在了两个域名下。

说明这还是有问题的,我上vbird.org问一下站长vbird的想法如何?

也许,正如:SEO每日一帖的zac说的那样,我中了SEO的毒了?

如何分离个人信息,缓存动态页面(转帖)

下面是一个用于php中的静态缓存加入动态个人信息的方案,我觉得他的思路是可以借鉴的,就转帖在这里了。

正文

****************************************************************************

转自:(http://nio.infor96.com/archives/283

如何分离个人信息,缓存动态页面

肖理达 (KrazyNio AT hotmail.com), 2005.06.07, 转载请注明出处

一直想写一篇关于动态页面 cache 的文章,但每次?提笔?却又放弃,因为总是觉得准备得

还不够充分。今天埋头写下,只是希望对自己的工作做一些笔录。

1、问题起源

我们经常会在一个动态页面中加入很多个人信息,以 CMS 首页为例,用户登录之前显示登

录框,登录之后显示其用户名,并根据权限显示其可用模块的链接。由于每个用户登录之

后,显示出来的动态信息都是不一样的,所以这部分无法进行 cache,我们将这部分信息

定义为?个人信息?,它的特性是根据登录用户进行动态改变。

现在问题来了,就是一个 CMS 的首页,访问者的登录概率并不是百分百的,应该说有一大

部分人访问首页是没有登录的,这个时候的首页是一个公共的页面,没有任何个人信息,

或者说这时候首页的任何动态信息都是可以转换成静态的,也就是说这部分是可 cache 的

2、使用 JavaScript 分离个人信息

解决这个问题的方法有很多种,一种是将个人信息和其他信息进行分离,如在 CMS 首页中

加入一个外部的 JavaScript 文件,而这个文件的内容实际上是由 PHP 动态生成的。CMS

首页 index.php 代码片段:

<script language="JavaScript" src="/js/personal.php"></script>

?.

<script language=?JavaScript?>

document.write(sUser);

document.write(sLinks);

</script>

personal.php 代码片段:

<?php

session_start();

header(?Cache-Control: no-store, no-cache, must-revalidate?);

?>

sUser = ?<?php echo $_SESSION['USER']; ?>?;

sLinks = ?<?php echo addslashes($_SESSION['LINKS']); ?>?;

这种方法比较适合个人信息较少,易于集中显示的情况。通过 JavaScript 外挂代码实现

个人信息分离之后,personal.php 是永不 cache 的,这样也就可以放心地对 CMS 首页进

行 cache 了,具体的 cache 方法可采用 304 HTTP 头与 Cache_Lite 相结合的方式,这

在后边有详细代码示例。

3、选择性分离个人信息

一旦个人信息较多,很难对其进行分离的时候,上述方法实现起来就会比较麻烦了。接下

来介绍一种比较放宽的 cache 方式,就是只对用户未登录的 CMS 首页进行 cache,一旦

发现用户处于登录状态,则跳过 cache 部分,直接运行相关代码,我把这种方法称为?

选择性 cache
?。这种方法中,我们牺牲了一部分可 cache 的情况,但很大程度上提

高了个人信息的可扩充性,也就是说个人信息的多少、显示的位置等等都不再受到限制,

这是值得的,毕竟修改服务端代码要比修改大量的 JavaScript 代码要来得方便,而且

JavaScript 的调试也会比较麻烦。

分析一下这种 cache 方式,概要流程图如下:

image

代码片段如下:

<?php

session_cache_limiter(?must-revalidate?);

session_start();

if (empty($_SESSION['USER'])) { //未登录时才使用 cache

    ?.    //输出 cache

} else {

    //  直接输出页面内容,此条件下与未使用 cache 时一样

    $data =& get_data();

    echo $data;

}   //end if

?>

这里需要说明的一点是,由于 PHP 在使用 SESSION 时,php.ini 中默认设置的

session.cache_limiter 为 nocache,所以需要修改 cache_limiter,设置成

must-revalidate,使得客户端再次浏览当前页时必须发送相关 HTTP 头信息到服务器进行

验证,然后才决定是否加载客户端本地 cache。不要把客户端本地 cache 与服务器端

cache 搞混,之后的代码片段中会充分利用客户端 cache 和服务器端 cache 机制达到缓

存的目的。关于 must-revalidate,请参考 HTTP 规格说明书 RFC 2612 的 14.9.4 章节

上边的代码并不完整,接下来是更加深入的探讨客户端 cache 机制了,利用客户端 cache

,可以有效地减轻服务器端负载。首先了解一下 HTTP 头:Last-Modified 与

If-Modified-Since。简单的说,Last-Modified 与If-Modified-Since 都是用于记录页面

最后修改时间的 HTTP 头信息,只是 Last-Modified 是由服务器往客户端发送的 HTTP 头

,而 If-Modified-Since 则是由客户端往服务器发送的头,其工作原理图如下:

image

可以看到,再次请求本地存在的 cache 页面时,客户端会通过 If-Modified-Since 头将

先前服务器端发过来的 Last-Modified 最后修改时间戳发送回去,这是为了让服务器端进

行验证,通过这个时间戳判断客户端的页面是否是最新的,如果不是最新的,则返回新的

内容,如果是最新的,则返回 304 告诉客户端其本地 cache 的页面是最新的,于是客户

端就可以直接从本地加载页面了,这样在网络上传输的数据就会大大减少,同时也减轻了

服务器的负担。想要详细查看 HTTP 头信息,可以在 Firefox 中安装 LiveHTTPHeaders

插件,安装完成之后按 Alt+L 就可以在 Sidebar 中看到了。

现在再来完善之前的 index.php 代码:

<?php

session_cache_limiter(?must-revalidate?);

session_start();

function &get_data()

{

    //此函数用于获取本页面的输出内容

    //?.

}   //end function

if (empty($_SESSION['USER'])) { //未登录时才使用 cache

    //====================================================

    //  1. 检查 HTTP 头是否符合 304 的条件

    //====================================================

    //get_last_modified() 函数需要另外单独实现,此函数用于获取服务器端 cache 文件的最后修改时间,可将时间戳保存在数据库中。

    $last_modified = get_last_modified();

    $headers = getallheaders();

    if (strtotime($headers['If-Modified-Since']) == $last_modified) {

        //  返回 304 并结束程序运行

        header('HTTP/1.1 304 Not Modified');

        exit;

    }   //end if

    header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $last_modified) . ' GMT');

    //====================================================

    //  2. 检查 cache 文件是否存在

    //====================================================

    require_once 'Cache/Lite.php';

    //  参数设置

    $options = array(

        'cacheDir' => './cache/',

        'lifeTime' => 86400, //最大 cache 一天时间

        'fileNameProtection'   => false //使用 CMS 自身提供的 id 作为名字

    );

    $cache = new Cache_Lite($options);  //创建 Cache_Lite 对象

    $id = md5($_SERVER['REQUEST_URI']); //生成对应于 cache 文件的 ID

    if ($data = $cache->get($id)) {   //存在 cache 文件,获取内容,直接输出

        echo $data;

    } else {

        $data =& get_data();

        echo $data;

        flush();

        $cache->save($data);    //保存 cache

    }   //end if

} else {

    $data =& get_data();

    echo $data;

}   //end if

?>

测试时可以使用 LivHTTPHeaders 插件,你将会看到第一次访问时是返回 200,第二次到

第N次访问时则返回了 304,而登录之后,则一直都返回 200,因为我们选择性 cache 之

后,对登录之后一律运行程序输出,而不使用 cache,如果之后需要对输出的个人信息进

行修改,只需要改函数 get_data() 即可,也避免了 JavaScript 的调试。

总结

除此之外,还有其它方法可以实现分离个人信息,缓存动态页面的目的。而且为了提高服

务器运行效率,还可以使用数据库 cache、Squid 反向代理等,如 ADOdb 的 cache。目前

用的比较多的 Drupal 应用的就是本文中提到的第二种方法。

参考资料

HTTP Caching & Cache-Busting for Content Publishers

Hypertext Transfer Protocol ? HTTP/1.1

PHP Anthology, Volume 2: Applications. Chapter 5: Caching

Caching Tutorial for Web Authors and Webmasters

Drupal 源代码

Comments RSS | Trackback URL

4 Comments on ?关于 Cache(4)?

By zeal. June 13th, 2005 at 3:25 pm

我们目前采用的是oracle cache server以及squid。对于不能cache的内容采取分目录存放

。在代码设计的时候就考虑可cache性。对于大量需要用户交互的内容,似乎cache的作用

不大。

By Nio. June 13th, 2005 at 5:02 pm

嗯,如果内容本身全都是个人信息的话或者必须登录才能浏览的页面,就用不到这种cache

方法了,需要看登录与不登录的概率比而定 🙂

By nc. July 17th, 2006 at 12:43 pm

感谢你文章的提示,非常不错.

By ahu. October 8th, 2006 at 5:10 pm

zeal的公司貌似有些money~

**************************************************************************

                                                           转载完毕

另一段静态页面计数代码:


<script language="javascript" src="/data/include/count.php?id=$id"></

script>

转摘自:(http://www.mephp.com/view.php?tid=1&id=44

301永久性重定向和302临时性重定向的研究(转帖)

转自:301永久性重定向和302临时性重定向的研究

301永久性重定向 和 302临时性重定向 的研究

作者:快速胡萝卜 日期:2006-08-09

字体大小: 小 中 大

先简要说一下

重定向就是网页自动转向

301永久性重定向

302临时性重定向

实施301后,新网址完全继承旧网址,旧网址的排名等完全清零。

实施302后,对旧网址没有影响,但新网址不会有排名。

详情见下文。

301 Redirect 永久重定向的实现

  在我们的网站建设中,时常会遇到需要网页重定向的情况:象网站调整,如改变网页目录结构,网页被移到一个新地址,再或者,网页扩展名改变,如因应用需要把.php改成.Html或.shtml,在这种情况下,如果不做重定向,则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户还会得到一个404页面错误信息,访问流量白白丧失;再如某些注册了多个域名的网站,也需要通过重定向让访问这些域名的用户自动跳转到主站点,等等。

  常用的重定向方式有: 301 redirect, 302 redirect 与 meta fresh:

  301 redirect: 301代表永久性转移(Permanently Moved),301重定向是网页更改地址后对搜索引擎友好的最好方法,只要不是暂时搬移的情况,都建议使用301来做转址。

  302 redirect: 302代表暂时性转移(Temporarily Moved ),在前些年,不少Black Hat SEO曾广泛应用这项技术作弊,目前,各大主要搜索引擎均加强了打击力度,象Google前些年对Business.com以及近来对BMW德国网站的惩罚。即使网站客观上不是spam,也很容易被搜寻引擎容易误判为spam而遭到惩罚。

  meta fresh: 这在2000年前比较流行,不过现在已很少见。其具体是通过网页中的meta指令,在特定时间后重定向到新的网页,如果延迟的时间太短(约5秒之內),会被判断为spam。

    页面永久性移走(301重定向)是一种非常重要的“自动转向”技术。

  301重定向可促进搜索引擎优化效果

  从搜索引擎优化角度出发,301重定向是网址重定向最为可行的一种办法。当网站的域名发生变更后,搜索引擎只对新网址进行索引,同时又会把旧地址下原有的外部链接如数转移到新地址下,从而不会让网站的排名因为网址变更而收到丝毫影响。同样,在使用301永久性重定向命令让多个域名指向网站主域时,亦不会对网站的排名产生任何负面影响。

  302重定向可影响搜索引擎优化效果

  迄今为止,能够对302重定向具备优异处理能力的只有Google。也就是说,在网站使用302重定向命令将其它域名指向主域时,只有Google会把其它域名的链接成绩计入主域,而其它搜索引擎只会把链接成绩向多个域名分摊,从而削弱主站的链接总量。既然作为网站排名关键因素之一的外链数量受到了影响,网站排名降低也是很自然的事情了。

  综上所述,在众多重定向技术中,301永久性重定向是最为安全的一种途径,也是极为理想的一款解决方案。

  对于正确实施301重定向,本人整理了以下方法可供大家参考:

  1. Apache服务器实现301重定向

  a. 相比较来说,Apache实现起来要比IIS简单多了。在Apache中,有个很重要的文件.htaccess,通过对它的设置,可以实现很多强大的功能,301重定向只是其中之一。

  Redirect permanent / http://www.yourdomain.com ;将目录下内容重定向到http://www.yourdomain.com/

  redirect permanent /old.html http://www.yourdomain.com/new-url/ ;将网页old.html内容重定向到http://www.yourdomain.com/new-url/

  通过合理地配置重定向参数中的正则表达式,可以实现更复杂的匹配。有兴趣的朋友可参考Apache手册。

  b. 采用“mod_rewrite”技术。

  通过该技术进行的改变将在.htaccess文件中体现出来,形如:

  Options +FollowSymLinks

  RewriteEngine on

  RewriteCond %{HTTP_HOST} ^yourdomain\.com

  RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [R=301,L]

  2. 适用于使用Unix网络服务器的用户

  通过此指令通知搜索引擎的spider你的站点文件不在此地址下。这是较为常用的办法。

  形如:Redirect 301 / http://www.yourdomain.com/

  3.在服务器软件IIS服务器实现301重定向

  * 打开internet信息服务管理器,在欲重定向的网页或目录上按右键

  * 选中“重定向到URL”

  * 在对话框中输入目标页面的地址

  * 切记,记得选中“资源的永久重定向”

  * 当然,最后要点击“应用”

  适用于使用Window网络服务器的用户

  4.绑定/本地DNS

  如果具有对本地DNS记录进行编辑修改的权限,则只要添加一个记录就可以解决此问题。若无此权限,则可要求网站托管服务商对DNS服务器进行相应设置。

  DNS服务器的设置

  若要将aaa.domain.com指向www.domain.com,则只需在DNS服务中应增加一个别名记录,可写成:aaa IN CNAME www.domain.com。

  如需配置大量的虚拟域名,则可写成::* IN CNAME www.domain.com.

  这样就可将所有未设置的以domain.com结尾的记录全部重定向到www.domain.com上。

  5. 用ASP/PHP/.net实现301重定向:

  ASP:

  Response.Status="301 Moved Permanently"

  Response.AddHeader "Location","http://www.vc01.com/"

  Response.End

  PHP:

  header("HTTP/1.1 301 Moved Permanently");

  header("Location:http://www.vc01.com");

  exit();

  ASP .NET:

  <script runat=”server”>

  private void Page_Load(object sender, System.EventArgs e)

  {

    Response.Status = “301 Moved Permanently”;

    Response.AddHeader(”Location”,”http://www.vc01.com”);

  }

  </script>

  配置完成后,要认真检查一下是否正确。Internet有很多Server Header检查工具

以下为非关键参考:

*************************************************

网站重定向成祸端(从Business.com遭封看302重定向编译:Karen)

  Business.com是网上最大的商业搜索引擎和分类目录,以专业提供商业信息而享负盛名,包括近19万网页。若以“business”为关键词在 Google中进行搜索,该网站名列第一。不过在9月5日,Business.com遇到一件蹊跷之事:它的首页由PR8变成了PR0, 而且 Google搜索结果中找不到首页。好在被“蒸发”的只是首页,不过庆幸的是第二天首页又回到了Google的搜索结果,但PR仍旧为0。

  Business.com的问题出在它的重定向命令上。该网站让business.com跳转到www.business.com,这种重定向本该是永久性的。我们知道,301属于永久性重定向,而302则属于临时性重定向,只有当一个网站或网页在24到48小时之内临时移到其它位置的情况下才能使用该命令。但Business.com却错误地使用了“HTTP/1.1302 Object Moved”状态码。

  其实网站重定向极为普遍,譬如不满意原来的域名而申请了一个新域名;买下容易被人错拼的域名,防止客户因为拼错URL而找不到网站,等等。可是,很多人却会由于使用了错误的重定向状态码而遭“灭站之灾”,就象Business.com。尽管他们的重定向理由充分合理,然而若使用不当,则可能被Google误认为是利用多个域名指向同一网站,那么你的网站就会被封掉,罪名是“利用重复的内容来干扰Google搜索结果的网站排名”。Business.com就是最好的前车之鉴。只不过大多数使用错误重定向参数的网站没Business.com这么幸运,一个小小的重定向就可能使网站前功尽弃,只能从头来过:重新申请新域名,重新发布新网站,等等。记住:Google绝不会同情任何人即使无心犯下的错误。

*************************************************

网站服务器响应网页浏览请求的运作流程

  让我们先来了解一下用户/搜索引擎和网站一开始的交互流程。当用户或搜索引擎向一个网站服务器发出网页浏览请求时,该服务器将:

  1.通过域名服务器(DNS)将域名转换为网站的IP地址,然后返回给客户

  2.打开一个该IP套接口连接

  3.记下通过该套接口的一个HTTP数据流

  4.从WEB服务器接收一个响应请求的HTTP数据流。该数据流包含状态码,状态码的值由HTTP协议所决定。  这里所说的“HTTP数据流”信息也叫“头信息(Header)”。头信息中包括了日期,服务器类型,通常还会有一条“200 OK”信息。如果一切良好,那么网络服务器就会将 “200 OK”信息以及请求页面发送出去。如果网站在这时候已经建立了重定向,那么服务器就会在头信息中包含一个 “302 Moved Temporarily”或“301 Moved Permanent”之类的响应信息。搜索引擎会根据服务器头信息中的内容作出决定。

*************************************************

网站重定向的注意事项

  1.若准备将服务器上的文件移到其它地方时,须就以下信息正确地通知搜索引擎的爬行程序:

- 目标地址:这些文件被移向何方

- 移动属性:暂时移走还是永久性移走

  2.对拥有多个域名的网站,专家建议应把那些不想在搜索引擎上推广的域名用301跳转命令来永久性重定向。

*************************************************

资深SEO专家Dan Thies的看法和建议

  对于Business.com所遭遇的问题Dan Thies深有体会,因为他也有过类似的遭遇。他的网站上有一个会员跟踪脚本,其中一个会员的站点通过302命令映射到这个跟踪脚本,而这个跟踪脚本又是通过302映射到他的主页。当在Google中用“keyword research”进行搜索,他的主页排名在前十位,然而地址显示的却是那个会员的网址。结果使他哭笑不得:访问者通过Google搜索结果进入他的网站,而他却不得不为这些访问量给那个会员支付报酬! 后来他用robots.txt文件禁止Spiders跟踪访问他的会员跟踪脚本才算解决了问题。

  对于Business.com,Dan Thies认为:“目前Google在302重定向"的处理上还存在一定的问题,但并不表示Google不允许302重定向。Business.com并未遭封或遭到惩罚,它们只是返回了错误的响应。”

  Dan Thies建议:如果使用了跟踪URL/脚本,又必须让访问者重定向到某一着陆页,那么一定要在robots.txt文件中禁止Spiders 去访问第二个重定向。如果没有对跟踪URL/脚本进行重定向,而只是把另外一个URL上的内容给复制过来,那么应在robots.txt文件中禁止 Spiders去访问跟踪URL,以防因内容重复而遭搜索引擎惩罚。引自:21cnbj:从Business.com遭封看302重定向

*************************************************

302转向与网址劫持

  302转向或者302重定向(302 redirect)指的是当浏览器要求一个网页的时候,主机所返回的状态码。302状态码的意义是暂时转向到另外一个网址。

  另一个更常见的状态码是404错误(404 error),404错误或404状态码指的是网页不存在。

  另一个和302状态码相关的是301重定向(301 redirect),301重定向指的是本网页永久性的转移到另外一个位置。301和302的区别就在于301是永久性重定向,302是暂时重定向。

  302重定向和网址劫持(URL hijacking)有什么关系呢?这要从搜索引擎如何处理302转向说起。从定义来说,从网址A做一个302重定向到网址B时,主机服务器的隐含意思是网址A随时有可能改主意,重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下,当收到302重定向时,一般只要去抓取目标网址就可以了,也就是说网址B。

  实际上如果搜索引擎在遇到302转向时,百分之百的都抓取目标网址B的话,就不用担心网址URL劫持了。

  问题就在于,有的时候搜索引擎,尤其是Google,并不能总是抓取目标网址。为什么呢?比如说,有的时候A网址很短,但是它做了一个302重定向到B 网址,而B网址是一个很长的乱七八糟的URL网址,甚至还有可能包含一些问号之类的参数。很自然的,A网址更加用户友好,而B网址既难看,又不用户友好。这时Google很有可能会仍然显示网址A。

  由于搜索引擎排名算法只是程序而不是人,在遇到302重定向的时候,并不能像人一样的去准确判定哪一个网址更适当,这就造成了网址URL劫持的可能性。也就是说,一个不道德的人在他自己的网址A做一个302重定向到你的网址B,出于某种原因,  Google搜索结果所显示的仍然是网址A,但是所用的网页内容却是你的网址B上的内容,这种情况就叫做网址URL劫持。你辛辛苦苦所写的内容就这样被别人偷走了。

  302重定向所造成的网址URL劫持现象,已经存在一段时间了。不过到目前为止,似乎也没有什么更好的解决方法。在正在进行的大爸爸数据中心转换中,302重定向问题也是要被解决的目标之一。从一些搜索结果来看,网址劫持现象有所改善,但是并没有完全解决。

  如果你遇到你自己的网站网址被劫持的时候,在你自己这一方面并没有什么办法,你只能向Google汇报。 作者: Zac原载: 搜索引擎优化每天一贴。

*************************************

以上文章为本人整理十多篇文章的成果,多处具体细节本人能力之内无法尝试,各部分原出处也已无法标明,见谅。有问题给我留言,大家一起研究研究。

JAVA学习日记页面静态化方案

JAVA学习日记页面静态化方案(借鉴了:http://www.agilejava.org/space/?233的 生成静态页面技术解决方案系列,见我的转帖:一个实现将JSP动态页面转为静态的方案(转帖)

1、首页和帖子页面静态化,帖子列表不静态化;

2、列表上的帖子用静态化链接;

3、隐私帖子页面不静态化;用户登录后用动态化链接,所以可以看到隐私帖子;

4、静态化时机:

  1)、发公开帖子;

  发公开目标:静态化目标和首页;

  公开日记:静态化日记、目标和首页;

  公开评论:评论日记:静态化日记、目标、首页;评论目标:静态化目标、首页;

  发私人日记:不作任何静态化;

  2)、修改公开帖子;

  修改目标(目标不能修改隐私属性):

  修改公开目标:目标、首页;

  修改私有目标:不作任何静态化;

  修改日记(日记可以修改隐私属性):

  修改公开日记,并且修改后仍是公开帖子:静态化日记、目标、首页;

  修改公开日记,但是修改后的日记是私有帖子:删除已经静态化日记,重新静态化目标、首页;

  修改私有日记,并且修改后仍是私有帖子:不作任何静态化;

  修改私有日记,但是修改后成了公开日记:静态化日记、目标、首页; 

  修改评论(评论的隐私属性与被它评论的目标或日记一致)

  修改公开目标的评论:静态化目标、首页;

  修改公开日记的评论:静态化日记、目标、首页;

  修改私有目标的评论:不作任何静态化;

  修改私有日记的评论:不作任何静态化;

  3)、删除帖子(私有帖子是不能被删除的);

  删除公开目标:删除目标会删除此目标下的评论和日记和日记的评论,所以要:删除已静态化的目标、删除已静态化的目标的日记、重新静态化首页;

  删除公开日记:删除日记会删除此日记下的评论,所以要:删除已经静态化的日记、重新静态化首页;

  删除公开评论:删除目标的公开评论:重新静态化目标、首页;删除日记的公开评论:重新静态化日记、日记的目标、首页;

 

  4)、静态化种类:

  手动静态化:由管理员执行手动全面静态化及维护工作:包括:对数据库和静态化文件储存目标扫描,重新静态化应该静态化的帖子;如果某个不应该静态化的私有目标或日记被静态化了则删除已静态化的文件,并且作下记录,分析原因;

  定时静态化:同手动静态化一样的功能,只不过由系统定时进行,比如每晚12:00点;

  帖子变动时的静态化:如上面的列表;

5、其它注意事项:

  1)、为了统一静态化页面和简要设计和增加系统灵活性,现对登录用户和游客用户(包括搜索引擎)的静态化作一区别:

  登录用户:全部用动态化,也就是说与现在动态化的系统没有区别;从各论坛和网站的统计情况来看:登录用户占全部用户的比例一般在5%左右,所以不会系统有什么大的影响;

  未登录用户(包括搜索引擎):首页和帖子全部用静态化,游客提交评论后通过Action的301跳转进入已静态化的最新页面,但是提交评论的表单已经静态化了,所以不能记住用户,这可以放在以后解决,同屏蔽垃圾留言的设计一起进行,可能会用<frame>内嵌表单来做。

  2)、类的设计:

  1个执行实际静态化的类:ToHtml.java;1个模拟游客访问,调用静态化的工具类:CallHtml.java;再增加一个静态化文件管理类:HtmlsManager.java,用于封装各种静态化时机的操作,包括:

  1>,提交帖子:doPostArt(),传入提交的帖子作为参数,即为doPostArt(ArticleInfo postedArt);

  2>,修改帖子:doEditArt(),传入修改前的帖子和修改后的帖子作为参数,即为:doEditArt(ArticleInfo oldArt, ArticleInfo newArt);

  3>,删除帖子:doDelArt(),传入被删除的帖子作为参数,即为:doDelArt(ArticleInfo);

  4>,检测是否相应静态化文件的方法:isExist(String phyFullName),传入系统路径的包含路径的全文件名作为参数;

  5>,删除一个相应静态化文件的方法:delete(String phyFullName),传入系统路径的包含路径的全文件名作为参数;

添加游客评论功能设计之测试计划

今天,添加游客评论功能设计所计划的功能已经基本实现。

1、实现过程中的改动:

  GuestArtInfo.java用原有的ArticleInfo.java代替;CookieManager.java因为所需要的代码少,另开一个类反而麻烦,功能直接写在了Action中;在util包中添加了一个处理解析存储在帖子正文头部的游客信息的工具类:GuestArtProcessor.java

2、一点心得:

  原来以为struts-config.xml中的“input="/disGoalContentAction.do"”只能用jsp文件,结果证明用*.do的路径也行,而且有时还必须如此。如下面:


        <action

            attribute="guestArtForm"

            input="/disGoalContentAction.do"

            name="guestArtForm"

            path="/postGuestArtAction"

            scope="request"

            type="com.learndiary.website.action.disgoal.PostGuestArtAction">

           

            <!--forward name="goalSuccess" path="/processGoalAction.do" /-->

           

            <!-- forward name="diarySuccess" path="/disall/disgoal/afterPostDiarySelect.jsp" /-->

            <forward name="goalSuccess" path="/toSendMailOfGoalAction.do" />

            <forward name="diarySuccess" path="/toSendMailOfGoalAction.do" />

            <forward name="isBackSubmit" path="/processGoalAction.do" />

            <forward name="isBackSubmit1" path="/disGoalContentAction.do" />

            <forward name="isBackSubmitGoal" path="/processGoalAction.do" />

            <forward name="adviceSuccess" path="/disGoalContentAction.do" />

            <forward name="adviceOfDiarySuccess" path="/disGoalContentAction.do" />

            <forward name="adviceOfGoalSuccess" path="/toSendMailOfGoalAction.do" />

            <forward name="messageSuccess" path="/main.do" />

            <forward name="failure" path="/disall/disgoal/disGoalContent.jsp" />

            <forward name="nonUser" path="/main.do" />

            <forward name="noParentArt" path="/main.do" />

        </action>

自己感觉有必要写个测试列表,进行逐项测试:

1,每项功能经过游客、注册用户、管理员的测试;每项功能在日记的评论和目标的评论中都要经过测试;

2,理想状态功能使用:

填写所有字段,无无效字符串。

3,用户信息为空,或只填用户名、邮件、网址其中一项或多项;

4,帖子内容或标题为空;

5,填写了字段,但是格式错误;

6,测试在其它页面游客发的帖子是否显示正常;

7,测试有游客发帖时的邮件发送内容是否正常;

8,测试有游客发帖时的RSS订阅内容是否正常。

9,传到网上公开测试;

例外:

1,因为软件暂时没有想到解决办法或麻烦,下列项暂时搁置:

1),网址格式过滤;

2),重复提交问题;

添加游客评论功能设计

本来,这个站根本没有朋友来回复(见:停止guest公共帐号,启用公共测试帐号),我又怕麻烦,又想学点东西,近段时间就不打算写网站的程序了。但是,我想,万一有某个朋友有心发表点意见,一看还要注册、登录,结果想在这里留点我认为弥足珍贵的文字也打退堂鼓了。基于“不怕一万,就怕万一”的理论,万一有朋友来访,我们不能拒朋友于门外吧。

1、基本功能:

就是一般博客站的游客回复功能(如http://www.jiehoo.comhttp://www.chinamyhosting.com等),具体为:

1),回复表单在显示帖子内容的下方;

2),字段包括:

名字(必须),邮件(必须),网站(可选),标题(必须,系统自动给出re:....的标题,可以修改),内容(必须);

3),朋友在提交评论后,写入cookie,以后再次访问时不用输入除标题和内容的字段;

2,以上功能在本站实现的要点:

1),回复表单在显示帖子内容的下方:

可以参考上传文件使用的frame结构,为了简化实现,游客回复去掉上传文件功能,但可以使用UBB语法;

2),因为本站已有的数据结构和为了简化实现,所有游客的回复在系统中划为一个游客帐号的帖子;但是,为了显示上述字段,可以把上面的“名字(必须),邮件(必须),网站(可选)”字段加在内容前面,并加入特殊的分隔符,把上述字段连同内容存入数据库;要显示游客的回复的时候,把从数据库中取出的内容字段分离出“名字(必须),邮件(必须),网站(可选)”字段用于显示相关内容。

这样,在取出一篇日记或目标的评论列表,并把它们显示出来的时候,对划归游客帐号的帖子的显示格式有所变化;

3),游客发表的帖子不能被普通用户修改,但管理员可以修改和删除(例如有可能出现的垃圾信息)。

4),因为游客帐号需要保存的cookie信息没有密码,也用不着把游客的相关历史信息存入数据库。

3,具体实现:

1),jsp页面文件:只有一个显示日记或目标内容的页面需要在下部加一个游客留言的frame;

2),java文件:传递游客信息需要增加一个GuestArtInfo.java,一个相应的FormBean:GuestArtForm.java,一个提交游客评论的Action:PostGuestArtAction.java,一个游客每次提交评论成功后的cookie写入方法,可以把这个方法归入到util包,为了高效,单独建一个类CookieManager.java,方法的名字就是writeCookie(Ojbect cookieInfo),然后,在用户以后来访问的时候,有一个读取cookie信息的方法:Object readCookie()也放在CookieManager中,同样。在这里,读了cookie还有一个传入游客评论frame页面的过程,这时,又需要建立一个保持cookie信息的GuestInfo.java

3),为了把游客的评论归入系统的单独一个游客帐户统一管理和简化实现,关健是要把“名字(必须),邮件(必须),网站(可选)”字段以特殊的标记加在内容前面,要显示时再把这些字段分离出来(日记的作者和管理员可以看见这些特殊内容),而且这个过程对用户来说是透明的。

初步设想如下:

存入数据库格式:


[guest]

 [name]

   littlebat

 [/name]

 [gemail]

   mdx-xx@tom.com

 [/gemail]

 [site]

   http://java.learndiary.com

 [/site]

[/quest]

评论内容

分离数据方式:

用正则表达式分离[guest]和[/guest]之间的内容,再用正则表达式把各个字段分离出来封装进上面保持游客cookie信息的GuestInfo.java类中。这个类的对象传入显示页面再读出来进行显示。

游客评论的显示格式为:标题  <a href=游客网站>游客名字</a> 发表时间

4、实现步骤:

1),依次完成GuestArtInfo.java,GuestInfo.java,CookieManager.java,GuestArtForm.java,PostGuestArtAction.java

2),完成jsp页面

3),测试和发布

5、时间:

想做就做,做完为止。

个人网站,不要流量也一样赚钱!(转帖)

转自:http://www.cn-pn.com/article/1/60.html

网站需要策略和运作,任何网站都是。下面这篇文章可以作为大家做任何网站的一点参考。

正文:

××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××

个人网站,不要流量也一样赚钱!

编辑:flymorn 来源:eczn.com 更新:2006-10-31 20:58:36 点击:

【字体:小 大】

摘要:个人网站,不要流量也一样赚钱!个人站长最擅长拉流量的方式就不外乎QQ广告群发。论坛发贴,砸钱,这些都手段却是能起到一定的作用,但是需要投入大量的人力和财力。

关键字:网站 流量 网赚

正文:

在写这个标题的时候。很多人点击进来看是觉得很好奇。个人站没流量拿什么赚钱,这似乎不可能,现在我来告诉你,这是完全可以的。很多站长认为。网站要赚钱,先从流量开始。其实这是一个误区,作网站要赚钱不是先从流量开始。而是先从品牌开始。

个人站长最擅长拉流量的方式就不外乎QQ广告群发。论坛发贴,砸钱,这些都手段却是能起到一定的作用,但是需要投入大量的人力和财力。

最近在DONEWS.“庞”出现的频率甚多,而其自创的BLOG招聘也打出中国第一。每每公司有新人进来之时也要在BLOG上大赞,而最吸引人的眼球是 “加入我们,3年,您有望成为千万富翁 ”,使得庞的QQ人满为患,“世外桃源,高薪水,高待遇,老板的传奇经历”,无不吸引着每个人的眼球。庞是个极其敏锐,极富洞悉力的新新人类,而他的得力干将屠则是擅长网络营销的高手,加之其在BLOG里自暴喜欢研究周易。而在中国很少有听说搞IT的还擅长周易相学。

细心的人可以发现,这是一种品牌营销的战略,2004年火了的刀郎,庞龙,在不闻其人先闻其声的策略下,歌曲在网络上迅速窜红,他们卖的是关子,不论是批评还是赞扬,他们却是火了一把,顺便那个假“刀朗”称火打劫一把,也来凑个热闹。这些迅速走红的歌手从一开始的闻其声不见其人,到最后的频繁在媒体露面,接受采访,办演唱会,张扬,绯闻,炒作,与之前的低调作风格格不入,可见其营销策略。

大家经常说,无论是黑猫白猫,只要能抓耗子就是好猫,谁都想兜里的钞票揣得鼓鼓的,所以只要在不违反国家法律法规的前提下,这些手段都是可以用的,

不论是传统行业还是新兴的IT网络,我们都要重视品牌的营销。学会如何推销自己,用最少的成本获得最大的回报。

9FLASH的杨涛 一篇“9flash的流量是怎样练成的”文章,被众多站长拜读,不但营销了自己的9FLASH品牌。而且还增加了网站的流量。他所写的东西正是我们站长喜欢的。杨涛是个绝对聪明的人,他很早就注重自己网站品牌的营销,当初给自己的网站定了口号,打出“爱你就象老鼠爱大米”,他把他的心得写了出来。得到了大家的认可,在读者的心里有了烙印。他的品牌自然会提升。而他的文章也在各大媒体转载,包括新浪(http: //tech.sina.com.cn/i/2005-03-23/1729559535.shtml),否则一个个人站长怎能拿到某日本的华资企业数百万元的投资。

收购的公司看重的是9FLASH 的品牌,所以网站的价值品牌排在第一位,而内容则是在品牌之后的次重点。

那么,网络营销到底能起到什么的效果那,他们能解决你所遇到的哪些问题呢?我看他可以解决你的流量问题,增加网站知名度,给你带来很高的现金收入。

好123不外乎个人站长的顶峰之作,很多人认为李兴平是个善于营销的搞人。我不这么认为,他的成功是有偶然性,不可复制性的。我不否认他的成功,但是就品牌营销上他绝对是个弱者,李做网站N 年,其好123的盈利模式一直很单一,而李的性格内向,拒绝一切外来的合作者,而其在265组织的厦门站长大会上却是他这么多年第一次走出广东省,实在令人汗颜。而好123的价格网络上一直有传被千万收购,其实从李在厦门站长大会上的一番话。圈里人也都明白了百度拣了个大便宜,实在佩服李彦宏见缝就插的能力。

好123其实有更深的价值去挖掘,百度收购好123不是平白无故的,正是利用他在个人站长中的品牌优势,对百度产品进行更深层次的推广,而好123无疑是个很好的平台。

                         --转帖完毕

SEO在网站运营中的位置(转帖)

转自:(http://www.chinamyhosting.com/seoblog/2006/11/09/seo-position/

 

SEO在网站运营中的位置 2006年11月9日

谈了这么多SEO,有可能让人误解搜索引擎优化在网站运营中占很大一部分,其实搜索引擎优化只是网站运营食物链中比较低层的一个位置。

我觉得从总体上来说,网站运营和SEO是这样层层包括的关系:

网站运营-网络营销-网站推广-SEM-SEO

网站运营是一个总体概念,包括了设计,编程,客户服务,公司管理等。网络营销是网站运营的一部分。

网络营销又包含很多内容,并不局限于网站本身的推广。网络营销还包含比如blog营销,市场定位,价格策略,销售流程的设计和优化,产品策略,电子邮件营销等。网站推广是网络营销的一部分,

网站推广又包括很多方法,比如联署计划,论坛的参与,免费礼物以吸引用户,发布新闻稿等。SEM(搜索引擎营销)是网站推广的其中一种手段。

SEM主要包括SEO(搜索引擎优化)和PPC竞价广告。

SEO只是网站推广和网络营销的一小部分内容,当然我个人觉得SEO是网站推广最有效的手法。

专门招聘SEO人员的公司和网站似乎不是很多,所以做SEO的人应该把自己的知识往食物链的上层扩展,多了解网站推广和网络营销的总体知识,对职业的发展有好处,而且对SEO本身的深度和广度也有很大好处。有很多SEO技巧不能只从技术层面看,而要考虑到这些技术对网站整体营销的影响。

作者: Zac

原载: 搜索引擎优化SEO每天一贴

版权所有。转载时必须以链接形式注明作者和原始出处及本声明。

收藏本页到:

365Key | del.icio.us

相关文章:

    * 谁是你的顾客?

    * 抓住一个方法,然后坚持!

    * 长尾理论和SEO及网络营销

    * 中英文垃圾邮件比较和网络商机

    * 写blog是不是就得干点什么?