通常 cookie 用于会话处理。然后所有选项卡和浏览器窗口共享同一个会话。但是您可以将您的 servlet 容器配置为使用 URL 重写而不是 cookie。 (这里是example for Jetty。)
使用 URL 重写时,会话只能通过包含会话 ID 的 URL 参数来识别。因此,您的 Web 应用程序的每个内部 URL 都必须使用方法 HttpServletResponse.encodeURL() 使用此参数进行增强。如果您正在使用像 Wicket 这样的 Web 框架,那么很有可能这已经为您完成了。
通过 URL 重写,可以在同一浏览器实例的不同窗口或选项卡中拥有多个独立会话。
更新:
为了回应反对票,我想明确 URL 重写的不同行为:
假设网站的 URL 是http://webapp.com。
Cookie:
在第一个浏览器选项卡中打开 http://webapp.com。
服务器创建一个会话并在响应中发送一个 cookie。
浏览器存储 cookie。
然后在第二个浏览器选项卡中打开http://webapp.com。浏览器将此 URL 与最近存储的 cookie 相关联,并将 cookie 添加到请求中。
对于服务器而言,来自第一个或第二个浏览器选项卡的请求和来自同一会话的响应之间没有区别。有时这是期望的行为。
网址重写:
在第一个浏览器选项卡中打开 http://webapp.com。
服务器创建一个 ID 为 1 的会话,并将参数 jsessionid=1 添加到响应页面中的每个 URL。没有 cookie 被传输。
从第一个浏览器选项卡对同一 web 应用的另一个页面的所有进一步请求都包括会话 ID(例如 1)。
然后从第二个浏览器选项卡打开http://webapp.com。 这里有区别!因为请求中没有cookie,也没有jsessionid参数,所以服务器新建一个session(即ID为2),并在响应页面中包含的每一个URL加上参数jsessionid=2 .从现在开始,来自第二个浏览器选项卡的所有后续请求都与会话 2 相关联。
所以你在同一个浏览器中有两个独立的会话。