Re: jsessionid path parameter: Is this compliant with the Servlet 3.0 spec?

[Dave Glasser]

 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:

  
    true
  


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.(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  
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

  

jsessionid path parameter: Is this compliant with the Servlet 3.0 spec?

[Dave Glasser]

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:


  
    JSESSIONID
    false
  
  URL
  COOKIE


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: OT: Re: Order of attributes significant in zipfileset?

[Dave Glasser]

Good to know! Thanks George!


  From: George Sexton 
 To: Tomcat Users List  
 Sent: Tuesday, April 26, 2016 4:06 PM
 Subject: OT: Re: Order of attributes significant in zipfileset?
   
This isn't as bad as the delete task.

If you specify dir and file, it will delete everything in dir, not just 
file.


   

Re: Order of attributes significant in zipfileset?

[Dave Glasser]

  From: "Caldarale, Charles R" <chuck.caldar...@unisys.com>
 To: Tomcat Users List <users@tomcat.apache.org>; Dave Glasser 
<dglas...@pobox.com> 
 Sent: Tuesday, April 26, 2016 2:32 PM
 Subject: RE: Order of attributes significant in zipfileset?
   
>> From: Dave Glasser [mailto:dglas...@pobox.com]
>> Subject: Order of attributes significant in zipfileset?
>
>> If you have a  element with both a dir and a file attribute, it 
>> will produce
>> different results depending on the order in which those attributes appear.
>
>Not surprising.

Really? Not surprising at all? I've never encountered a piece of software where 
the order of attributes on an input XML document mattered. AFAICT, you can't 
enforce the order of attribute names through a DTD or schema. Even W3C says 
"Notethat the order of attribute specifications in a start-tag or 
empty-elementtag is not significant." So, to me, it's quite surprising to 
encounter a situation where the order of attributes makes such a dramatic (but 
non-obvious) difference.

>> I want to make clear that I'm aware that the docs for fileset say:
>> "Either dir or file must be specified" and that I might be doing it wrong. 
>> You could argue
>> otherwise, but perhaps that does in fact unambiguously imply that having 
>> both is incorrect
>> and hence the behavior is undefined.
>
>
>Yes, it's undefined.  The file attribute is documented as a "shortcut for 
>specifying a single-file fileset" - you should not use both dir and file.  If 
>you want a single file in a particular directory, use just the file attribute:
>
>
Yep, that's pretty much what I figured. Or just use the includes attribute 
instead of file. That seems to work the way you'd expect it to, and the 
documentation is clear and unambiguous. I was just hoping maybe someone had 
some deeper information on this beyond an interpretation of the documents.


  

Order of attributes significant in zipfileset?

[Dave Glasser]

I discovered this in ant 1.6.5, and found that it still behaves this way in 
1.9.7.
If you have a  element with both a dir and a file attribute, it 
will produce different results depending on the order in which those attributes 
appear. If the file attribute appears first, it behaves as you would expect. 
For example, with this:

It looks for a file named "file1.txt" inside the directory "dir1". However, 
with this:

It looks for file1.txt inside the current working directory. This can be 
verified by running the demonstration target I provide below with the -debug 
switch, and reading the debug output.
I want to make clear that I'm aware that the docs for fileset say:
"Either dir or file must be specified" and that I might be doing it wrong. You 
could argue otherwise, but perhaps that does in fact unambiguously imply that 
having both is incorrect and hence the behavior is undefined. Be that as it 
may, what I would like to know is this:
Is this a known, and expected behavior?  Is it documented anywhere?
Should I assume that the order of attributes is significant in other places 
throughout my build.xml file?
Here's a self-contained target that demonstrates this behavior:
  
    

    
    
    
    
    

    
    

    
    
  
    

    
  
    

    
    

    
  
  
    

    
  

  
  
    

    Contents of ${ZIP1}:
    
  
  
    

    Contents of ${ZIP2}: