作者回复: 嗯很好的补充。其实你说的情况,跟课程里的情况正好相反: 1.课程里的案例是返回的方向,是HTTP响应的头部超限 2. 你的案例是请求的方向,是HTTP请求的头部超限。那么这种情况下,属于HTTP请求不合规,返回HTTP 400也是正确的做法。
作者回复: 是的~
作者回复: 是的,案例里的是我在ucloud公有云时候的事情。在ebay也有类似的发生过。
作者回复: 我记得当时的报错信息里并没有明确指出"upstream回复的response里的header size超限”这个原因,也许是Haproxy可以改进的地方。其实envoy也有类似的不足,比如envoy回复4xx的的时候在日志也不会记录具体哪里不合规,只会笼统的说请求不合规。 至于为什么是报502,文中有提及:https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/502 “它表示作为网关或代理的服务器,从上游服务器中接收到的响应是无效的。”
作者回复: 就503来说,是后端(上游)服务器暂时不可用了(比如从LB连不到服务器)。“没有实现该方法”应该是501了:) 你说的aws LB的traceid,应该是LB到上游服务器的请求里带着,而进入LB的时候还没有吧?还是说客户端生成请求的时候就已经带了这个traceid?然后经过LB的时候在traceid后面附加了信息,或者是新增一个traceid头部?
作者回复: 你看重的是这篇文章中哪个关键点? 我猜,是不是把问题表像(选多一个城市就报错)推进到具体的技术细节(收到HTTP 502)的过程? 看到这表像,确实一开始是有点难以下手的。但熟练掌握了网络排查的技巧,你可能就有三板斧了,比如浏览器的开发者工具、tcpdump抓包、wireshark分析,这一通操作下来,扑朔迷离的表面现象,也可能被你逐步定位,最终水落石出。这个过程就像探案一样,是很有趣的!
作者回复: 恩这几个案例确实是http的,明天上线的就是解密课了,其实能解密就依然能做这些分析了,只是前置任务多了一项:)
作者回复: 是的:)