Thanks, that is pretty clear and unambiguous, as is "The name of
the parameter must be jsessionid." When the spec is in conflict with itself,
I'm happy to consider Tomcat the reference implementation.
The reason a session cookie name had to be specified in the first place was
because we initially had just this:
<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>
Because we wanted the httpOnly flag. But that broke Weblogic, because Weblogic
interpreted that to mean that we wanted to the session cookie name to be null,
rather than the default, and it started throwing:
java.lang.IllegalArgumentException: Cookie name must not benull or empty
at javax.servlet.http.Cookie.<init>(Cookie.java:172)
atweblogic.servlet.internal.ServletResponseImpl.setSessionCookie(ServletResponseImpl.java:1446)
So we had to specify a cookie name, and thought JSESSIONID was the obvious
choice. Little did we know. And the problem it caused with the desktop app
launching the browser was discovered long enough afterward that it took some
time to figure out the connection.
On Sunday, February 4, 2018, 5:35:04 PM EST, Mark Thomas <ma...@apache.org>
wrote:
No. This is not a bug. See the final paragraph of section 7.1.1
"If a web application configures a custom name for its session tracking
cookies, the same custom name will also be used as the name of the URI
parameter if the session id is encoded in the URL (provided that URL
rewriting has been enabled)."
Specifying a custom name that is the same as the default is an arguable
edge case but I'm going to lean towards the current Tomcat implementation.
Regarding the Javadoc, it probably was a copy and paste and should be
corrected. I'll get that done shortly.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
