SpringBoot出现Whitelabel Error Page的本质原因和三种解决方案
yuyutoo 2024-10-12 00:32 1 浏览 0 评论
0、简述
在学习这个学习笔记之前最好能够对spring mvc以及Tomcat有些了解,这样理解起来更加方便,如果需要知道最直接的解决方案,拖到最底部看样例代码即可。
介绍了springboot的白页出现的真正原因,主要是没有合适的匹配情况出现404情况,然后跳转到系统默认的第一个ErrorPage,也就是白页内容上,然后根据其特定分别从三个角度,1、拦截器,2、新ErrorPage,3、自定义/error路由 去解决该问题,并且介绍各自方法的优缺点,其中还有介绍到循环页面错误的本质原因等情况
1、Whitelabel Error Page 白页
什么叫Whitelabel Error Page(也叫白页),就是SpringBoot中HTTP请求出现异常的说明页,如下图
白页内容会展示状态码、path、以及错误原因等情况,但是真正发布在线上生成环境一般不允许出现这样的情况,更多的是自定义的404页面或者500页面等。
那么现在我们就来了解下什么情况会产生白页的情况,以及如何解决这种情况。我们就以404的情况去了解其原因。
直接来到DispatcherServlet类的protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception方法,其中包含的代码片段
mappedHandler = getHandler(processedRequest); // 找到合适的请求处理器 if (mappedHandler == null || mappedHandler.getHandler() == null) { // 原则上如果没有找到则会进入到这里,并且设置response的状态码为404 // 但是经过调试并没有进入到这里 noHandlerFound(processedRequest, response); return; }
在getHandler方法中会遍历当前web容器中的HandlerMapping,找出合适的处理器Handler
由上图可以很明显的知道便利出的当前Handler是SimpleUrlHandlerMapping,因为其中的url中包含了/**,所有的url都可以被匹配出,不会进入到后面的noHandlerFound中,适配处理器HandlerAdapter是HttpRequestHandlerAdapter实例化的对象
在mv = ha.handle(processedRequest, response, mappedHandler.getHandler())中没法找到对应的resource,设置response的状态码为404,具体可看ResourceHttpRequestHandler类的handleRequest方法
现在就相当于该请求设置了状态码为404,其他并没有做什么,mv也是为null的
这时候需要回到Tomcat的调用流程内,如果对Tomcat的调用流程请求的同学应该知道,Tomcat在连接器收到Socket套接字请求包装成为request、response等信息交由Engine->Host 等组件一层一层传递,再由各个组件的Pipeline管道接收,后续各自的Valve(阀门)一层一层的过滤处理。
这个时候来到StandardHostValve类的private void status(Request request, Response response)方法
private void status(Request request, Response response) { int statusCode = response.getStatus(); // 查看当前状态码,当前样例是404 // 获取当前上下文 Context context = request.getContext(); if (context == null) { return; } if (!response.isError()) { // 当前请求没错误 // 是一个原子类AtomicInteger errorState,如果大于0则认为遇到错误 return; } ErrorPage errorPage = context.findErrorPage(statusCode); // 这个地方以后再说,就是解决方案的一种,设置错误页 if (errorPage == null) { // Look for a default error page errorPage = context.findErrorPage(0); } if (errorPage != null && response.isErrorReportRequired()) { ...
结合代码和图,再看白页清楚的写着This application has no explicit mapping for /error,路由为\error,这个缘由就是来自这里,然后进行forward跳转,路由地址是\error
后面使用了SpringBoot提供的白页mv,渲染生产我们所看到的白页页面内容
至此,整个的流程也已经执行完成,总结一下就是请求一个不存在的链接,被发现是404请求之后转发到/error的请求上
那么解决方案就很简单了,有三种方案,不过这三种方案均是从不同的角度去解决该问题
- 添加拦截器
- 添加ErrorPage
- 添加/error 路径
2、解决白页问题
2.1、添加拦截器
public class CustomHandlerInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 一定得为true,否则拦截器就无法生效了 // 当然可以随意各种对url的拦截处理 return true; } @Override public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception { if (modelAndView != null) { // 防止出现空指针 // 在springboot中如果是错误页肯定不会出现mv为null的情况 modelAndView.setViewName("/err"); // 注意:该请求只是测试试用,并没有实际的意义 } } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { } } @Bean public WebMvcConfigurerAdapter customMvcConfigurerAdapter (){ return new WebMvcConfigurerAdapter() { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new CustomHandlerInterceptor()).addPathPatterns("/**"); // 添加拦截器 super.addInterceptors(registry); } }; }
拦截器在捕获到/error 的请求之后,强制修改mv,使得最后渲染试用的mv是我们自定义设置的,而不是白页内容,其中白页本身的mv会经过ContentNegotiating视图解析器处理成为ErrorMvcAutoConfiguration$WhitelabelErrorViewConfiguration
注意这整个过期其实经过3次HTTP请求处理的,如下图是使用HTTP事件监听打印出的日志信息
经历了/abc==>跳转/err==>跳转/error(并不显示该内容,因为发送到浏览器的内容已经经过/err 渲染完成
其中真正的调用处理流程是/abc 没有发现合适的handler,后选择交由/error 路径处理,只是后面又被拦截器拦截处理,转发给了/err 处理
缺点:会拦截该路由的所有请求,包含静态资源文件,对纯提供接口的后端服务没太多影响,其他的服务会有影响的
2.2、添加ErrorPage
添加合适的ErrorPage就不会出现跳转到拦截器默认的/error 路径,而是跳转到自定义的ErrorPage上,这点在上面的status方法已经介绍其原因了
@Bean public EmbeddedServletContainerCustomizer containerCustomizer() { return new EmbeddedServletContainerCustomizer() { @Override public void customize(ConfigurableEmbeddedServletContainer configurableEmbeddedServletContainer) { ErrorPage errorPage400 = new ErrorPage(HttpStatus.BAD_REQUEST,"/400"); ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND,"/404"); ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR,"/500"); configurableEmbeddedServletContainer.addErrorPages(errorPage400,errorPage404,errorPage500); } }; } // ======= 分割线 @ApiOperation("404请求") @GetMapping("404") public String e404() { return "404"; }
上述代码添加了几个错误页ErrorPage跳转的路径以及其对应的HTTP错误码,我们当前的样例肯定是跳转到/404连接上去了,再执行怎么又报错了,原则上来说应该显示404.html的内容文件,同时显示的是经典的Tomcat错误页了,如下图页面展示以及日志输出的内容
这个就是循环跳转的问题
当系统没有指定明确的视图解析器之后,系统便会使用自带的默认解析器InternalResourceView,在渲染前会去校验当前url的问题,如果发现请求的url和目的url是一致的情况,就会认定转发自身,出现Circular view path的问题
protected String prepareForRendering(HttpServletRequest request, HttpServletResponse response) throws Exception { String path = getUrl(); if (this.preventDispatchLoop) { String uri = request.getRequestURI(); if (path.startsWith("/") ? uri.equals(path) : uri.equals(StringUtils.applyRelativePath(uri, path))) { throw new ServletException("Circular view path [" + path + "]: would dispatch back " + "to the current handler URL [" + uri + "] again. Check your ViewResolver setup! " + "(Hint: This may be the result of an unspecified view, due to default view name generation.)"); } } return path; }
那么如何解决呢,肯定得从根本目的出发
- 添加模板解析器,这样就不会使用默认解析器了
- 修改跳转路径
具体的解决方案就自行了解,本文不使用模板引擎渲染,直接展示body数据
@RequestMapping("/") @RestController public class ErrorController { @ApiOperation("404请求") @GetMapping("404") public String e404() { System.out.println("404............"); return "这真的是一个404页面,你看看"; }
2.3、添加/error 路径
上面已经知道了,既然默认的系统跳页至/error,并且会完成数据渲染,那么我们自定义个/error的路由不就可以了,而且避免了静态资源找不到的问题,不过注意这里存在一个问题,具体看下图
先自行添加定义了一个很简单的/error路径的处理方法,但是在springboot启动时,共有3个/error路径的处理器方法,而且同时隶属于同一个handle中,恰好经过URL路由规则处理,选择了autoconfigure里面的handle,这肯定导致了我们自定义的/error 无效
经过测试也确实无效,依旧显示白页,那么如何解决呢?同样的方法有多种
- 根据路由匹配规则,修改适当内容,使得最后选择处理器的时候达到我们自定义的处理器上,不过这点难度很大吧,需要对spring mvc 本身的路由映射规则了解的相当清楚,确保url映射处理的优先级问题等
- 上述我们已经知道了这三个/error是在RequestMappingHandlerMapping路由映射器中,我们可以使得自定义的处理器不存放在该路由映射其中,并且使得spring在轮询时,优先处理约定的路由映射器即可,可是事实上handlerMapping中的BeanNameUrlMapping还在RequestMappingHandlerMapping之后,如果再去修改这个顺序,同样难度很大
EndpointHandlerMapping 是springboot的actuator模块中的端点,自定义端点难度较大而且不适用在当前项目中
使用SimpleUrlHandlerMapping针对在springboot中不太合适,如果使用xml配置可直接设置其url会很方便的,如果强加在springboot中使用注解的方式需要额外配置,如下代码
@RequestMapping("/") @Controller public class SimpleUrlController { private static final String ERROR_PATH = "/error"; @Resource private SimpleUrlHandlerMapping simpleUrlHandlerMapping; @PostConstruct public void init() { Map<String, Object> map = new HashMap<>(); map.put(ERROR_PATH, this); simpleUrlHandlerMapping.setUrlMap(map); simpleUrlHandlerMapping.initApplicationContext(); // 重新调用simpleurl映射 } @GetMapping("/error") @ResponseBody public String error(HttpServletRequest request) { System.out.println("SimpleUrlController"); Enumeration<String> attributes = request.getAttributeNames(); Map<String, Object> map = new HashMap<String, Object>(); while (attributes.hasMoreElements()) { String name = attributes.nextElement(); if (name.startsWith("java")) { // spring本身的属性不宜对外暴露,切记! Object value = request.getAttribute(name); map.put(name, value); } } return JSON.toJSONString(map); } }
虽然完成了/error 注入到SimpleUrlHandlerMapping中,可是即使添加了额外的配置依旧会出现无适配器的错误,这种方法并不适用
回过头通过对BasicErrorController的观察,我们可以自行继承ErrorController接口完成
@RequestMapping("") @Controller public class CustomErrorController implements ErrorController { private static final String ERROR_PATH = "/error"; @GetMapping(ERROR_PATH) @ResponseBody public String error(HttpServletRequest request) { System.out.println("CustomErrorController"); Enumeration<String> attributes = request.getAttributeNames(); Map<String, Object> map = new HashMap<String, Object>(); while (attributes.hasMoreElements()) { String name = attributes.nextElement(); if (name.startsWith("java")) { // spring本身的属性不宜对外暴露,切记! Object value = request.getAttribute(name); map.put(name, value); } } return JSON.toJSONString(map); } @Override public String getErrorPath() { return ERROR_PATH; } }
到这里整个的过程就算是完成了。整体上来说还是根据spring mvc的执行过程来分析解决问题的。
相关推荐
- MySQL5.5+配置主从同步并结合ThinkPHP5设置分布式数据库
-
前言:本文章是在同处局域网内的两台windows电脑,且MySQL是5.5以上版本下进行的一主多从同步配置,并且使用的是集成环境工具PHPStudy为例。最后就是ThinkPHP5的分布式的连接,读写...
- thinkphp5多语言怎么切换(thinkphp5.1视频教程)
-
thinkphp5多语言进行切换的步骤:第一步,在配置文件中开启多语言配置。第二步,创建多语言目录。相关推荐:《ThinkPHP教程》第三步,编写语言包。视图代码:控制器代码:效果如下:以上就是thi...
- 基于 ThinkPHP5 + Bootstrap 的后台开发框架 FastAdmin
-
FastAdmin是一款基于ThinkPHP5+Bootstrap的极速后台开发框架。主要特性基于Auth验证的权限管理系统支持无限级父子级权限继承,父级的管理员可任意增删改子级管理员及权限设置支持单...
- Thinkphp5.0 框架实现控制器向视图view赋值及视图view取值操作示
-
本文实例讲述了Thinkphp5.0框架实现控制器向视图view赋值及视图view取值操作。分享给大家供大家参考,具体如下:Thinkphp5.0控制器向视图view的赋值方式一(使用fetch()方...
- thinkphp5实现简单评论回复功能(php评论回复功能源码下载)
-
由于之前写评论回复都是使用第三方插件:畅言所以也就没什么动手,现在证号在开发一个小的项目,所以就自己动手写评论回复,没写过还真不知道评论回复功能听着简单,但仔细研究起来却无法自拔,由于用户量少,所以...
- ThinkPHP框架——实现定时任务,定时更新、清理数据
-
大家好,我是小蜗牛,今天给大家分享一下,如何用ThinkPHP5.1.*版本实现定时任务,例如凌晨12点更新数据、每隔10秒检测过期会员、每隔几分钟发送请求保证ip的活性等本次分享,主要用到一个名为E...
- BeyongCms系统基于ThinkPHP5.1框架的轻量级内容管理系统
-
BeyongCms内容管理系统(简称BeyongCms)BeyongCms系统基于ThinkPHP5.1框架的轻量级内容管理系统,适用于企业Cms,个人站长等,针对移动App、小程序优化;提供完善简...
- YimaoAdminv3企业建站系统,使用 thinkphp5.1.27 + mysql 开发
-
介绍YimaoAdminv3.0.0企业建站系统,使用thinkphp5.1.27+mysql开发。php要求5.6以上版本,推荐使用5.6,7.0,7.1,扩展(curl,...
- ThinkAdmin-V5开发笔记(thinkpad做开发)
-
前言为了快速开发一款小程序管理后台,在众多的php开源后台中,最终选择了基于thinkphp5的,轻量级的thinkadmin系统,进行二次开发。该系统支持php7。文档地址ThinkAdmin-V5...
- thinkphp5.0.9预处理导致的sql注入复现与详细分析
-
复现先搭建thinkphp5.0.9环境...
- thinkphp5出现500错误怎么办(thinkphp页面错误)
-
thinkphp5出现500错误,如下图所示:相关推荐:《ThinkPHP教程》require():open_basedirrestrictionineffect.File(/home/ww...
- Thinkphp5.0极速搭建restful风格接口层
-
下面是基于ThinkPHPV5.0RC4框架,以restful风格完成的新闻查询(get)、新闻增加(post)、新闻修改(put)、新闻删除(delete)等server接口层。1、下载Thin...
- 基于ThinkPHP5.1.34 LTS开发的快速开发框架DolphinPHP
-
DophinPHP(海豚PHP)是一个基于ThinkPHP5.1.34LTS开发的一套开源PHP快速开发框架,DophinPHP秉承极简、极速、极致的开发理念,为开发集成了基于数据-角色的权限管理机...
- ThinkPHP5.*远程代码执行高危漏洞手工与升级修复解决方法
-
漏洞描述由于ThinkPHP5框架对控制器名没有进行足够的安全检测,导致在没有开启强制路由的情况下,黑客构造特定的请求,可直接GetWebShell。漏洞评级严重影响版本ThinkPHP5.0系列...
- Thinkphp5代码执行学习(thinkphp 教程)
-
Thinkphp5代码执行学习缓存类RCE版本5.0.0<=ThinkPHP5<=5.0.10Tp框架搭建环境搭建测试payload...
你 发表评论:
欢迎- 一周热门
- 最近发表
-
- MySQL5.5+配置主从同步并结合ThinkPHP5设置分布式数据库
- thinkphp5多语言怎么切换(thinkphp5.1视频教程)
- 基于 ThinkPHP5 + Bootstrap 的后台开发框架 FastAdmin
- Thinkphp5.0 框架实现控制器向视图view赋值及视图view取值操作示
- thinkphp5实现简单评论回复功能(php评论回复功能源码下载)
- ThinkPHP框架——实现定时任务,定时更新、清理数据
- BeyongCms系统基于ThinkPHP5.1框架的轻量级内容管理系统
- YimaoAdminv3企业建站系统,使用 thinkphp5.1.27 + mysql 开发
- ThinkAdmin-V5开发笔记(thinkpad做开发)
- thinkphp5.0.9预处理导致的sql注入复现与详细分析
- 标签列表
-
- mybatis plus (70)
- scheduledtask (71)
- css滚动条 (60)
- java学生成绩管理系统 (59)
- 结构体数组 (69)
- databasemetadata (64)
- javastatic (68)
- jsp实用教程 (53)
- fontawesome (57)
- widget开发 (57)
- vb net教程 (62)
- hibernate 教程 (63)
- case语句 (57)
- svn连接 (74)
- directoryindex (69)
- session timeout (58)
- textbox换行 (67)
- extension_dir (64)
- linearlayout (58)
- vba高级教程 (75)
- iframe用法 (58)
- sqlparameter (59)
- trim函数 (59)
- flex布局 (63)
- contextloaderlistener (56)