2008年1月14日 下午 07:08:00

<meta name="description" content="对本页的描述">

<meta name="description" content="对本页的描述">此标记提供了对当前页面一个简短描述。在很多情况下该描述会作为页面摘要（snippet）显示在谷歌的搜索结果中。详情请参阅我们的博客文章“使用更好的元描述来改善页面摘要”以及帮助中心的文章“如何更改网站的标题和描述”。虽然描述元标记是可选的，并且不会影响到您的排名，一个好的描述可以产生一个更好的页面摘要，这反过来又可以帮助提高我们的搜索结果质量和你的网页的访问者数量。

<title>页面标题</title>从技术上讲，标题标记并不是一个元标记，它经常与"description"标记一起使用。此标记的内容（即标题）一般显示在搜索结果中（当然，当用户使用浏览器来浏览网页或察看书签时也能看到页面标题）。我们的博客文章"针对访问者，还是针对搜索引擎？"尤其是"充分利用网页标题"中有关于标题标记的更多信息。

<meta name="robots" content="…, …">
<meta name="googlebot" content="…, …">这些元标记控制搜索引擎如何抓取和索引页。 "robots"元标记指定的规则适用于所有搜索引擎，"googlebot"元标记指定的规则只适用于谷歌。谷歌可以理解以下值（当指定多个值时，用逗号将它们分开） ：

* noindex: 防止网页被索引（见"使用元标记拦截或删除网页")
* nofollow: 不要通过当前页的链接来寻找并抓取新的网页（也见"使用元标记拦截或删除网页")
* nosnippet: 在搜索结果中显示当前页时，不要显示页面摘要（见"防止显示或删除页面摘要")
* noodp: 在为本页产生标题或页面摘要时，不要使用开放式目录项目（又名dmoz.org）中的文本（见"如何更改网站的标题和描述？")
* noarchive: 在显示本网页于搜索结果中时，不要显示一个"网页快照"链接（见"防止显示或删除缓存的网页")
* unavailable_after:[日期]:在指定的日期和时间后从搜索结果中删除这个网页（见"机器人排除协议：现在更灵活")

当你完全省略此标记或当你指定content= "all"时，默认规则是"index, follow"。"使用 robots 元标记"中有关于"robots"元标记的更多信息。作为一个说明，你现在也可以在你的页面首部通过"X-Robots-标签"HTTP 头指令来指定这一信息。这特别有用，尤其是当你想微调抓取和索引诸如 PDF、图片或其他类型的非 HTML 文件时。

<meta name="google" value="notranslate">当我们认识到一个页面的内容并不是用用户可能想读的语言所写时，我们往往在搜索结果中提供一个链接以自动翻译你的网页。一般来说，这让你有机会提供独特和令人折服的内容给一个更广大的用户群。不过，在特定情况下，你可能不想你的网页被翻译。用这个元标记，你可以表明你不想让谷歌提供一个翻译此页的链接。这个元标记一般不影响该页为任何特定语言的排名。更多的信息请参阅"谷歌翻译常见问题解答"。

<meta name="verify-v1" content="…">这是一个谷歌网站管理员工具的特定元标记，它是被用在你网站的高层页面，以在网站管理员中核实一个网站的所有者（另一种核实方法是上传一个HTML文件）。你为这个标记所设置的 "content="的值是由你的网站管理员工具帐户提供的。请注意，这一元标记的 content 值（包括大小写）必须和你的帐户提供给你的值完全一样，这和你是否从 XHTML 改变标记为 HTML 无关，也和你标签的格式是否与你的网页相符无关。详情请见" 如何通过向网站主页中添加元标记来验证网站？"

<meta http-equiv="Content-Type" content="…; charset=…">这个元标记定义该页的内容类型和字符集。使用这个元标记时，content 属性的值必须放在引号中;否则字符属性可能被错误理解。如果你决定 使用这个元标记，不用说，你应该确保你的内容实际上用的是指定的字符集。"谷歌的网络作者统计"里有一些关于这个元标记的使用的有趣数据。

<meta http-equiv="refresh" content="…;url=…">这个元标记在一定的时间后将用户指引到一个新的 URL，有时它被用来作为一种简单的重定向形式。不是所有浏览器都支持这种重定向。它也可能混淆用户。对显示在搜索引擎结果中的某一页面，如果你需要改变它的 URL，我们建议您使用服务器端的 301 重定向。此外，W3C 的"网页内容易读性技巧和故障指南 2.0"把它列在应该被废弃的标记中。

(X)HTML 和大小写
谷歌既能阅读 HTML 式的元标记，也能阅读 XHTML 式的元标记（无论网页用的是哪种编码）。此外，元标记的大小写一般并不重要--我们把<TITLE> and <title>看作是同样的。但是，"verify-v1"元标记是一个例外，它是区分大小写的。

revisit-after 网站地图的 lastmod 和 changefreq 标记
偶尔，网络管理员不必要地包含了"revisit-after"标记以加快一个搜索引擎的爬行速度，不幸的是，这个元标记大多数情况下是被忽略的。如果你想 让搜索引擎知道你更改页面的信息，你可以提交一个 XML 格式的网站地图。在该文件中，你可以说明你网站的最后修改日期(lastmod)和 URL 页面的改变频率(changefreq)。

