tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: httpd/Tomcat load balancing question
Date Wed, 05 Jan 2011 16:21:27 GMT
Hash: SHA1


Late to the thread. :(

On 12/23/2010 5:37 AM, Pid wrote:
> On 23/12/2010 07:49, André Warnier wrote:
>> So in clear everyday English, for the benefit of the oppressed minority
>> who does not speak JSTL fluently, the fact of encoding this link in the
>> page as "<c:url something..>" is the reason why Tomcat (roughly
>> speaking) modifies it to add the ";jessionid" bit, yes ?

Exactly: <c:url> runs the argument through
HttpServletResponse.encodeURL() which adds ";jsessionid" if the request
didn't include a JSESSIONID cookie. This allows cookie-less session
management and is part of the servlet spec.

All URLs should be given this treatment in order for apps to work.

>> And if one were to remove the "<c:url .." tag from those links, it
>> wouldn't, right ?
>> And if so, why did you say "Fail" above ?
> I was referring to the "Definitely the culprit." statement.
> Fail because encoding the links to static resources is unnecessary.

I disagree: using <c:url> will also add the webapp's context path to the
beginning of the URL, making it trivially relocatable. You're right,
though, the addition of ";jsessionid" to static resources is likely to
only confuse things (as they did in this situation).

On the other hand, without the session identification being sent to
Tomcat, access controls can't properly be maintained for static content.
Just because it's static doesn't mean it's not sensitive.

>> As long as we're at it, are there any dire consequences in this case for
>> removing the "<c:url .." bit ?
> For static resources?  No.  In this case, only gain.

I see some opportunities for loss: see above.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message