tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [OT] WEB-INF
Date Fri, 12 Jul 2013 13:36:03 GMT
Hash: SHA256


On 7/11/13 11:36 AM, André Warnier wrote:
> Leo Donahue - RDSA IT wrote:
>>> -----Original Message----- From: Tim Funk
>>> [] Subject: Re: [OT] WEB-INF
>>> Its a best practice to keep your jsp's inside of WEB-INF.
>>> Since WEB-INF/ is not allowed to be requested by the browser -
>>> its a simple enforcement mechanism to prevent users from direct
>>> access to calling jsps.
>> Thanks Tim.  A lot of old reference books on servlets/JSP never
>> really touched on this topic, and I've read about placing
>> resources in WEB-INF on the web somewhere since then.  I was
>> curious if this practice was originally by design or if the
>> benefit was realized after the servlet spec - such as someone
>> deciding "hey, we should put stuff in WEB-INF".
>>> (Since it may be  common to have jsp's as snippets for header
>>> / footers etc -- and there for they might be able to be called
>>> in surprising ways and exposing funny attacks)
>> You mention header/footers, which was in the back of my mind when
>> I posted this.  Placing headers/footers in WEB-INF doesn't allow
>> me to re-use these in different webapps, without having multiple
>> copies of these? If I have a header/footer template in 
>> \webapps\ROOT\WEB-INF\templates\, I can't reference it from 
>> \webapps\App2\WEB-INF\templates  ... or can I?
> There are 2 schools of thought here. One says that webapps should
> be independent of one another. On that base, you /should/ duplicate
> these headers/footers for each webapp, so that they can still be
> individually modified/redeployed. And one could argue that they are
> probably not so big (bytewise), so the additional space required
> should not be a real inconvenient. The other school of thought
> would argue that have multiple redundant copies of something is
> bad, because it can lead to diverging versions etc. (And the first
> school of thought would then come back with a vengeance, saying
> that this is an issue which your deployment process should take 
> care of).

For the record, I personally am an instructor at this particular
School of Thought (solve duplication issues with deployment processes).

Here's why: your web application(s) will become overly complicated and
fragile if you try to share resources between webapps. Fragility is
IMO more expensive than the maintenance cost of a more complicated build.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message