如果您想要更多的例子，或有对如上所述的元标记有任何疑问，请到我们的谷歌网站管理员讨论组参与讨论。

又及：你可以阅读网络管理员帮助讨论组里的关于其他热门选择的一个讨论。

如果仓促而为，设计一个专题或者网站一定会成为恶梦。Web设计需要遵循一些准则并有计划地去做。

       Rule #1 : 先出设计图

这是必须的。不要假设设计图在你的头脑中就开始设计web，必须要放到纸上。可以这样做：

1，  拿尺子、笔和纸，按照具体的尺寸一行一行地画下来；

2，  记得考虑分界线的长度等，这样才能符合CSS的像素；

3，  记下设计的每一个细节免得忘记，如果把所有细节都累积到最后将是巨大的麻烦。

Rule #2 :配色

这是设计的核心部分，只有颜色搭配合适才能使你的网页看起来不错。首先要决定的是主色，也即你在网页中多数使用的颜色；然后选择跟主色调搭配的第二颜色；不要选择超过三种颜色不然你的设计看起来会很乱。如果你想要更多的颜色，可以使用浅色或者深色的阴影来搭配主色调。

1，  浏览十个跟你网页有同样主色调的网页；

2，  给几个人看你的配色方案并取得反馈；

3，  从浏览的网页和反馈你将更好地完善你的颜色搭配。

Rule #3 : 从基本的版块开始构建

定下配色和设计图之后，从最基本的框架开始构建——我的意思是说不添加任何文本。因为在版面中加入文本会使得架构混乱。方法如下：

1，  每一个版块设定边界线，这样能够看到具体的尺寸和位置；

2，  对不同的版块使用不同的颜色，在完成版块后再改成你想要的颜色。

Rule #4 : 理清CSS

不要在你的HTML文件中将styling元素搞得太复杂，不然等到你修改的时候你就不得不到处搜索。所以将所有styling元素归置在一个单独的CSS文档中。

在styling之前理清你的CSS免得太过杂乱导致你多次重复同一件事。CSS支持继承，也即parent block的style可以用于child block.，充分利用这条特性。命名CSS分类名也要易懂易记。比如使用“main_content”而不是“div_1”。

Rule #5 : 制订多重 CSS 文档

我们都知道，使用浏览器可以轻易地看到网页的输出，但使用另一浏览器的时候则可能发现输出不正常。这不是什么稀奇事儿，因为每个浏览器对HTML和CSS的处理方式都不一样。

为避免这种情况，每个浏览器准备一个CSS文档，这样所有浏览器都可以正常浏览。虽然这有一定的难度，但是记着指望一个CSS文档来满足所有浏览器是不可能的。

1、关心你的技艺
Care About Your Craft
除非你在乎能否漂亮地开发出软件，否则其它事情都是没有意义的。

2、思考！你的工作
Think!About Your Work
在你做某件事情的时候思考你在做什么。不间断地思考，实时地批判你的工作。这将占据你的一些宝贵时间，酬劳则是更为活跃地参与你喜爱的工作、感觉到自己在掌握范围日增的各种主题以及因感受到持续的进步而欢愉。从长远来说，你在时间上的投入将会随着你和你的团队变得更为高效、编写出更易于维护的代码以及开会时间的减少而得到回报。

3、提供各种选择，不要找蹩脚的借口
Provide Options,Don't Make Lame Excuses
不要说事情做不到；要说明能够做什么来挽回局面。不要害怕提出要求，也不要害怕承认你需要帮助。

4、不要容忍破窗户
Don't Live With Broken Windows
不要留着“破窗户”（低劣的设计、错误的决策、或者糟糕的代码）不修。发现一个就修一个。如果没有足够的时间进行适当的修理，采取某种行动防止进一步的破坏，并说明情势处在你的控制之下。
如果你发现你所在团队和项目的代码十分漂亮——编写整洁、设计良好，并且很优雅，你不会想成为第一个弄脏东西的人。

5、做变化的催化剂
Be a Catalyst for Change
你不能强迫人们改变。相反，要向他们展示未来可能会怎样，并帮助他们参与对未来的创造。
设计出你可以合理要求的东西，好好开发它。一旦完成，就拿给大家看，让他们大吃一惊。然后说：“要是我们增加...可能就会更好。”假装那并不重要。坐回椅子上，等着他们开始要你增加你本来就想要的功能。人们发现，参与正在发生的成功要更容易。让他们瞥见未来，你就能让他们聚集在你周围。

6、记住大图景
Remember the Big Picture
如果你抓一只青蛙放进沸水里，它会一下子跳出来。但是，如果你把青蛙放进冷水里，然后慢慢加热，青蛙不会注意到温度的缓慢变化，会呆在锅里，直到被煮熟。
不要像青蛙一样。留心大图景。要持续不断地观察周围发生的事情，而不只是你自己在做的事情。

7、使质量成为需求问题
Make Quality a Requirements Issue
你所制作的系统的范围和质量应该作为系统需求的一部分规定下来。让你的用户参与权衡，知道何时止步，提供足够好的软件。

8、定期为你的知识资产投资
Invest Regularly in Your Knowledge Portfolio

虽然这种simulation比较麻烦，但在以前也还应付的过去。可是随着java语言的发展，越来越多的呼声要求把enum这种数据结构独立出来，加入到java中。所以从java 1.5以后，就有了enum，这也是这篇blog要学习的topic。

