在与Tomcat Web服务器对话期间，是否应检查JSESSIONID是否更改？

Question

There's a Java code which emulates browser behaviour. It does a stateful conversation with a Tomcat server, for example: login, doSomething, logout.

The current implementation is like this:

1. http post to "login" page, store returned cookie (assume it's JSESSIONID=9845).
2. http post to "doSomething" page, pass stored cookie (JSESSIONID=9845) with the request, do nothing with response headers (ignoring further cookies)
3. http get to "logout" page, pass stored cookie (JSESSIONID=9845) with the request.

This is working fine.

However I do not know if it's safe to ignore response headers in step 2. Should I expect the server changing the value of JSESSIONID during the conversation, or not?

In other words, what to do if in step 2. the server returns Set-Cookie=[JSESSIONID=9846] in the response headers?

I can imagine the followings:

1. this can't happen in real life, not worth to check it, current code is fine.
2. this signals a serious problem with the Tomcat server, worth check it, and the code should stop the conversation without further calls
3. it's legal, the Tomcat server just wants to use a new identifier for the session, so I have to store the new value, and use it with subsequent calls. The current code should be completed.

I guess that real browsers do the 3. option from the above, but maybe 1. and 2. option is also acceptable?

Answer 1

Typically the session changes on login and logout, means that you can expect to be safe largely (but read on, I only said "typically"). You're asking if it's safe to ignore the HTTP spec - and I'd argue that it isn't, as there always can be unexpected changes that make your app hard to maintain or upgrade the infrastructure.

One of those hard to find things will be: If, one day, you start deploying your app on a cluster with sticky sessions, tomcat will tag the session id with the cluster machine, eg your session identifiers will rather look like 9846;node3 . While this still won't change typically, it will when node 3 gets shut down and the next request gets rebalanced to another node: 9846;node1 .

If your "login, do something, logout" operations are always semi-atomic (eg following each other immediately), the probability of node 3 going down in between the three requests is probably negligible. If you keep the session open for a while, you might want to cattter for such an event.

In summary: Is it advisable to ignore the HTTP-spec? No. Will you most likely get away doing so: You decide. I gave one example where it will bite you, probably years ahead. You might get away with it easily. Your implementation will likely be a lot easier (to maintain) if you ignore the spec. But the mistake will be harder to find, as the issues might be seemingly random and rare when they show up in future, eg a debugging nightmare.