-
过滤器链： （a）过滤的顺序：作用于同一个web资源的过滤器，触发的顺序依赖于它们在“web.xml”中“<filter-mapping/>”的配置顺序； （b）实例化的顺序：与过滤的顺序恰好相反，先实例化后面的过滤器，然后再实例化前面的过滤器。这样可以保证当前面的过滤器触发时，后续的过滤器都是准备好了的； （c）销毁的顺序：与实例化的顺序相同，理解中……。查看全部
-
过滤器链执行过程查看全部
-
web.xml配置查看全部
-
过滤器可以根据用户请求的内容决定将请求转发到哪个web资源，但是不可以直接发回响应，因为过滤器毕竟只是过滤器，生成响应不是它的工作范围~！查看全部
-
过滤器的生命周期： （a）实例化--服务器启动时，读取应用配置文件“web.xml”中的相关配置； （b）初始化--实例化完成之后，执行“init()”方法进行初始化设置； （c）活动--初始化完成之后，执行“doFilter()”方法过滤交互数据； （d）销魂--服务器关闭时，执行“destory()”方法销毁； 注意：以上各阶段，除了活动阶段会执行若干次，其他阶段只会执行一次。查看全部
-
过滤器： （a）运行于服务端，是一个服务端组件； （b）截取和过滤客户端与服务端的交互数据，包括客户端的请求与服务端的响应；查看全部
-
过滤器的分类： request：用户直接访问页面时，web容器将会调用过滤器。 forward：目标资源是通过requestDispatcher的forward访问时，该过滤器将被调用查看全部
-
过滤器生命周期： 实例化（web.xml）---初始化（调用init（）方法）------过滤（执行doFilter（）方法） -----销毁（执行destroy（）方法）查看全部
-
过滤器工作原理： 用户请求--------过滤器---------------------------------web资源查看全部
-
过滤器是一个服务器端的组件，它可以截取用户端的请求与响应信息，并对这些信息过滤查看全部
-
过滤器分类查看全部
-
为什么sendRedirect会陷入死循环，而getRequestDispatcher.forward不会。 因为前者是使用的过滤器类型是request，访问index.jsp页面时，触发过滤器，重定向到main.jsp，由于过滤器类型是request，所以会继续触发main.jsp的过滤器，所以会陷入死循环。 后者在访问index.jsp的时候，过滤器类型是request，所以会触发过滤器，然后利用转发的方式访问main.jsp，这时候过滤器的类型是forward，而此时web.xml中定义的匹配main的过滤器类型还是request，所以不执行main所匹配的过滤器，因此只执行一次。查看全部
-
filter过滤器的init、dofilter、destroy方式查看全部
-
web.xml对过滤器的配置查看全部
-
filter过滤器的init方法查看全部
举报
0/150
提交
取消