-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pid,
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0kmocACgkQ9CaO5/Lv0PATdgCePFzM/ez0dhAjKN0FuOY6b1rQ yUUAnjejEA2xbYcWN5A9ymuE1EvSmnOf =Yihv -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