学习的最好方式就是例子，先来一个：

注意事项已经在code中注释出，还要说明一点的是，这个java文件编译完成后不只有一个EnumDemo.class，还会有一个EnumDemo$Color.class，奇怪吧！

Another e.g.

这个例子要说明的就是case的情况。

就这么多吗，当然不是，我们的enum结构还可以定义自己的方法和属性。

属性	用途
id	给将要应用bean的变量一个名字，如果发现有相同id和scope的bean对象，则应用此对象而不会产生一个新的例示。
class	指明了bean的整个包名。
scope	表 明了此bean的作用范围，共有四个值：page, request, session, 和 application，缺省的是page属性，表明此bean只能应用于当前页（保存在当前页的PageContext 中）；request属性表明此bean只能应用于当前的用户请求中（保存在ServletRequest对象中）；session属性表明此bean能 应用于当前HttpSession生命周期内的所有页面；application属性值则表明此bean能应用于共享ServletContext的所有 页面。需要注意的是，当没有具有相同的id和scope对象时，一个jsp:useBean 实体只能作用于一个新的例示中，反之，则作用于以前的对象，这时，在jsp:useBean标签之间的任何jsp:setParameter和其它实体都 将被忽略。
type	说明将要索引对象的变量类型，它必须与类名及父类名相匹配。记住，这个变量的名字是由id属性值代替的。
beanName	给定此bean的名字，可以将其提供给bean的例示方法，只提供beanName和type而忽略class属性的情况是允许的。

 下面是标签处理方法类:UseBean.java：

import javax.servlet.jsp.*;

import javax.servlet.jsp.tagext.*;

import java.lang.reflect.*;

//

public class UseBean extends TagSupport{  //继承自TagSupport类

       private String scope;

       private String type;

       public UseBean(){super();}

       /**

        *设置属性存取方法，这个方法由容器自动调用。setId()和getId()由系统自动实现

        */

       public void setScope(String s) {

           this.scope = s;

      }    

       public String getScope(){return this.scope;}

       public void setType(String type){

              this.type=type;

       }

       public String getType(){return this.type;}

       /**

        *覆盖doStartTag方法

        */

        public int doStartTag() throws JspTagException 

        {  

            Object o = null;

           // find the bean in the specified scope

           if (scope.equals("page")) {

                     o = pageContext.getAttribute(getId(),PageContext.PAGE_SCOPE);

              } else if (scope.equals("request")) {

                     o = pageContext.getAttribute(getId(), PageContext.REQUEST_SCOPE);

              } else if (scope.equals("session")) {

                     o = pageContext.getAttribute(getId(), PageContext.SESSION_SCOPE);

              } else if (scope.equals("application")) {

                     o = pageContext.getAttribute(getId(), PageContext.APPLICATION_SCOPE);

           }

              if(o==null)

              {

                     System.out.println("o is null!");

                     try{

                            Class u=Class.forName(type);

                            o=u.newInstance();//无参构造方法

                            System.out.println("create success!");

                     }

                     catch(Exception e){

                            throw new JspTagException("error to created a "+getId()+" object!");

                     }

              }

              pageContext.setAttribute(getId(), o); //保存实例对象到上下文对象中

           return EVAL_BODY_INCLUDE; //返回类型

       }

}

现 在我们已经把对象实例放到pageContext里了，是不是这样就可以在JSP页面中直接引用了？当然不是了，直接将JAVA对象放进 pageContext中与在脚本中直接引用是不同的。差别在于JSP容器要负责取得这个对象，以脚本变量的形式提供给页面。即JSP容器负责来维护脚本 变量与pageContext中相应对象的状态。有两种方法可以为自定义标签来声明脚本变量。

一种是声明variable，一种是通过TagExtraInfo类声明变量。前者是JDK1.2后的方法，优点是比较方便。后者因为要再写一个类文件，所以显得麻烦些，但更灵活，出于兼容性与功能上的考虑，建议还是采用后者。（关于此类的详细说明，请参考PPT文档）

 import javax.servlet.jsp.*;

import javax.servlet.jsp.tagext.*;

 public class UseBeanTag extends TagExtraInfo {

    public VariableInfo[] getVariableInfo(TagData data) {

        return new VariableInfo[] {

      new VariableInfo(

            data.getId(),

           data.getAttributeString("type"),

            true,

            VariableInfo.AT_BEGIN)

        };

  }

}

现在，定义一个useBean标签的工作已进行大半，下面该定义标签库描述（TLD）文件了，该文件是一个XML文档，主要定义标签的属性、处理类和扩展信息类的声明。主要声明部分如下：(tag.tld)

……………………（省去标头部分）

<!-- useBEAN 标签-->

 <tag>

<name>useBEAN</name>

<!—声明标签处理类-->

    <tag-class>cn.dever.tag.UseBean</tag-class>

<!—声明标签扩展信息类-->

    <tei-class>cn.dever.taginfo.UseBeanTag</tei-class>

    <!—主体内容类型-->

    <body-content>jsp</body-content>

<!—属性设置-->

   <attribute>

        <name>scope</name>

<!—是否必选-->

        <required>true</required>

