当一个功能在开发环境中正常工作，但在使用Apache Httpd和mod_proxy的产品环境中出现500错误时，问题源于Apache将非标准响应码298转换为500。研究发现，Apache在未接收到响应码后的字符串时会修改码。通过添加自定义响应字符串，可以暂时解决此问题。此外，Apache添加默认的"Content-Type:text/plain"响应头导致Chrome和Firefox无法正确解析，需调整Apache配置以避免问题。
前几天，一个开发组开发的一个模块，放到我们的产品环境上去后，发现其中的一个功能没有正常工作。用Fiddler查看HTTP记录，发现那个功能的发出的HTTP请求返回了500错误。查看文档，500代表Internal Server Error，服务器出错了。
问题抛回给负责开发的组，他们查看了服务器log，没有发现相关的错误。而这个功能在他们自己开发的环境上都是可以的。
难道和我们产品环境的部署有关？产品环境和开发环境的不同就只有，产品环境上用了Apache Httpd，并使用了mod_proxy做一个反向代理。尝试在产品环境上绕过Apache直接去访问对应的服务器，发现竟然真的是可以的。 用Fiddler一查，发现响应和Apache代理后的几乎没区别，唯一的不同就是返回的是298响应码。298？好像原来没看到过这个码，查文档，RFC确实没有明确的定义这个响应码。猜想，问题应该是因为服务返回了一个不标准的响应吗，Apache的mod_proxy就将它改成了500。
Google一下，找到了一些：ServerFault上的讨论，
最低0.47元/天 解锁文章
扫一扫
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
