apache|js|seo|二级域名|优化Apache是用了很长时间，但也只是用了很长时间，要说精通还谈不上。所以这四五天存在着补课的味道在里面：既然公司不能提供好的系统管理员，也只能是自已兼任了。经过对Apache和tomcat结合后的进行SEO优化的处理，四五天后，对这几件工具的基本逻辑框架有了统一的认识。

对URL重写的了解需要是针对这样的需求：偏向于HTML的SEO搜索引擎优化，以及提供不定量的二级域名便于模块管理和推广。搜索引擎不能识虽动态页面在技术上是不可能的；我认为最大的可能在于对于静态的hardlink，如果不存在搜索引擎会得到一个404标识；而对于动态页面，反应就不一定了。这样就不便于搜索引擎对索引维护和分目。

对Apache mod_rewrite的深入了解后，发现在它的文档和介绍文章中常常缺少几个关键性的导引；而过快地涉及到具体的细节。要理解mod_rewrite的工作，首先是要理解，mod_rewite是针对目录进行工作的。换言之，每一个目录的RewriteRule是各自独立的，每个目录的重写既是最高层的容器同时也是最低层的容器，因此，RewriteRule定义的地方是在各个目录所在的位置，<Directory $dir/> 或者是所在目录的.htaccess中。

其次，mod_rewrite是缺乏逻辑功能的平面型规则集合，因此每一个目录设置中都是每一条规则地进行重复性转换，[L]仅仅是表明一次匹配结束，它还需要重新匹配，直接没有任何条目与之匹配后才会输出请求，这样，如果规则稍多不但性能会直线下降，而且还很容易陷入混乱，所以 mod_rewrite要慎用，使用mod_rewrite来匹配二级域名要小心。对此，mod_rewrite设计者是期望使用正则表达式匹配，或允许用户调用perlShell作为复杂匹配逻辑上的应用。但这样就令开发变得复杂起来了。

由于 mod_rewrite是基于目录级的，所以它的优先级低于虚拟主机设置；而VirtualHost主机的优先级也低于 VirtualDocumentRoot的泛虚拟主机设置。由于VirtualHost的ServerName基于IP头的匹配不能使用正则表达式，因此，使用VirtualDocumentRoot设置多级域名存在着非常大的限制,应用稍微多元化就会面临着难以克服的冲突。因此，单纯使用虚拟主机或者是URL 重写都是不太有效率的，这时侯主要路径应该是使用html导引，这样既可以满足SEO喜欢hardlink的要求，也不会影响到使用者的浏览；最重要的是，可以把主要解决方案集中到一个应用程序的范筹，简化了项目技术，也就降低了项目的成本。

使用mod_rewrite和二级域名的站点基本上使用php大概是基于这样的原因：会话的一致性维护。当mod_rewrite应用到jsp站点时存在着很大的复杂性。由于mod_rewrite是针对目录进行的，它必然干扰到目录的运作；而jsp的上下文由于根据基础目录作为应用程序的判断的；这样，在目录清晰的情况下，jsp在不同的域名和虚拟主机下面都能正常识别到所维护的会话，但一旦目录不齐全，象使用二级域名，无论这个目录解释是来源于 URL重写还是虚拟主机设设置，浏览器都会把它看作是两个会话请求，从而造成混乱。因此，在jsp站点使用二级域名，除了使用硬的html连接导引外，别无它法。当然，使用Redirect方式可以解决问题的，表面上，但这样的话就失去了SEO的意义；而URL重写本来就是为了SEO而进行的；那么又何必搞重写呢？

而且，这种域名/路径和会话的关系，不同的浏览器表现还不一样。IE仅与上下文路径相关，而firefox/mozila/netscape却与域名（二级域名）也有关系。这样，如果不想引起混乱的话，最好定好改写的界限，在某处就停下来，仅仅把改写作为一个入口，而其他，以完整的主域名为主要域名。同时也意味着相对路径无论对于图片还是静态动态文件都是不可靠的。关于由于路径变化造成的会话丢失，无论是那一种浏览器，都会自动把会话清除掉，从而造成会话的丢失。

综上所术，在/.htaccess中的URL二级域名重写，最好还是从一开始就写成重定向到标准主机和路径，这样可以省却后面的许多麻烦，同时，对于SEO来说，并不影响蜮名本身受到赋值。