<!—是否可以使用JSP表达式-->

        <rtexprvalue>true</rtexprvalue>

      </attribute>

      <attribute>

        <name>id</name>

        <required>true</required>

        <rtexprvalue>true</rtexprvalue>

      </attribute>

      <attribute>

        <name>type</name>

        <required>true</required>

        <rtexprvalue>true</rtexprvalue>

      </attribute>

 </tag>

其实这个标签库描述文件应该是最先建立的，因为我们主要是为了说明实现的方法，所以标签描述放在后边了。接下就是将刚才做的这些东西部署到我们的应用中去。在目标JSP页面中引用一下就OK了。

<%@ taglib uri="/WEB-INF/tag.tld" prefix="dever" %>

<dever:useBEAN id="test" type="cn.dever.common.User" scope="page" />

OK，到此为止

1．Java基础

（1）参考书：java编程思想

2．java web编程

（1）HTTP协议

（2）java网络编程：参考书：O'reilly的《java网络编程（第三版）》

（3）java多线程：参考书：O'reilly的《java线程》

（4）java I/O：参考书：O'reilly的《java I/O》、《java NIO》

2．J2EE编程

（１）JNDI：定位服务器资源（EJB组件，Datasouce，JMS）查找方法，难点在于服务器资源文件的配置。

（２）JTA：事务的控制的方法，以及在什么场合使用JTA（保证不同数据库操作的原子性）

（３）RMI：Remote Method Invocation，RMI是EJB的基础O'reilly的《java RMI》

（４）EJB：理解EJB是如何通过RMI来实现对远端对象的调用的，以及在什么情况下要用到。参考书：O'reilly的《Head First EJB》、《Master EJB 3.0》

（５）JMS：

（6）Servlet/JSP：O'reilly的《java Servlet 2.3》、《Head First JSP/Servlet》

（7）JDBC：O'reilly的《JDBC编程》

（8）XML：O'reilly的《Java and XML》

2、领域知识的学习

（1）UML：

（2）Design Pattern：设计模式和框架的学习，包括EJB的设计模式和J2EE的核心模式，参考书：O'reilly的《Head First Design Pattern》、Gang of Four的《设计模式》、《J2EE设计模式》、《EJB设计模式》

3、Web Services

Web Services像是一种黏合剂，可以把不同的服务统一起来提供一个统一的调用接口，作为使用者来说，只要获得服务提供者的WSDL（对服务的描述）参考书：

    当你发现你已经可以掌握此程序语言之后，你可以选择： 

（1）向上延伸：学习OOA、OOD、Design Patterns、以及软件工程，以培养做大型计划的能力 
（2）向下深入：深入了解系统内部的运作机制，例如操作系统、虚拟机器（Virtual Machine）、甚至硬件（hardware）内部。
（3）向旁延伸：学习不同的API，例如：多媒体、数据库、企业运算（Enterprise Computing）…
另外，数据结构（data structure）、算法（algorithm）等基础也很重要。

java代码要编译成class字节码文件，需要由JDK的javac进行编译（至于如何编译，其中的一些编译原理可参看sun的The Java^TM Virtual Machine Specification），而jre则负责将class文件装载（装载原理略），对其进行安全检测等，最后由java解释器解释为具体平台上的机器指令。

4、HTTP请求处理过程

浏览器发起请求获取页面信息，浏览器只和本机传输层对话。传输层将请求截取封装成TCP请求段，添加一些随机数字标识数据，然后把请求传给本地网络层。网络层把数据解析封装成一定大小的本地IP数据报，并且传输给网络连接层/网络连接层把数据报封装成物理介质的模拟信号数据，通过wire将数据传输到通过地址表识的远程机器的网络连接层，远程机器由网络连接层进行解析，一层一层往上解析，直至应用层。

一、术语session
在我的经验里，session这个词被滥用的程度大概仅次于transaction，更加有趣的是transaction与session在某些语境下的含义是相同的。

session， 中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个 session。有时候我们可以看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关闭这个期间 ①。最混乱的是“用户（客户端）在一次会话期间”这样一句话，它可能指用户的一系列动作（一般情况下是同某个具体目的相关的一系列动作，比如从登录到选购 商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候也可能仅仅是指一次连接，也有可能是指含义①，其中的差 别只能靠上下文来推断②。

然而当session一词与网络协议相关联时，它又往往隐含了“面向连接”和/或“保持状态”这样两个含义， “面向连接”指的是在通信双方在通信之前要先建立一个通信的渠道，比如打电话，直到对方接了电话通信才能开始，与此相对的是写信，在你把信发出去的时候你 并不能确认对方的地址是否正确，通信渠道不一定能建立，但对发信人来说，通信已经开始了。“保持状态”则是指通信的一方能够把一系列的消息关联起来，使得 消息之间可以互相依赖，比如一个服务员能够认出再次光临的老顾客并且记得上次这个顾客还欠店里一块钱。这一类的例子有“一个TCP session”或者 “一个POP3 session”③。

而到了web服务器蓬勃发展的时代，session在web开发语境下的语义 又有了新的扩展，它的含义是指一类用来在客户端与服务器之间保持状态的解决方案④。有时候session也用来指这种解决方案的存储结构，如“把xxx保 存在session 里”⑤。由于各种用于web开发的语言在一定程度上都提供了对这种解决方案的支持，所以在某种特定语言的语境下，session也被用来指代该语言的解决 方案，比如经常把Java里提供的javax.servlet.http.HttpSession简称为session⑥。

