上一篇说道session和cookie的关系，一般情况下session是借助于cookie传值的，那么cookie被禁用了，session怎么传id的值，下面介绍两种方法

 

经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。

附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

当客户端浏览器中禁止 Cookie，Servlet 容器无法从客户端浏览器中取得作为 Cookie 的 Session ID，也就无法跟踪客户状态。Java Servlet API 中提出了跟踪 Session 的另一种机制，如果客户端浏览器不支持 Cookie，Servlet 容器可以重写客户请求的 URL，把 Session ID 添加到 URL 信息中。

HttpServletResponse 接口提供了重写 URL 的方法：public java.lang.String
encodeURL(java.lang.String url)

该方法的实现机制为：
● 先判断当前的 Web 组件是否启用 Session，如果没有启用 Session，直接返回参数 url。
● 再判断客户端浏览器是否支持 Cookie，如果支持 Cookie，直接返回参数 url；如果不支持 Cookie，就在参数 url 中加入
Session ID 信息，然后返回修改后的 url。

我们可以对网页中的链接稍作修改，解决以上问题：
修改前：
修改后：“>

这样，你就会发现你的url后面多了一个小尾巴
/grid.jsp;JSESSIONID=fjsdklafjdsfsldkafjlsf?type=1
其中的分号和JSESSIONID就是自动加上去的东西了。


还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：


< input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
< input type="text">
< /form>
实际上这种技术可以简单的用对action应用URL重写来代替。

 

URL重写有什么缺点

对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL。每个引用你的站点的URL，以及那些返回给用户的URL(即使通过间接手段，比如服务器重定向中的Location字段)都要添加额外的信息。这意味着在你的站点上不能有任何静态的HTML页面(至少静态页面中不能有任何链接到站点动态页面的链接)。因此，每个页面都必须使用servlet或JSP动态生成。即使所有的页面都动态生成，如果用户离开了会话并通过书签或链接再次回来，会话的信息都会丢失，因为存储下来的链接含有错误的标识信息－该URL后面的SESSION ID已经过期了。

http response的content-type header里指定的编码和html meta标签指定的编码是有优先级的。

使用隐藏的表单域有什么缺点：

仅当每个页面都是有表单提交而动态生成时，才能使用这种方法。单击常规的超文本链接并不产生表单提交，因此隐藏的表单域不能支持通常的会话跟踪，只能用于一系列特定的操作中