有一个模拟浏览器行为的 Java 代码。它与 Tomcat 服务器进行状态对话，例如:登录、做某事、注销。
目前的实现是这样的:
- http post 到“登录”页面，存储返回的 cookie(假设它是 JSESSIONID=9845)。
- http 发布到“doSomething”页面，将存储的 cookie (JSESSIONID=9845) 与请求一起传递，不对响应 header 执行任何操作(忽略其他 cookie)
- http 到达“注销”页面，在请求中传递存储的 cookie (JSESSIONID=9845)。
这工作正常。
但是我不知道在第 2 步中忽略响应 header 是否安全。我是否应该期望服务器在对话期间更改 JSESSIONID 的值？
也就是说，如果第2步服务器在响应头中返回了Set-Cookie=[JSESSIONID=9846]怎么办？
我可以想象如下:
- 这在现实生活中不会发生，不值得检查，当前代码没问题。
- 这表明 Tomcat 服务器存在严重问题，值得检查，并且代码应该停止对话而无需进一步调用
- 这是合法的，Tomcat 服务器只是想为 session 使用一个新标识符，所以我必须存储新值，并在后续调用中使用它。当前代码应完成。
我想真正的浏览器会执行上面的 3. 选项，但也许 1. 和 2. 选项也是可以接受的？
最佳答案
通常 session 会在登录和注销时发生变化，这意味着您可以期望在很大程度上是安全的(但请继续阅读，我只说“通常”)。您在问忽略 HTTP 规范是否安全 - 我认为不安全，因为总是会出现意想不到的变化，使您的应用难以维护或升级基础架构。
其中一个很难找到的东西是:如果有一天，您开始在具有粘性 session 的集群上部署您的应用程序，tomcat 将使用集群机器标记 session ID，例如您的 session 标识符看起来像 9846;node3。虽然这通常不会改变，但当节点 3 关闭并且下一个请求重新平衡到另一个节点时它会改变:9846;node1。
如果您的“登录、执行某些操作、注销”操作始终是半原子操作(例如，立即紧随其后)，则节点 3 在三个请求之间出现故障的可能性可以忽略不计。如果您将 session 保持打开状态一段时间，您可能想要为这样的事件打个招呼。
总结:是否建议忽略 HTTP 规范？不，你最有可能逃脱这样做:你决定。我举了一个它会咬你的例子，可能是 future 几年。你可能会轻易摆脱它。如果您忽略规范，您的实现可能会更容易(维护)。但是错误将更难发现，因为这些问题在将来出现时可能看似随机且很少见，例如调试噩梦。
关于java - 在与 Tomcat Web 服务器的对话期间，我应该检查 JSESSIONID 是否更改？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46685732/