URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的ID信息重写到URL地址中。服务器能够解析重写后的URL获取Session的ID。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。

HttpServletResponse类提供了encodeURL(String url)实现URL地址重写。例如：

<td>
<a href=”<%= response.encodeURL(“index.jsp?c=1&wd=Java”) %>”>Homepage</a>
</td>

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

<td>
<a href=”index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=1&wd=Java”>Homepage</a>
</td>

即在文件名的后面，在URL参数的前面添加了字符串“;jsessionid=XXX”。其中XXX为Session的id。分析一下可以知道，增添的jsessionid字符串既不会影响请求的文件名，也不会影响提交的地址栏参数。用户点击这个链接的时候会把Session的ID通过URL提交到服务器上，服务器通过解析URL地址获得Session的ID。
对于WAP程序，由于大部分的手机浏览器都不支持Cookie，WAP程序都会采用URL地址重写来跟踪用户会话。比如用友集团的移动商街等。
注意：TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有Cookie。尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie（因为并无任何Cookie可以携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有jsessionid了。
既然WAP上大部分的客户浏览器都不支持Cookie，索性禁止Session使用Cookie，统一使用URL地址重写会更好一些。Java Web规范支持通过配置的方式禁用Cookie。下面来说一下怎样通过配置禁止使用Cookie。 本文链接地址: jsp中使用URL重写跟踪Session，浏览器不支持Cookie的解决方案