我正在研究http://www.lovethesales.com – 并且遇到了一个恼人的问题.

正如您可能在主页上看到的那样,有时候,间歇性地,图像请求将因502 Bad Gateway错误而失败.这似乎发生在所有浏览器中 – 例如,您可以在Chrome开发人员工具中看到红色失败的请求

问题/ imageproxy中的资源永远不会返回除200或304以外的任何内容.

1)这个页面(设置为显示500个结果)似乎永远不会有破坏的图像,即使它正在进行相似/相同的请求,但显示更多它们：

http://www.lovethesales.com/sales/?take=500

2)如果你按CTRL刷新 – 它总是很好,只有你做’软’标题刷新才会收到502错误. (只需点击刷新按钮)

处理程序是标准的IHttpHandler,注册如下：

<add name="ImageProxy" path="/home/imageproxy*" verb="*" type="LoveTheSales.Handlers.ImageProxy" resourceType="Unspecified" preCondition="integratedMode" />

关于如何解决这个问题的任何建议/想法都将受到最高的赞赏.

干杯,
戴夫

[编辑]
我已经设法在我的测试Azure实例上重新创建了这个问题(只有我使用它) – 并且,在打开完整的Web /请求日志记录后 – 我可以看到502请求甚至从未进入我的应用程序 – 它们不是甚至在日志中.我想这一定是Azure错误？

[编辑2]
这也发生在非Imageproxy请求上,因此,也是简单的静态图像

解决方法:

我倾向于做一些像这样的问题

1)做一个小提琴手.对于某些用户/环境,此问题似乎很难重现.像Fiddler这样的工具可以让你准确记录发生的事情.特别有趣的是失败和后续请求/响应之间的差异(如果有的话)

2)使用户不要注意它.例如,刚刚重新提交请求的jquery错误处理程序.我曾经只发生过一次(当然在我自己打开小提琴手之前).如果问题非常罕见,那么它可能足以处理0.1％的优先出错的情况.

3)执行严重的负载测试(本地).如果你看这里http://blog.wouldbetheologian.com/2014/07/502-bad-gateway-error-on-azure-websites.html,可能会有一个潜在的原因导致你的应用程序池崩溃.这不会被记录,新实例会被调整,但是对旧实例的请求会收到502个请求.

特别是这最后一种情况适合我可以看到的场景.