(1) ) ) )。
这是保险措施
因为Session默认情况下需要Cookie支持
但是，一些客户的浏览器已经关闭了Cookie
在这种情况下，必须在URL中指定服务器上的session标记，即5f 4771183629 c 9834 f 8382 e23 be 13 C4 c
用一种方法(忘记了方法的名称)处理URL列可以得到这个东西
这个方法判断你的浏览器是否打开了Cookie，如果他认为应该添加他，就添加
(2) ) ) )。
链接1:wapbrowse.jsp？ curAlbumID=9；
链接2:wapbrowse.jsp； jsessionid=5ac 6268 DD 8d 4d 5d1fdf 5d 41 e9F2 FD 960？ curAlbumID=9；
这两个链接是从运行模拟器时生成的source复制的，两个链接都指向wapbrowse.jsp。 由于不包含链接1
由于是jsessionid，因此在wapbrowse.jsp中变量为null，在链接2中打开wapbrowse.jsp可以成功访问session变量
(3) ) )。
URL改写功能是为了防止部分用户禁止Cookie使用session而设置的功能. jsessionID后面的长字符串是您服务器上session的id号。 这样，可以在没有Cookie的情况下使用session。
(4) ) )。
http本身没有session，无法跟踪客户端信息。 换句话说，http协议可以是任何人连接自己。
为了实现session，需要浏览器的支持。 浏览器可以用cookie保存会话。 这是最常见的方法。
但是，即使我自己编写了完全符合http协议的浏览器，如果不配合服务器的session要求，服务器也无法生成session。
幸运的是，所有当前浏览器都符合session请求，即使关闭cookie，浏览器也会将sessionid传递给服务器。 此id保存在浏览器的内存空间中，不保存在硬盘cookie中。
(5) ) )。
会话id作为临时cookie放在浏览器端。
会话的具体信息放在服务器端。
对于每个来自浏览器的请求，http header都会携带会话id来标识自己。
既然使用Struts，顺便使用JSTL，
以下非常有用的标签：
清单12 .操作的语法
var='name' scope='scope '
.
URL的改写是通过操作自动进行的。 JSP容器存储用户的当前会话id
饼干，那么就不用重写了。 但是，如果不存在这样的cookie，则生成的所有URL
它将被改写为对会话id进行编码。 注：如果后续请求具有相应的cookie，则URL将停止重写并包含其id。
参考： http://www-900.IBM.com/developer works/cn/Java/j-jstl 0318/index.shtml
(6) ) )。
方法1 :将servlet/JSP文件名添加到URL中； jsessionId=sessionId。 其中，会话id为
HttpSession.getId ()，例如http://localhost:8080/aaa
/bbb.jsp； jsessionid=saldjfsdflsaeir234？ para=12=2
感性的害羞：在“APP”中保存会话管理器hashmap :会话id-- -
会话射频。 这将在所有servlet/JSP上调用。 这需要将sessionId作为参数(例如http: )传递给url
//localhost :8080/AAA/BBB.JSP？ sessionId=saldjfsdflsaeir234？ para=12=2，在服务中
器端通过request.getparameter(sessionid ) )获取
(7) ) )。
会话保存在服务器端。 服务器根据url请求的session_id搜索对应的session。
以bbs为例，站点必须为每个请求url获取用户信息，cookie方法可能会令人不安，因为所有用户信息都存储在cookie中
全部； 在session方式中，用户信息可以存储在服务器侧，服务器如果从http请求取得session_id，则存储在session中
用户信息。 这很安全。 会话在服务器上的行为取决于服务器，可能会写入临时文件或直接存储在内存中。
服务器从http请求中检索session_id的方法有两种： cookie和url重写。 如果客户端启用了cookie
session_id可以保存在cookie中； 如果禁用cookie
用url重写方式，在url中添加.jsessionid=xxxxx参数部分，服务器会试图从url中得到.jsessionid参数作为session_id.
(8)
cookie 是保存在客户端的文本格式数据，session是客户端登录到应用，由服务器为该客户端建立的唯一的标识，可以在session里面保存该客户端的数据比如说用户帐号。
一般cookie可以用来保存你的登录帐号和密码，在你登录到应用服务上，自动添加到登录界面或直接发送到服务器上进行登录，这就是你经常能在论坛上看到的你的登录信息保存一年的选项 的实现方式
(9)
在http的报文格式里面cookie和session是在同一个包文位置上的
如果ie发现包文里面包含cookie/session的信息的话，他会根据安全级别来决定是否保存相关信息，比如，如果安全机制允许使用
cookie那么ie将把cookie的信息保存到临时文件里面，每次在请求服务器文件的时候会把收到的session的信息加入到请求的报文里面，这就
是session保存信息的原理。如果安全机制不允许使用cookie的话，虽然ie收到了cookie和session的信息，那么cookie的信息
不会被写入临时文件，当ie再次请求服务器文件的时候，也不会把收到的session的信息加入到请求报文里面，服务器就无法知道session的信息
了。
jessionid通过这样的方式来从客户端传递到服务器端,从而来标识session。
注意一点，jsessionid跟一般的url参数传递方式是不同的，不是作为参数跟在"？"后面，而是紧跟在url后面用"；"来分隔。
这样在用户禁用cookie的时候我们也可以传递jsessionid来使用session了，
只不过需要每次都把jseesionid作为参数跟在url后面传递。
那这样岂不是很麻烦，每次请求一个url都要判断cookie是否可用，
如果禁用了cookie，还要从url里解析出jsessionid，然后跟在处理完后转到的url后面，以保持jsessionid的传递。
这些问题sun当然已经帮我们想到了。
所以提供了2个方法来使事情变得简单：response.encodeURL()和response.encodeRedirectURL()。
这2个方法会判断cookie是否可用，如果禁用了会解析出url中的jsessionid，并连接到指定的url后面，如果没有找到jessionid会自动帮我们生成一个。
至于为什么要有2个方法？这2个方法有什么不同？google了一下，说是这2个方法在判断是否要包含jsessionid的逻辑上会稍有不同。
在调用HttpServletResponse.sendRedirect前，应该先调用encodeRedirectURL()方法，否则可能会丢失Sesssion信息。
这2个方法的使用方法如：response.sendRedirect(response.encodeURL("/myapp/input.jsp"));。
如果cookie没有禁用，我们在浏览器地址栏中看到的地址是这样的：/myapp/input.jsp，如果禁用了cookie，我们会看到：/myapp/input.jsp;jsessionid=73E6B2470C91A433A6698C7681FD44F4。
所以，我们在写web应用的时候，为了保险起见，应该在程序里的每一个跳转url上都使用这2个方法，来保证session的可用性。
以前很少遇到这样的问题，今天又涨见识了...