导读：近期有一个业务部门的同学反馈说他负责的C工程在小概率情况下SpringMvc会返回415，通过输出的日志可以确定是SpringMvc找不到content-type这个头了，具体为什么找不到了呢？请听我娓娓道来。
关键词：http 415，SpringMvc，nginx，lua，wireshark，jmeter
问题现象：
近期接到一个同学的反馈说，他负责的C工程在小概率的情况下SpringMvc会返回415，通过输出的日志发现请求头里面并没有content-type了，所以才导致SpringMvc返回415，他猜测可能是我在nginx这边加的lua脚本给影响了（我们用lua脚本做了一些灰度跳转的逻辑），虽然我心里很清楚lua这块并没有修改请求头的逻辑，但是没办法，嘴上说说并不能服众，我需要拿出证据自证清白。
第一把斧亮相：
既然是说lua把请求头给改了，那把content-type输出来看看不就完事了。很简单，直接修改nginx access日志的log_format即可，在原有的基础上增加$http_content_type。就这样很快加完了，那就开始守株待兔吧，运气还不错，几分钟以后就命中一个415的请求，查看access日志里记录的content-type值，一点问题没有，就是我们熟悉的那个“application/json”，这一刻心里窃喜“不是哥的问题，回邮件该干啥干啥了”。
第二把斧亮相：
半天过后负责Resin（一种web服务器，和Tomcat差不多）的同学找到了我，猜测可能是请求头里面有某些特殊字符导致请求头的解析发生了问题，所以请求头乱了，请看下面这张图，仔细找找其实是能找到content-type的。
话到这里我已经知道他要干什么了，给我几分钟我想想办法，既然怀疑是特殊字符导致那我就将所有的头信息都打印出来，查了一下lua-nginx-module的使用手册，有一个声明叫log-by-lua可以使用一下，它类似于一个过滤器一样，如果配置了，nginx会在特定的阶段触发它，更具体的说nginx会在log阶段且在记录access log之前触发。所以我的大概思路是这样“如果请求后端服务器返回415那就输出请求头信息到日志中”，具体的脚本写出来就是这样（我当时想是不是可以用在服务的监控上）：
5.将第四步复制的tcp报文直接贴到jmeter里面进行测试（我为什么选择jmeter，因为可以直接模拟发送tcp报文，不会像postman增加一些自己的头）；
6.成功复现结果；
7.导出jmeter脚本给负责Resin的同学修改bug；
问题原因分析：
最终确定是Resin出了问题，但这里有个前提是我们公司自己改造过的Resin，官方的Resin并没有这个问题，至于为什么我们改造过的Resin会出问题，这里就不多说了，只是一些内部的技术债罢了，说了可能也不会明白，明白了可能也不会碰上。
总结：
十一长假的第五天，此刻刚把孩子哄睡着，在床边小心翼翼的打开电脑整理一下上次排查问题的过程，上面提到的几个工具是我想推荐给大家使用的，这里拿自己经历过的真实场景做一个抛转引用，至于更深层次的使用网络上不乏铺天盖地的介绍，我这里就不啰嗦了，祝大家假期愉快。
参考资料：
https://github.com/openresty/lua-nginx-module#log_by_lua