鉴于这种混乱已不可改变，本文中session一词的运用也会根据上下文有不同的含义，请大家注意分辨。
在本文中，使用中文“浏览器会话期间”来表达含义①，使用“session机制”来表达含义④，使用“session”表达含义⑤，使用具体的“HttpSession”来表达含义⑥

二、HTTP协议与状态保持
HTTP 协议本身是无状态的，这与HTTP协议本来的目的是相符的，客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没有必要纪录彼此过去 的行为，每一次请求之间都是独立的，好比一个顾客和一个自动售货机或者一个普通的（非会员制）大卖场之间的关系一样。

然而聪明（或者贪 心？）的人们很快发现如果能够提供一些按需生成的动态信息会使web变得更加有用，就像给有线电视加上点播功能一样。这种需求一方面迫使HTML逐步添加 了表单、脚本、DOM等客户端行为，另一方面在服务器端则出现了CGI规范以响应客户端的动态请求，作为传输载体的HTTP协议也添加了文件上载、 cookie这些特性。其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机制则是又一种在客户端 与服务器之间保持状态的解决方案。

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：
1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。
2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。
3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。

由 于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的是在客户端保 持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所 以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

三、理解cookie机制
cookie机制的基本原理就如上面的例子一样简单，但是还有几个问题需要解决：“会员卡”如何分发；“会员卡”的内容；以及客户如何使用“会员卡”。

正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。

而cookie 的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的 资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出示，如果某家分店还发行了自 己的会员卡，那么进这家店的时候除了要出示麦当劳的会员卡，还要出示这家店的会员卡。

cookie的内容主要包括：名字，值，过期时间，路径和域。
其中域可以指定某一个域比如.google.com，相当于总店招牌，比如宝洁公司，也可以指定一个域下的具体某台机器比如www.google.com或者froogle.google.com，可以用飘柔来做比。
路径就是跟在域名后面的URL路径，比如/或者/foo等等，可以用某飘柔专柜做比。

路径与域合在一起就构成了cookie的作用范围。
如 果不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的 cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览器 就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。

存储在硬盘上的cookie 可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。对于IE，在一个打开的窗口上按 Ctrl-N（或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存cookie；对于 Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie。一般来说是用javascript的window.open打开的窗口会与原窗 口共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程序开发者造成很 大的困扰。

下面就是一个goolge设置cookie的响应头的例子
HTTP/1.1 302 Found
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html

这是使用HTTPLook这个HTTP Sniffer软件来俘获的HTTP通讯纪录的一部分
浏览器在再次访问goolge的资源时自动向外发送cookie
使用Firefox可以很容易的观察现有的cookie的值
使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。
IE也可以设置在接受cookie前询问
这是一个询问接受cookie的对话框。

四、理解session机制
session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当 程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 session id将被在本次响应中返回给客户端保存。

保存这 个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID，而。比如weblogic对于web应用程序生成的cookie，JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是 JSESSIONID。

由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://...../xxx;jsessionid= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。
为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单
<form name="testform" action="/xxx">
<input type="text">
</form>
在被传递给客户端之前将被改写成
<form name="testform" action="/xxx">
<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
<input type="text">
</form>
这种技术现在已较少应用，笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。
实际上这种技术可以简单的用对action应用URL重写来代替。

在 谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实可以想象一下会员卡的例子，除非顾客主动对店家提 出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程序 一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所 以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个 session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的 HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。

五、理解javax.servlet.http.HttpSession
HttpSession是Java平台对session机制的实现规范，因为它仅仅是个接口，具体到每个web应用服务器的提供商，除了对规范支持之外，仍然会有一些规范里没有规定的细微差异。这里我们以BEA的Weblogic Server8.1作为例子来演示。

首 先，Weblogic Server提供了一系列的参数来控制它的HttpSession的实现，包括使用cookie的开关选项，使用URL重写的开关选项，session持 久化的设置，session失效时间的设置，以及针对cookie的各种设置，比如设置cookie的名字、路径、域， cookie的生存时间等。

一 般情况下，session都是存储在内存里，当服务器进程被停止或者重启的时候，内存里的session也会被清空，如果设置了session的持久化特 性，服务器就会把session保存到硬盘上，当服务器进程重新启动或这些信息将能够被再次使用， Weblogic Server支持的持久性方式包括文件、数据库、客户端cookie保存和复制。

复制严格说来不算持久化保存，因为session实际上还是保存在内存里，不过同样的信息被复制到各个cluster内的服务器进程中，这样即使某个服务器进程停止工作也仍然可以从其他进程中取得session。

cookie生存时间的设置则会影响浏览器生成的cookie是否是一个会话cookie。默认是使用会话cookie。有兴趣的可以用它来试验我们在第四节里提到的那个误解。

cookie的路径对于web应用程序来说是一个非常重要的选项，Weblogic Server对这个选项的默认处理方式使得它与其他服务器有明显的区别。后面我们会专题讨论。

关于session的设置参考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

六、HttpSession常见问题
（在本小节中session的含义为⑤和⑥的混合）

1、session在何时被创建
一 个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用 HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <% @page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句 HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的 session对象的来历。

由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。

2、session何时被删除
综合前面的讨论，session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）

3、如何做到在浏览器关闭时删除session
严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。

