关于session的实现：cookie与url重写
本文讨论的语境是java EE servlet。
我们都知道session的实现主要两种方式：cookie与url重写，而cookie是首选(默认)的方式，因为各种现代浏览器都默认开通cookie功能，但是每种浏览器也都有允许cookie失效的设置。
由于浏览器默认启动cookie功能，而且普通客户一般都不会取消cookie功能。久而久之，我们写代码的时候，也就不会在意session的具体实现，其实这里面还是有很多值得注意的地方，尤其在用户取消cookie功能的情况下。
一 servlet session实现与接口简要介绍：
servlet规范规定实现session的cookie名称强制为jsessionid(在servlet 3.0 可以自定义了)，在浏览器第一次请求的时候，服务器产生一个唯一的id，并把这个id设置给一个名为jsessionid的cookie，然后再通过reponse的addcookie，输出到浏览器端。其实这些东西我们都可以通过debug模式下的去查看服务器，来验证这些内容；或者用http协议拦截器来查看，因为servlet的所有接口也都是基于http协议的，
下面基于http协议解释一下：
浏览器第一次请求：
GET /cxt/index.do HTTP/1.1
...
由于是第一次请求，所以没有cookie要推给服务器
服务器返回：
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=3EF0AEC40F2C6C30A0580844C0E6B2E8; Path=/cxt
...
...
由于服务器没发现浏览器没提供任何cookie，服务器不知道是浏览器未提供cookie的原因：可能是cookie功能取消了，也可能是第一次访问。所以服务器生成一个名为jsessionid的cookie，用Set-Cookie来把cookie推给浏览器；并且，服务器的servlet在生成html页面的时候需要用reponse.encodeURL方法来编码url，该方法其实就是用来实现url重写功能的，这是因为浏览器可能是因为取消cookie功能，而未提供cookie的。服务器为了确保下次提交成功，必须确保生成给浏览器端的url带有jsessionid。
若cookie功能没取消，则浏览器浏览器第二次请求：
POST /cxt/login.do;jsessionid=3EF0AEC40F2C6C30A0580844C0E6B2E8 HTTP/1.1
Cookie: JSESSIONID=3EF0AEC40F2C6C30A0580844C0E6B2E8;
...
浏览器的下一次请求的时候用http的Cookie属性把当前domain的Cookie都推给服务器，来表明自己的身份。这次，服务器知道浏览器支持cookie功能，servlet不需要再使用reponse.encodeURL来编码url了
若浏览器cookie功能取消，则浏览器请求内容为
POST /cxt/login.do?jsessionid=3EF0AEC40F2C6C30A0580844C0E6B2E8 HTTP/1.1
...
服务器在接受到上述内容是，通过url后面的jsessionid参数知道这个请求与上一次请求是同一个session
与session有关的类接口：
HttpServletRequest.getSession
HttpSession
HttpServletResponse.encodeURL
二 实现url重写的编码注意点
1.既然浏览器可能被取消cookie功能，那么我们输出给客户端的代码中必须要支持url重写功能，分几种情况解释
假如纯粹用jsp/servlet来写，那么我们必须手动用reponse.encodeURL来编码每一个url，包括的href，form的action，或者其他href
2.使用其它web框架的话，最好消息使用框架提供的输出href功能，否则会有匪夷所思的结果。
比如用struts，若struts单独提供了一个tag来实现html:rewrite，比如logout ，这个tag功能与html:rewrite相似，也有href属性，生成带有标签的html内容。