重定向死亡-CSDN博客

据说最大的伤害可能来自最好的意图。最近，我们有一个案例，出于最佳意图，两个@＃@＆* @ !! ^ @参与者用一个请求杀死了我们的服务器，从而导致涉及我们所有Tomcat实例（包括所有HTTP线程）的死锁。自然，让自己陷入困境并不是一种愉快的情况。
这里需要有关我们的设置的一些说明。我们有许多Tomcat实例，它们为无状态负载均衡器后面的网站提供HTML页面。然后是时候添加我们第二个部署在Jetty上的应用程序了。由于我们需要将新应用程序作为同一网站的一部分提供服务（例如，http：//www.wix.com/jetty-app），因此我们从Tomcat代理了第二个（Jetty）应用程序（不要深入了解为什么我们由Tomcat代理Jetty，我们当时认为我们有充分的理由），因此实际上我们具有以下架构：

在Tomcat端，我们使用Apache HttpClient库连接到Jetty应用程序。默认情况下，HttpClient配置为遵循重定向。最佳意图＃1：为什么我们要求开发人员考虑重定向？让我们自动为她处理...

在Jetty端，我们有一个通用的错误处理程序，在发生错误时，它不会显示错误页面，而是将用户重定向到Jetty上应用程序的主页。最佳意图2：为什么要向用户显示错误页面？让我们将他重定向到我们的主页…

但是，当Jetty应用程序的主页生成错误时会发生什么？好吧，显然它返回了一个重定向指令给自己！现在，如果浏览器将获得该重定向，它将进入一个重定向循环并在大约20次重定向后中断它。我们将看到20个请求全部导致重定向，可能会看到流量激增，但没有别的。

但是，由于在HttpClient库中启用了重定向，因此发生了以下情况：

一个请求到达我们的Tomcat服务器，该服务器将其解析为代理到Jetty应用程序
Tomcat线程＃1代理对Jetty的请求
码头发生异常，并返回到http://www.wix.com/jetty -app的重定向
Tomcat线程1连接到www.wix.com主机，该主机通过负载平衡器到达另一个Tomcat线程– Tomcat线程2
Tomcat线程2代理对Jetty的请求
码头发生异常，并返回到http://www.wix.com/jetty的重定向
Tomcat线程1连接到www.wix.com主机，该主机通过负载平衡器到达另一个Tomcat线程– Tomcat线程3
依此类推，直到所有Tomcat上的所有线程都卡在同一个请求上

那么，我们可以从这次事件中学到什么？我们可以了解到，Apache HttpClient的默认值不一定是您期望的默认值。我们可以了解到，如果您发出重定向，请确保您未重定向到自己（例如我们的Jetty应用程序主页）。我们可以了解到HTTP协议（有时被认为是一种商品）有时可能会很复杂且难以调整，而且并非每个开发人员都知道执行HTTP请求。我们还可以了解到，当你把一个^第三方库，你应该学习如何使用它，了解故障点，以及如何克服这些投资的时间。

但是，这里有更深的信息。当我们开发软件时，我们在权衡开发速度和风险。我们开发软件的速度越快，我们就越需要信任各个开发人员。我们对开发人员的信任程度越高，开发人员出现黑点的风险就越大，这是开发人员无法考虑的事情，例如处理重定向。作为软件工程师，我不确定是否有解决此问题的简单方法–我想这取决于您。

参考：来自Wix IO博客的JCG合作伙伴 Yoav Abrahami 的重定向死亡。