4、有个HttpSessionListener是怎么回事
你 可以创建这样的listener去监控session的创建和销毁事件，使得在发生这样的事件时你可以做一些相应的工作。注意是session的创建和销 毁动作触发listener，而不是相反。类似的与HttpSession有关的listener还有 HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。

5

、存放在session中的对象必须是可序列化的吗
不是必需的。要 求对象可序列化只是为了session能够在集群中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。在 Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果 session中有不可序列化的对象，在session销毁时会有一个Exception，很奇怪。

6、如何才能正确的应付客户端禁止cookie的可能性
对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。

8、如何防止用户打开两个浏览器窗口操作导致的session混乱
这 个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端，同时保存在session里，客 户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与保存在session里的值是否一致，如果不一致则说明本次操作已经被提交过了。可 以参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascript window.open打开的窗口，一般不设置这个id，或者使用单独的id，以防主窗口无法操作，建议不要再window.open打开的窗口里做修改 操作，这样就可以不用设置。

9、为什么在Weblogic Server中改变session的值后要重新调用一次session.setValue
做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改变，需要向其他服务器进程复制新的session值。

10、为什么session不见了
排 除session正常失效的因素之外，服务器本身的可能性应该是微乎其微的，虽然笔者在iPlanet6SP1加若干补丁的Solaris版本上倒也遇到 过；浏览器插件的可能性次之，笔者也遇到过3721插件造成的问题；理论上防火墙或者代理服务器在cookie处理上也有可能会出现问题。
出现这一问题的大部分原因都是程序的错误，最常见的就是在一个应用程序中去访问另外一个应用程序。我们在下一节讨论这个问题。

七、跨应用程序的session共享

常 常有这样的情况，一个大项目被分割成若干小项目开发，为了能够互不干扰，要求每个小项目作为一个单独的web应用程序开发，可是到了最后突然发现某几个小 项目之间需要共享一些信息，或者想使用session来实现SSO(single sign on)，在session中保存login的用户信息，最自然的要求是应用程序间能够访问彼此的session。

然而按照Servlet规 范，session的作用范围应该仅仅限于当前应用程序下，不同的应用程序之间是不能够互相访问对方的session的。各个应用服务器从实际效果上都遵 守了这一规范，但是实现的细节却可能各有不同，因此解决跨应用程序session共享的方法也各不相同。

首先来看一下Tomcat是如何实 现web应用程序之间session的隔离的，从 Tomcat设置的cookie路径来看，它对不同的应用程序设置的cookie路径是不同的，这样不同的应用程序所用的session id是不同的，因此即使在同一个浏览器窗口里访问不同的应用程序，发送给服务器的session id也可以是不同的。

根据这个特性，我们可以推测Tomcat中session的内存结构大致如下。

笔 者以前用过的iPlanet也采用的是同样的方式，估计SunONE与iPlanet之间不会有太大的差别。对于这种方式的服务器，解决的思路很简单，实 际实行起来也不难。要么让所有的应用程序共享一个session id，要么让应用程序能够获得其他应用程序的session id。

iPlanet中有一种很简单的方法来实现共享一个session id，那就是把各个应用程序的cookie路径都设为/（实际上应该是/NASApp，对于应用程序来讲它的作用相当于根）。
<session-info>
<path>/NASApp</path>
</session-info>

需 要注意的是，操作共享的session应该遵循一些编程约定，比如在session attribute名字的前面加上应用程序的前缀，使得 setAttribute("name", "neo")变成setAttribute("app1.name", "neo")，以防止命名空间冲突，导致互相覆盖。

在Tomcat中则没有这么方便的选择。在Tomcat版本3上，我们还可以有 一些手段来共享session。对于版本4以上的Tomcat，目前笔者尚未发现简单的办法。只能借助于第三方的力量，比如使用文件、数据库、JMS或者 客户端cookie，URL参数或者隐藏字段等手段。

我们再看一下Weblogic Server是如何处理session的。

从 截屏画面上可以看到Weblogic Server对所有的应用程序设置的cookie的路径都是/，这是不是意味着在Weblogic Server中默认的就可以共享session了呢？然而一个小实验即可证明即使不同的应用程序使用的是同一个session，各个应用程序仍然只能访问 自己所设置的那些属性。这说明Weblogic Server中的session的内存结构可能如下

对于这样一种结构，在 session机制本身上来解决session共享的问题应该是不可能的了。除了借助于第三方的力量，比如使用文件、数据库、JMS或者客户端 cookie，URL参数或者隐藏字段等手段，还有一种较为方便的做法，就是把一个应用程序的session放到ServletContext中，这样另 外一个应用程序就可以从ServletContext中取得前一个应用程序的引用。示例代码如下，

应用程序A
context.setAttribute("appA", session);

应用程序B
contextA = context.getContext("/appA");
HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");

值得注意的是这种用法不可移植，因为根据ServletContext的JavaDoc，应用服务器可以处于安全的原因对于context.getContext("/appA");返回空值，以上做法在Weblogic Server 8.1中通过。

