本文主要记录我们的讨论过程及结论，具体测试代码就不贴了。
一、背景
最近研发让我开一下服务器的put、delete方法，被我以不安全的http方法给拒绝了。
研发表示我很无理，put怎么就是不安全的了，在他看来，put和post只是语义上的不同。如果put是不安全的方法，那么post也是不安全的方法了。
网上的说法也是分为两派，一派说这些都是不安全的方法，要关掉；另一派说它们只是语义上的区别，不存在安不安全。
二、一探究竟
经过我和研发各自编写测试用例来论证后，我明白了为什么会有这样的分歧：我是从nginx作为web服务器的角度来看问题的，研发是从java代码上来看问题的。
1、为什么说POST和PUT只是语义上的区别？
在研发的代码里，终端（浏览器或客户端）过来的流量，最终通过java的注解，携带参数进入到了研发写了一个方法里来了。比如研发对某个自定义方法使用PUT的注解，那么终端通过PUT方法传递的参数就会进入到这个自定义方法中。有点编程经验的话，就会知道，到了你写的方法里，这些参数就随便你玩了。
对于PUT、POST，研发都可以通过添加不同注解的方式，得到传递的参数，然后进行操作。所以研发会认为他们只是语义上的区别。
2、为什么说PUT、DELETE是不安全的方法？
对于nginx，可以使用HttpDavModule编译nginx（./configure --with-http_dav_module），开启PUT、DELETE等方法。开启后，恶意攻击者就可以直接将病毒文件等传到nginx服务器上，所以PUT等方法对nginx来说是不安全的。
3、上面两个问题是否矛盾？
并不矛盾。
假如研发人员打包一个jar包，这时客户端直接访问这个jar包起的服务，那么put传递过来的所有参数，是可以由研发人员编写的代码控制的。只要控制得没有猫病，那么就是安全的。假如开发的是一个tomcat容器部署的工程，参数也是一样可以由研发的代码控制的。
同时，用nginx也可以反向代理put方法（不用HttpDavModule），所以只要后端服务对put服务做好控制，nginx不需要做任何更改，也就实现了对put方法的支持。
但nginx不能单独开启put等，因为研发的代码不能对nginx做控制。
三、结论
后端服务可开启put方法，只需要后端服务对put传递的参数做好控制，并实现put方法即可。
nginx不可开启put方法，这是一种危险的方法。
才疏学浅，如果分析得不对，请各位大佬指正~~~