WebRoot 与 WEB-INF 相关问题学习整理

1、为了减少风险，可以把页面文件移到WEB-INF目录下，WEB-INF目录是不对外开放的，外部没办法直接访问到，所有只能通过映射来访问，比如映射为一个action或者Servlet通过服务器端跳转来访问到具体的页面。这样可以限制访问，提高安全性。基于Servlet的声明，WEB-INF不作为Web应用的公共文档树的一部分。WEB-INF是Java的WEB应用的安全目录，所谓安全就是客户端无法访问，只有服务端可以访问的目录。

2、首先，对于外部访问来说，web-inf下的文件都是不可见的（即不能通过url获得web-info下的任何文件），所以，直接访问jsp是不可能的。这要从web-inf文件夹的作用说起：
WEB-INF的存在以及其下的lib和classes目录的作用都是jsp规定的，主要是系统运行的配置信息和环境,用来存储服务端配置文件信息和在服务端运行的类文件，它下面的东西不允许客户端直接访问的，这是jsp环境的规定。
而我们通常是使用view层框架（如struts）来提供jsp服务，此时，我们可以将jsp文件放到web-inf下避免客户直接访问到页面，同时使用struts来进行jsp文件提取，并将编译好的结果发送到客户端。

3、看见个挺有意思的比喻。

就像一条河,本来有一个独木桥,人容易掉下去. 
于是甲不走独木桥(不使用webroot访问jsp),只是在边上造一座安全的桥通行(用服务端转发方式访问jsp). 
乙说有桥为什么不走,造桥多破坏环境呀,他要走独木桥,可是他的做法是先将独木桥踹飞("加一个过滤器阻止所有对*.jsp的访问"),再在原地造一座安全的桥通行(阻止了所有对*.jsp的访问,必然还需要一个服务端转发方式来访问jsp页面) 
既然都不走独木桥为什么要那么麻烦还去理独木桥?直接另造座桥就好了.桥造在原地和造在边上有什么区别.更何况,两者在转发时的区别只不过是转发url中甲比乙多了一个文件夹.入口还不是一样. 
放在webroot下又麻烦(要针对用户直接访问作一些预防动作)又不安全(一些敏感页面),放在web-inf下也不见得打乱了项目文件结构,怕和classes lib弄混,可以在web-inf下创个名为jsp的文件夹专放jsp文件. 
直接用模板框架如freemarker,省了这些个麻烦~

4、

附言：有关路径问题？

关于JAVA EE项目在WEB-INF目录下的jsp页面如何访问WebRoot中的CSS和JS文件

在有Struts部署的Java EE环境中，我们一般把jsp页面写在WebRoot\WEB-INF\content 目录下，这样使得jsp页面一定需要struts的控制转发才可访问，提高页面安全性。

但是今天在jsp页面中应用WebRoot目录中的css，js文件发现十分困难，先看看我的文件结构：

 

目标是在index.jsp中访问default.css。

defautl.css是在index.jsp目录的父目录的父目录的CSS目录下。所以我这样写：

ps:空格为故意添加，不知为何会自动变成博客园的网址

        <link href="../ ../css/default.css" rel="stylesheet" type="text/css"/>        <link href="../ ../css/uploadify.css" rel="stylesheet" type="text/css"/>

在Eclipes中也出现超链接提示，说明目录正确，但是结果失败。

查询资料后，在百度百科中看到：

http://baike.baidu.com/view/1745468.htm

　TomCat 服务器下的WEB-INF文件夹是一个非常安全的文件，在页面中不能直接访问其中的文件，必须通过web.xml文件对要访问的文件进行相应映射才能访问。

从上面的实验可以看出，不但是直接访问，使用" ../ ../ "之类的间接访问也不能成功。

在此多方查询资料之后，尝试使用如下方法访问：

1         <!-- 输出为项目根目录，即WebRoot -->2         <%String path = request.getContextPath(); %>3         <link href="${path}/css/default.css" rel="stylesheet" type="text/css"/>4         <link href="${path}/css/uploadify.css" rel="stylesheet" type="text/css"/>

原理很简单，变量path值为项目根目录，而css就是此目录的子目录，自然可以访问。

可惜结果还是错，思考之，el表达式的${}是以page,request,session,application的顺序寻找匹配的项，而path并不在这个范围之内，也许在java脚本中直接定义的对象是局部作用域，而不是page作用域？可惜百度之后难以找到相关资料，不过结论应该是没错的。

既然EL表达式无法取出，那么java脚本应该可以达到目的吧？尝试如下：

1         <%String path = request.getContextPath(); %>2         <link href="<%=path %>/css/default.css" rel="stylesheet" type="text/css"/>3         <link href="<%=path %>/css/uploadify.css" rel="stylesheet" type="text/css"/>

果不其然，页面成功读出了css文件中的样式，达到目的。不过此页面中存在java脚本，不够规范，查询资料后，用以下纯EL表达式实现：

1         <c:set value="${pageContext.request.contextPath}" var="path" scope="page"/>2         <link href="${path}/css/default.css" rel="stylesheet" type="text/css"/>3         <link href="${path}/css/uploadify.css" rel="stylesheet" type="text/css"/>

先将ContextPath放如page中，再使用el表达式取出，问题得以解决

3、4 引用自：http://iteye.blog.163.com/blog/static/186308096201211204421565/