那 么Weblogic Server为什么要把所有的应用程序的cookie路径都设为/呢？原来是为了SSO，凡是共享这个session的应用程序都可以共享认证的信息。一 个简单的实验就可以证明这一点，修改首先登录的那个应用程序的描述符weblogic.xml，把cookie路径修改为/appA 访问另外一个应用程序会重新要求登录，即使是反过来，先访问cookie路径为/的应用程序，再访问修改过路径的这个，虽然不再提示登录，但是登录的用户 信息也会丢失。注意做这个实验时认证方式应该使用FORM，因为浏览器和web服务器对basic认证方式有其他的处理方式，第二次请求的认证不是通过 session来实现的。具体请参看[7] secion 14.8 Authorization，你可以修改所附的示例程序来做这些试验。

HTTPLook 是一个 HTTP 的嗅探器，它能捕捉本机与其它任何主机的 HTTP 通讯（不是 HTTPS 哦 ）， 然后显示详细的 HTTP 操作（如 GET/POST）、访问资源的 URL 、字节数大小等，这个软件简单易用，不用对 Internet Explorer 做任何其它设置（有的软件通过在 IE 中设置代理来监控数据），也不需要其它任何软件的支持，是一款较为绿色的、轻量级的软件。

HTTPLook 的应用场景：

1、程序开发及调试

在 CGI、ASP/PHP/JSP、ASP.NET、Web Service 的开发中，经常要查看 GET 或 POST 的数据是否正确，用这个工具能很好地协助完成此工作。

2、复杂页面分析

上网有时会碰到的很复杂的页面，查看源码也不能了解它的工作原理，这一般是作者为了保护 Web 在页面而加上了一些保护机制（如使用 Frame/IFrame、捕捉键盘或 Mouse 事件、使用 Script 来访问资源等），使用 HTTPLook 有助于对此页面进行分析，进而破解其保护机制。

比较典型的一个例子就是 SharePoint Team Services 中使用了 WebBot ，查看源码根本不知道它调用了那些 ASP/Script/CSS 文件，但使用 HTTPLook 之后，一目了然，非常有效，可以据此来自定义原有页面风格，如色彩，字体等。

3、获得被保护的 Web 资源

在很多网站上，尤其是 Microsoft 的网站上，经常见到一些制做精美的 Flash ，但是由于 Flash 不是一个单一文件，而是在最先启动的 FLASH 中再调用其它 Flash 资源文件，由于无法获得这些文件的 URL ，所以下载到本地，但如果使用 HTTPLook ，通过对整个播放过程的监视，就可以完全侦测出所有在程序中访问的资源的地址，进而保存到本地，可以离线浏览。当然也可以保存其它资源，如图片等。

4、学习 HTTP 协议

可以详细地了解 HTTP 通讯的细节，如 GET/POST、User-Agent、Cookie、Proxy 设置及验证、HTTP 协议出错代码及意义等。

10 Status Code Definitions

Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.

10.1 Informational 1xx

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.

A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.

Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a

proxy adds a "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).)

10.1.1 100 Continue

The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code.

10.1.2 101 Switching Protocols

The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response.

The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.

10.2 Successful 2xx

This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.2.1 200 OK

The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

GET an entity corresponding to the requested resource is sent in the response;

HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

POST an entity describing or containing the result of the action;

TRACE an entity containing the request message as received by the end server.

10.2.2 201 Created

The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.

A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.

10.2.3 202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

10.2.4 203 Non-Authoritative Information

The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).

10.2.5 204 No Content

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

10.2.6 205 Reset Content

The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.

10.2.7 206 Partial Content

The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.

The response MUST include the following header fields:

      - Either a Content-Range header field (section 14.16) indicating
the range included with this response, or a multipart/byteranges
Content-Type including Content-Range fields for each part. If a
Content-Length header field is present in the response, its
value MUST match the actual number of OCTETs transmitted in the
message-body.

      - Date

      - ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant

If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.

A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4.

A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.

10.3 Redirection 3xx

This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.

      Note: previous versions of this specification recommended a
maximum of five redirections. Content developers should be aware
that there might be clients that implement such a fixed
limitation.

10.3.1 300 Multiple Choices

The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request.  However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.

10.3.4 303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

      Note: Many pre-HTTP/1.1 user agents do not understand the 303
status. When interoperability with such clients is a concern, the
302 status code may be used instead, since most user agents react
to a 302 response as described here for 303.

10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

The response MUST include the following header fields:

      - Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.

      - ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant

If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

10.3.6 305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.

      Note: RFC 2068 was not clear that 305 was intended to redirect a
single request, and to be generated by origin servers only.  Not
observing these limitations has significant security consequences.

10.3.7 306 (Unused)

The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application.

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

10.4.3 402 Payment Required

This code is reserved for future use.

10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

10.4.6 405 Method Not Allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.

10.4.7 406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

      Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
request. In some cases, this may even be preferable to sending a
406 response. User agents are encouraged to inspect the headers of
an incoming response to determine if it is acceptable.

If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

10.4.8 407 Proxy Authentication Required

This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

10.4.9 408 Request Timeout

The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.

10.4.10 409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough

information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.

10.4.11 410 Gone

The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

10.4.12 411 Length Required

The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.

10.4.13 412 Precondition Failed

The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.

10.4.14 413 Request Entity Too Large

The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.

10.4.15 414 Request-URI Too Long

The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.

10.4.16 415 Unsupported Media Type

The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.

10.4.17 416 Requested Range Not Satisfiable

A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)

When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type.

10.4.18 417 Expectation Failed

The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.

10.5 Server Error 5xx

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.

10.5.1 500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

10.5.2 501 Not Implemented

The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

