浏览器不支持或者禁止cookie,如何实现session机制

如果浏览器不支持或者禁止cookie,
如何实现session机制（如何实现sessionId的跟踪）
通过url重写机制来解决。
（1）对于需要支持session机制的页面/资源,
不能够直接在浏览器地址栏输入其地址。
要通过链接的方式。
（2）对于需要访问的地址，要使用如下方式：
response.encodeURL("需要访问的地址");
（3）对于重定向，要使用如下方式：
response.encodeRedirectURL("需要访问的地址");

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写，例如：



">
Homepage



该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。重写后的输出可能是这样的：



1&wd=Java">Homepage



即在文件名的后面，在URL参数的前面添加了字符串“;jsessionid=XXX”。其中XXX为Session的id。分析一下可以知道，增添的jsessionid字符串既不会影响请求的文件名，也不会影响提交的地址栏参数。用户单击这个链接的时候会把Session的id通过URL提交到服务器上，服务器通过解析URL地址获得Session的id。

如果是页面重定向（Redirection），URL地址重写可以这样写：

<%

if(“administrator”.equals(userName)){

response.sendRedirect(response.encodeRedirectURL(“administrator.jsp”));

return;

}

%>

效果跟response.encodeURL(Stringurl)是一样的：如果客户端支持Cookie，生成原URL地址，如果不支持Cookie，传回重写后的带有jsessionid字符串的地址。

对于WAP程序，由于大部分的手机浏览器都不支持Cookie，WAP程序都会采用URL地址重写来跟踪用户会话。比如用友集团的移动商街等。

%注意：TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有Cookie。尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie（因为并无任何Cookie可以携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有jsessionid了。


JavaServletAPI中引用Session机制来追踪客户的状态。ServletAPI中定义了javax.servlet.http.HttpSession接口，Servlet容器必须实现这个接口。当一个Session开始

时，Servlet容器将创建一个HttpSession对象，Servlet容器为HttpSession分配一个唯一标识符，称为SessionID。Servlet容器将SessionID作为Cookie保存在客户的浏览器中。每次客户发出HTTP请求时，Servlet容器可以从HttpRequest对象中读取SessionID，然后根据 SessionID找到相应的HttpSession对象，从而获取客户的状态信息。

当客户端浏览器中禁止Cookie，Servlet容器无法从客户端浏览器中取得作为Cookie的SessionID，也就无法跟踪客户状态。

JavaServletAPI中提出了跟踪Session 的另一种机制，如果客户端浏览器不支持Cookie，Servlet容器可以重写客户请求的URL，把SessionID添加到URL信息中。

HttpServletResponse接口提供了重写URL的方法：ng.StringencodeURL(ng.Stringurl)

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

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

修改后：
“>