情景描述
- 使用postman请求后端服务器
http://localhost:8085/api/users/1可以顺利拿到response - 使用zuul做route
server.port=8888
UserCenter:
path: /user-center/**
url: http://localhost:8085
- 使用route filter
- 请求
https://localhost:8888/user-center/api/users/1 - 报错：404
- 但是将filter的类型修改成pre，就一直可以通过
矛盾点
- 正常情况下不论任何时候只要请求
http://localhost:8085/api/users/1可以拿到response，那么https://localhost:8888/user-center/api/users/1永远可以收到正确的response，为什么针对route filter会出现有时候可以拿到，有时候不行？
问题解决
Q1：zuul pre filter的执行时机
-
A1:pre filter的run方法会在route之前执行。
- 请求首先会进入filter的run方法，处理完毕之后继续将请求发送给route部分。
- 如果filter中对请求相关信息没有改动，那么就会按照原来的request原来的url进行route。
---> 因此上面的例子，只要filter换成pre就可以正常的获取response。
Q2: route filter 导致请求404，是route filter本身的运行机制导致的，还是filter中的内容导致的呢？
A2: 我们将filter的内容全部清空，只留下
return null发现请求获得了正确的response。由此可知。请求的路径并没有出现任何问题，仅仅是filter中的处理导致了url改变，请求404.Q3:那么filter里面执行了什么会出现，修改了url呢？
A3:经过处理发现由于执行了
RequestContext.getCurrentContext().set("requestURI", uri);导致请求出现了404。此时即使我set的requestURI和原来的完全一致，也会导致404.
----> 此时的现象就是：只要在route filter中对request做任何set都会导致请求404.Q4:那么为什么set request中的数据，就会导致url出现问题呢？
A4:我尝试修改服务器的路径使得请求
http://localhost:8085/user-center/api/users/1即可以拿到资源。然后再次发送请求https://localhost:8888/user-center/api/users/1发现资源拿到了。这样看来，明显就是：本来route可以去除请求前缀/user-center但是set reuqest之后把user-center前缀又加回来，导致最终到达服务器的路径中多了user-center前缀。
---- 但是 这个route filter的先后顺序仍然不得而知，如果想要彻底弄明白这个route filter可能要读一读源码了。
反思
- 对于一些新的知识，网上的相关文档真的有限，所以这时候应该尝试去看一看源代码才能解决心理的疑惑，可能是这么久以来太依赖文档，就算文档没有，也有Stack Overflow总有人能通过他的描述告诉问题答案。当什么都没有的时候，就只能靠猜测，其实要是有时间和精力真的应该去读一下。
