共计 1067 个字符，预计需要花费 3 分钟才能阅读完成。
swoft2.0.x 官网文档介绍的跨域解决 demo 如下:
这中形式在失常申请下看似没有问题, 但如果 $handler->handle($request)
步骤产生了异样, 比方 Validator 拦挡到申请参数不非法, 抛出了 ValidatorException, 那么后续增加申请头的操作就无奈失去执行.
那么, 可不可以在执行 handle 办法前先通过 Context::get()->getResponse()
取得 Response 对象, 而后先对 Response 对象进行 header 设置呢?
答案是:NO, 因为 HttpContext 没有提供 response 属性的 setter, 想要输入批改后的 Response 只能在框架提供的各个环节中 return 给调用者.
再看 swoft 源码 Swoft\Http\Server\HttpDispatcher:
不难发现:
1.`$requestHandler->handle($request)` 这一步如果产生异样, 那么咱们天然也得不到对应的 `$response`.
2. 产生异样后, 零碎会通过 `$errDispatcher = Swoft::getSingleton(HttpErrorDispatcher::class)` 失去错误处理的调度者, 最初通过错误处理调度者返回一个 Response
联合源码, 最终的解决思路有 4 个:
1. 在每个中间件执行 $handler->handle($request)步骤时加上 try/catch, 捕捉执行中的异样, 而后获取 Response, 设置好跨域后, 失常 return.
2. 利用 swoft 的 HttpErrorDispatcher, 在对应的异样解决类外面设置跨域的申请头(对于如何设置异样解决, 请参见 swoft 官网文档).
3. 跳出在 php 中设置跨域申请 header 的思路, 在比方 nginx 等代理服务器设置 header.
4. 批改源码, 在如下机会退出 header 设置, 此处的 $this->configResponse($response)办法为自定义的 header 设置办法:
以上 4 中办法:
前 2 中办法须要在注册的每一个中间件或者错误处理回调类外面增加 header 设置, 比拟繁琐. 最多是加个 Common 类来对立解决, 但其它类依然须要继承这个 Common 类.
第 3 种形式无需动 php 任何代码, 举荐生产环境应用. 然而在本地开发时须要 Nginx 等服务作为代理, 略显繁琐.
第 4 种形式, 益处是只需动一处代码, 就能作用全局. 害处也很显著: 动的那一处是框架提供的源码. 倡议测试环境应用.
总结:
测试环境第 4 种, 生产环境第 3 种.
正文完
