> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, January 05, 2011 10:21 AM > To: Tomcat Users List > Subject: Re: httpd/Tomcat load balancing question > > -----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
So Chris - If you read some more of the thread, you'll see that in the original config from dev, none of the files were protected, had I deployed as standalone Tomcat (or just lb-passthrough of everything). Any file could be served directly to the browser just by fronting the URL as hostname.com/Portal/static/.... This meant any file from WEB-INF or META-INF or any other directory under the original exploded directory. The httpd front-end was actually provided a little more security than provided by default. As PID points out, in my case, we don't particularly care if the intended static resources were protected (images, scripts, and stylesheets) as they were items that had to sent to clients anyway. The original intent of having httpd serve these files was to lower the httpd<->tomcat traffic load. Why increase the internal traffic load unnecessarily? Had these items really needed the protection, I suppose the only way to do so would be to pass the requests onto Tomcat, correct? BTW: While I was out on Xmas break, the dev team did implement some additional security so that the WEB-INF & META-INF directories are protected again. It "feels" weird, but appears to work. Jeff __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