10.5.3 502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

10.5.4 503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

      Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.

10.5.5 504 Gateway Timeout

The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.

      Note: Note to implementors: some deployed proxies are known to
return 400 or 500 when DNS lookups time out.

10.5.6 505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.

获取用户需求

　　这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动（如图1所示）。

　　● 了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。

　　● 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。

　　● 需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：

　　⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；

　　图1 获取用户需求的活动

　　⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；

　　⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。

　　● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：

　　⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；

　　⑵使需求符合系统的整体目标；

　　⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。

分析用户需求

　　在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动：

　　● 以图形表示的方式描述系统的整体结构，包括系统的边界与接口；

　　● 通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价；

　　● 系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等；

　　● 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。

　　图2 DFD示意图

　　用于需求建模的方法有很多种，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。DFD作为结构化系统分析与设计的主要方法，已经得到了广泛的应用，DFD尤其适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。图2描述的是某个项目的DFD示意图。

　　ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。需求分析阶段使用ERD来描述现实世界中的对象。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。

　　在面向对象分析的方法中通常使用Use Case来获取软件的需求。Use Case通过描述“系统”和“活动者”之间的交互来描述系统的行为。通过分解系统目标，Use Case描述活动者为了实现这些目标而执行的所有步骤。Use Case方法最主要的优点，在于它是用户导向的，用户可以根据自己所对应的Use Case来不断细化自己的需求。此外，使用Use Case还可以方便地得到系统功能的测试用例。

编写需求文档

　　需求文档可以使用自然语言或形式化语言来描述，还可以添加图形的表述方式和模型表征的方式。需求文档应该包括用户的所有需求（功能性需求和非功能性需求）。

评审需求文档

　　需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。

管理需求

　　图1 需求变更流程

　　需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。需求变更流程和需求跟踪矩阵分别如图1和图2所示。

　　图2 需求跟踪矩阵

　　常见问题及建议

　　Q、客户与最终用户的区别是什么？

　　A、可以借助图3来说明它们之间的区别。

　　图3 需求获取渠道示意图

　　软件需求来自系统工程与客户两个方面，其中客户是主要的需求提供者（系统工程需求也来自于客户）。客户需要搜集其最终用户的需求并考虑自身的需求，然后再提供给开发方。假如客户并未去认真搜集最终用户的需求，开发方便需要做到这一点，因为系统最终要满足最终用户的需求。

　　Q、如何进行用户访谈？

　　A、首先，一定要事先确定访谈的目的和提纲。其次，因为用户往往并不知道应该提供哪些方面的需求，所以需要开发人员引导。

　　Q、用户访谈内容是什么？

　　A、首先，请用户描述他们如何完成自己当前的工作，并与用户一起抽象出一个工作流程或工作模型。然后，在得到用户的认可后，向用户解释自己是怎样来实现这些功能的，并说明哪些环节可以用自动化方式实现等。

　　Q、采用哪一种方式做需求分析最好？

　　A、不同的需求分析有不同的特点。还没有哪一种方法可以完全替代别的方法，否则，现在就不会存在不同的需求建模方式了。一般来说，可以使用DFD＋ERD来描述那些功能层次比较清晰的需求；而USE CASE则适于描述功能结构复杂的需求。做需求分析的目的是为了建立需求的模型，不同的子系统有可能使用不同的建模方法。

　　Q、怎样做原型，原型的目的是什么？

　　A、通常使用原型分析方法来帮助开发方进一步获取用户需求或让用户确认需求。开发方往往先向用户提供一个可视界面作为原型，并在界面上布置必要的元素以演示用户所需要的功能。可以使用第四代语言（例如Visual Basic、Delphi等）来快速生成用户界面，也可以使用FrontPage等网页制作工具来生成用户可视的页面流。

　　原型的目的往往是获取需求。但有时也使用原型的方式来验证关键技术或技术难点。对于技术原型，界面则往往被忽略掉。

            Hello h = new Hello_Stub();
            h.getString();
            

我们不会这样写：

            Hello_Stub h = new Hello_Stub();
            h.getString();
            

因为使用接口适用性更广，就算更换了接口实现类，也不需要更改代码。因此客户端需要Hello.class和Hello_Stub.class这两个文件。

但是对于EJB来说，就不需要Hello_Stub.class，因为服务器会发送给它，但是Hello.class文件客户端是省不了的，必须有。表面上我们的客户端代码在操纵Hello，但别忘记了Hello只是一个接口，抽象的，实质上是在操纵Hello_Stub。

            ((Hello Home)) home = (Home)
            ((Portable Remote Object)).narrow(ctx.lookup("Hello"),
            ((Hello Home)).class);
            

这一行代码是从JNDI获得Home接口，但是请记住！接口是抽象的，那么home这个对象到底是什么类的对象实例呢？很简单，用toString()输出看一下就明白了，下面一行是输出结果：

            ((Hello Bean))_HomeImpl_WLStub@18c458
            

这表明home这个通过从服务器的JNDI树上查找获得的对象实际上是HelloBean_HomeImpl_WLStub类的一个实例。

接下来客户端代码：

            Hello h = home.create()
            

同样Hello只是一个抽象的接口，那么h对象是什么东西呢？打印一下：

            ((Hello Bean))_EOImpl_WLStub@8fa0d1
            

            Hello h = home.create();h.helloWorld();