You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dave Glasser <dg...@pobox.com> on 2018/02/03 21:55:21 UTC
jsessionid path parameter: Is this compliant with the Servlet 3.0
spec?
This text is based on a stackoverflow question I posted earlier today:
https://stackoverflow.com/questions/48600576/jsessionid-as-path-parameter-not-working-in-tomcat/48602272
I'm using Tomcat 7.0.84, and my web app uses the Servlet 3.0 deployment descriptor. The web.xml file contains this:
<session-config>
<cookie-config>
<name>JSESSIONID</name>
<http-only>false</http-only>
</cookie-config>
<tracking-mode>URL</tracking-mode>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
I have a desktop application that logs into the web app and establishes a session. In response to a user action, it invokes a URL in a browser. Since I want the browser to be logged in with the same session, I append the jsessionid path parameter like this:
http://server/contextroot/path/;jsessionid=8BDF744802E7850D5AA4AB6535163504
I close my browser completely so when the URL is spawned, no previous session cookies will be sent. (My default browser is chrome, and I verify this is the case.)
I also verify in code that the URL tracking mode is enabled, by logging the return value of ServletContext.getEffectiveSessionTrackingModes.
What I'm expecting is the browser request to automatically get the session indicated by the ;jsessionid parameter, but it is not happening. Each time Tomcat includes a new session cookie in its response.
What DOES work, and what I suspect does not comply with the servlet 3.0 spec, is either of these workarounds:
1. In web.xml, change the name of the session cookie from JSESSIONID to jsessionid2. In the URL, change the name of the path parameter from jsessionid to JSESSIONID.
Section 7.1.3 of the Servlet 3.0 spec contains this text:
The session ID must be encoded as a path parameter in the URL string. The name of
the parameter must be jsessionid. Here is an example of a URL containing encoded
path information:
http://www.myserver.com/catalog/index.html;jsessionid=1234
It does not provide at all for configuring a name for the path parameter used to pass in the session ID. It says explicitly, "The name of the parameter must be jsessionid."
But in org/apache/catalina/util/SessionConfig.java, this code is used to get the name of the session parameter:
private static final String DEFAULT_SESSION_PARAMETER_NAME = "jsessionid";
...
/**
* Determine the name to use for the session cookie for the provided
* context.
* @param context
*/
public static String getSessionUriParamName(Context context) {
String result = getConfiguredSessionCookieName(context);
if (result == null) {
result = DEFAULT_SESSION_PARAMETER_NAME;
}
return result;
}
I included the Javadoc because it seems to indicate this method was originally copy/pasted and then modified. The logic is, if there is a name configured for the session cookie, use the same name for the session path parameter, otherwise use jsessionid.
So, can anyone tell me if my suspicion that this is non-compliant (and hence, a bug) correct?
Re: jsessionid path parameter: Is this compliant with the Servlet 3.0
spec?
Posted by Mark Thomas <ma...@apache.org>.
On 05/02/2018 03:18, Dave Glasser wrote:
> 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.
Technically, the RI is glassfish.
This sort of spec inconsistentcy is, I hope, something that the
community will be more easily able to fix once Java EE completes the
move to Eclipse.
> 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)
Whoops. The web-common_3_0.xsd syas that the cookie name is optional.
That is a clear WebLogic bug for spec non-compliance.
> 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.
As I said, the Tomcat behaviour here is arguable. I can see a case for
the path parameter being either JSESSIONID or jsessionid in this case.
My only reason for leaning towards JSESSIONID is maintaining the status
quo. Experience suggests changing this is going to break things for
someone else.
Ultimately, the spec needs to be more explicit here. I'll add this to my
TODO list of things to discuss once the process at Eclipse gets to the
point where we can start updating the spec.
Mark
>
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jsessionid path parameter: Is this compliant with the Servlet
3.0 spec?
Posted by Dave Glasser <dg...@pobox.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jsessionid path parameter: Is this compliant with the Servlet 3.0
spec?
Posted by Mark Thomas <ma...@apache.org>.
On 03/02/18 21:55, Dave Glasser wrote:
> This text is based on a stackoverflow question I posted earlier today:
> https://stackoverflow.com/questions/48600576/jsessionid-as-path-parameter-not-working-in-tomcat/48602272
>
>
> I'm using Tomcat 7.0.84, and my web app uses the Servlet 3.0 deployment descriptor. The web.xml file contains this:
>
> <session-config>
> <cookie-config>
> <name>JSESSIONID</name>
> <http-only>false</http-only>
> </cookie-config>
> <tracking-mode>URL</tracking-mode>
> <tracking-mode>COOKIE</tracking-mode>
> </session-config>
>
> I have a desktop application that logs into the web app and establishes a session. In response to a user action, it invokes a URL in a browser. Since I want the browser to be logged in with the same session, I append the jsessionid path parameter like this:
>
> http://server/contextroot/path/;jsessionid=8BDF744802E7850D5AA4AB6535163504
>
> I close my browser completely so when the URL is spawned, no previous session cookies will be sent. (My default browser is chrome, and I verify this is the case.)
>
> I also verify in code that the URL tracking mode is enabled, by logging the return value of ServletContext.getEffectiveSessionTrackingModes.
>
> What I'm expecting is the browser request to automatically get the session indicated by the ;jsessionid parameter, but it is not happening. Each time Tomcat includes a new session cookie in its response.
> What DOES work, and what I suspect does not comply with the servlet 3.0 spec, is either of these workarounds:
> 1. In web.xml, change the name of the session cookie from JSESSIONID to jsessionid2. In the URL, change the name of the path parameter from jsessionid to JSESSIONID.
>
> Section 7.1.3 of the Servlet 3.0 spec contains this text:
> The session ID must be encoded as a path parameter in the URL string. The name of
> the parameter must be jsessionid. Here is an example of a URL containing encoded
> path information:
>
> http://www.myserver.com/catalog/index.html;jsessionid=1234
>
> It does not provide at all for configuring a name for the path parameter used to pass in the session ID. It says explicitly, "The name of the parameter must be jsessionid."
> But in org/apache/catalina/util/SessionConfig.java, this code is used to get the name of the session parameter:
> private static final String DEFAULT_SESSION_PARAMETER_NAME = "jsessionid";
> ...
>
> /**
> * Determine the name to use for the session cookie for the provided
> * context.
> * @param context
> */
> public static String getSessionUriParamName(Context context) {
>
> String result = getConfiguredSessionCookieName(context);
>
> if (result == null) {
> result = DEFAULT_SESSION_PARAMETER_NAME;
> }
>
> return result;
> }
>
>
> I included the Javadoc because it seems to indicate this method was originally copy/pasted and then modified. The logic is, if there is a name configured for the session cookie, use the same name for the session path parameter, otherwise use jsessionid.
>
> So, can anyone tell me if my suspicion that this is non-compliant (and hence, a bug) correct?
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org