真的是要吐，这段时间好几个客户单位反馈业务系统无法使用，一直报错

上去一看，PUT 请求全部被拦截，也不知道家防火墙商干的好事，默认把 PUT 请求全部给禁了，还给客户培训说 PUT 请求就是不安全

给客户解释了半天，根本不听，就说防火墙这样设置肯定有他的道理，说是我们使用了不安全的请求方法，要我们负责安全整改

全站遵循 RESTful 设计的呀~简直要疯了~也不知道哪个 wbd 做的默认规则

www.zhihu.com/question/38770182

主要是历史原因

一直这样啊, 所以你没发现几乎所有的成熟框架处理 rest 都有一个类似 name=__rest 的字段去做 fallback 的么.........

v 站标准月经贴哈哈
搜索 site:hesudu.com restful 了解更多

例如: www.hesudu.com/t/634514

报个价，然后说不支持 put 的防火墙不安全

其实你们现在给 js 做下 ajax function 或者 fetch 的猴子补丁， 把 method=put/delete/update 的都给劫持成 post+method 字段， 原生 form 就通过事件委托劫持， 后端那边做个中间件， 检测到这个字段就把 method 改了， 业务层不用变， 花不了多少时间的

这个可以

http 都是文本协议啊，安不安全还不是看自己怎么处理，不同方式就是报文内容不一样，说起来要安全都安全，不安全都不安全

真心老火
真的要吐了

我们的也可以再 post 里面套用一个_model 参数来用 post 包装所有请求方式，外行也就不说，真不知道做防火墙那帮子人怎么想的

这波反向有道理，哈哈哈

整改肯定是有方案，但是为什么要用别人的错，来增加自己的成本

http 的几个请求方法，就 header 字段有区别，要不是浏览器限制，get 也能承载 body 体，真的是有些防火墙厂商运维还四处宣扬，PUT 不安全，工作群里问他们不安全的点在哪里又说不出来

报个价，然后说不支持 put 的防火墙不安全

所以在我有话语权的场合, 我基本上都提倡用 post + json...不用 get 是因为不用把参数带到 url 上面. 但总有人喜欢瞎整, 或者是复制粘贴不管啥, 给出了接口就完事了...要不就是 post get 乱用, 根本不管什么 rest

一看就是没有用 HTTPS ，用了 HTTPS 防火墙还能知道你用的啥方法？

以前只用 GET 和 POST 是因为一些地方运营商屏蔽其他 method ，现在还只用 GET 和 POST 是因为一些运维人员只会复读前辈的“不安全”，前辈为什么说不安全他们是完全不知道，只会有样学样

知其然而不知其所以然，迷信就是这么来的

有道理，不用 HTTPS 还谈什么安全🤣

那就整改啊，上 HTTPS 和 mtls ，让他防火墙检测不到，不就“安全”了吗？

WAF 能看到吧（不知道这个「防火墙」在哪一层

上 https

上 https ，也可能没用的，防火墙要求把私钥给他。

就是懒.. 估计要走流程改.. IIS Akamai 都遇到默认 PUT 没开的问题

甲方是爸爸，听甲方的

学校还是 zf 吧，我们之前学校也是这种情况，把 put 和 delete 都改成 get post 了

我现在觉得全 post 真香

因为最原始的 http 里面 put 是上传文件的一种方式（比如 iis6 ） 所以被视为不安全的 method 。

所以有些 waf/扫描工具 /扫描人员 直接报告说支持 put 就是不安全

webdav 你坏事做尽(

有些客户，你不要把他当人看，楼主的客户大概就是这种人。基本上，凡是拿预算买东西而不是花自己钱买东西的客户，不论中外，都不是真客户，你不能拿正常人的思维去对付。

对方业务里在用老系统？老系统涉及 put 请求就有漏洞。

确实给了私钥的哈

不太认同那种因为甲方就要应承他的想法，什么都照甲方的想法改，最后出问题了还是会甩锅到自己头上。

就像十年前的项目，你不兼容 IE 就说你系统有问题，技术都顶着，技术栈全线更新全切 Chrome 了，现在客户也知道旧版 IE 不能正常显示不完全是系统的

就给了两个方案，要么双倍预算我们重做系统，要么防火墙放行

有些想法很中肯，客户傻逼就不陪他玩，我绕过就行

但这次就是不太想绕过了，要么重新开发，要么你把 put 给放了

put 改成 post 不就完了吗，批量替换分分钟的事情。

因为有很多安全工程师拉低了圈子的下限.

支持楼主硬刚哈😀

之前也遇到过一次同样的问题，结果没刚过甲方的运维。最后还是妥协了，在前端加了个拦截器，把所有 PUT 和 DELETE 请求换成了 POST ，同时附加一个 X-HTTP-Method-Override=PUT/DELETE ；后端再按 X-HTTP-Method-Override 给换回来……

倒也没废多少事，但是非常不爽。

＃22

什么叫最原始的 HTTP ？

HTTP 0.9 ？ HTTP 1.0 ？ HTTP1.1 ？

HTTP 标准里面 PUT 的语义是修改 Entity ，对应到你说的文件的例子里面修改文件，上传文件应该是用 POST 。

所以你说的东西只能说是某个 HTTP 实现的问题，并不能怪到 HTTP 标准本身头上。

还是甲方好

API 接口只能用 POST 和 GET ，且 http 状态码只能用 200 ，否则你都不知道会发生什么事

只要能加钱，啥都能改，不给钱，请滚

＃31 我哪里怪 http 标准了 我是怪“waf/扫描工具 /扫描人员 直接报告说支持 put 就是不安全”

你们给客户推开源安全，闭源危险的文章，让他们要求防火墙那边开源，狗头

甲方给钱才叫爸爸，不给钱就是孙子。合同以外的需求，给钱就开发咯。

“PUT 方法，由于 PUT 方法自身不带验证机制，利用 PUT 方法即可快捷简单地入侵服务器，上传 Webshell 或其他恶意文件，从而获取敏感数据或服务器权限。”
甘霖娘的，网上的资料翻来覆去就抄这句，也不说个所以然。

随便就搜到个：blog.csdn.net/CHEndorid/article/details/111277629
而且和楼主公司的情况挺像的，不会就是同一个公司吧？

直接贴过来：

一、背景
最近研发让我开一下服务器的 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 方法，这是一种危险的方法。

另外：竟然真的有人认为 REST 挺好，是有多傻。

如果用 Spring 的话可以试试 HiddenHttpMethodFilter

30 楼就是标准做法
get 带 body 也是靠这个
参数里加也算是标准写法 有些 http 库就直接支持

结论：这傻帽根本没有自己实测过。首先，用于 Web 服务的 Nginx 为什么要带 dav 模块编译？各大发行版的默认 Nginx-minimal 就是没有 dav 模块的。你为什么编译的时候不可以关掉
其次，Nginx 的 dav 模块是需要 dav_methods 指令开启的。还可以根据不同路径使用不同的设置。
nginx.org/en/docs/http/ngx_http_dav_module.html

自己不会配置 Nginx 还要怪 restful 不行？

用于 Web 服务的 Nginx 为什么要带 dav 模块编译？各大发行版的默认 Nginx-minimal 就是没有 dav 模块的。你为什么编译的时候不可以关掉

人家原文里说：

对于 nginx ，可以使用 HttpDavModule 编译 nginx （./configure --with-http_dav_module ），开启 PUT 、DELETE 等方法。开启后，恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。

这意思没说默认就有 dav 模块吧？也没说默认就开启吧？人家这意思说的就是默认不开启、如果需要开启单独编译吧？所以你要不要再自习看看 :joy:

其次，Nginx 的 dav 模块是需要 dav_methods 指令开启的。还可以根据不同路径使用不同的设置

你有没有想过今天给你开一个特殊的明天给他开一个特殊的，安全部门还得维护各种，开发与运维、安全人员耦合，而且毕竟留了口子，哪天不小心、或者包括人员离职交接、新功能上线导致纰漏留了漏洞等情况？而对于开发而言，统一协议规范、提高这点安全标准并不费多大事，为什么要为了开发自己的便利去与更多部门产生工程上的耦合？代码讲究高内聚低耦合，但代码是服务于整个工程的，工程思维要考虑整体，包括架构、运维、安全相关的部门协作等各种，只考虑自己方便不是一个好的努力方向

而且，我上楼转那个帖是为了说明 PUT 不安全相关的问题，所以，nginx 编译方案并不适合作为安全问题甩锅的理由

自己不会配置 Nginx 还要怪 restful 不行？

抛开 nginx 不谈，restful 就好用吗？

1. 真实项目里有多少人在用真正的 restful （只是用了各种 method 就以为是 restful 这种不算）？
2. 有多少人真正理解了 restful ？不怕各位笑话，我就没太懂，因为搞得太绕太复杂，要理解它所谓的精妙设计就要不少心智成本，就像有人讨论说的，它跟 OOP 一样存在过度抽象的问题，需要前期消耗很多顶层设计、预先设计的成本，我只是人云亦云、具体我是不了解了，因为好的东西讲究大道至简少即是多，这种搞一堆套路定义的东西、把本来可以简单的问题复杂化，看半小时还没入门、让人云里雾里的东西，我默认它是垃圾。
3. 虽然我不真的懂 restful ，但是可以简单对比下 restful 和 GET/POST+结构化 body 的方式，最简单的思考，restful 不仅多种 method 要仔细设计，仍然也需要 body 参数的结构化设计，而 GET/POST+结构化 body ，省去了 method 设计这块的心智成本，哪个更简单省力？另外，抛开 web 领域，其他服务器领域，命令号 /路由+结构化 body 到处再用，IM/游戏 /分布式系统内部 RPC 交互，也就 HTTP 这垃圾协议早期设计者内心戏太多搞得这么复杂，号称的文本协议可读性好都是扯淡，即使二进制协议，浏览器或者其他工具转换一道可视化出来也不是啥问题，但对于整个互联网流量、算力会带来巨大的节约，相应的也是巨大的性能提升。早期的用户量小，这点协议复杂带来的成本不高，现在都互联网爆发的时代了、大数据的时代了，HTTP 协议的复杂性带来的能源消耗都是不小的开销，只是历史包袱太重没法随便切换成更高效的协议，我目测相比于更高效的二进制协议，它浪费的能源甚至不比挖矿少。

所以，是大家 “怪” restful 不行还是它真的不行？

WebDAV 的问题咋又车到 RESTful 了，不 diss 一下不舒服是吗

我记得 springboot 的话，可以前端 js 改成 post 方式 加个参数 _method = put/delete ，后端不用变就行

有些 put 和 post 的路由是一样的，简单替换不行

＃38
＃39 网上抄来抄去的那篇文章就是启用 WebDAV 又不配置认证，发现可以匿名上传，然后得出结论：可以匿名上传是因为 WebDAV 依赖的 HTTP PUT 不安全

就是错误归因。类似于把 Redis 暴露到公网又不配置认证，被挂马了，说 Redis 认证方法不安全

PUT 方法和 Nginx + PUT 组合在云厂商的服务里多得是，配置类 API 大量使用 PUT ，对象存储上传文件也用 PUT ，CDN 既用 Nginx 也用 PUT 。自认能“快捷简单地入侵”的快去 SRC 提交漏洞，有这本事拿个几万美金奖励轻轻松松

HTTP Methods 本身就只负责操作，安全认证都不是人家的活。安全没做好，只 allow GET 也能被 SQL 注入

做个拦截统一转发

GET/POST+结构化 body ，省去了 method 设计这块的心智成本

这个看不先去了哈，那 http1.1 设计就太冗余了，按这个说法最安全的最好的浏览器发展方向，应该把包括 GET 在内的所有方法，都自动封装为一个 WANT 发送

各大厂商的开发 API 还搞什么 restful 呀，完全是莫名其妙的增加心智成本

我觉得真安全，就上 HTTPS 。然后跟客户说，这是新需求，加钱！！

这篇明显是有问题的，网上转过来也得自己思考下。
如果实实在在地打印过 http 请求中的内容，看过 http 的格式就知道 method 的最大区别就是第一行的格式。
（ http 是基于 tcp 的，只要你把 http 请求收到的 tcp 内容打出来看看就知道了）

什么叫“从 Java 代码的角度考虑问题”？这跟什么语言都根本没关系，是 http 协议的内容。
“在研发的代码里，终端（浏览器或客户端）过来的流量，最终通过 java 的注解，携带参数进入到了研发写了一个方法里来了。”写这篇文章的人，明显就是直接上手 spring boot ，连基本的 http 协议都没了解过。

至于什么 nginx 会遇到问题，那就去配啊。

阿里云的 API 不都是 PUT 、DELETE 这样用么，难道阿里云不安全？

从技术角度来说，修改也很简单，改用 POST + Header 方式来模拟 PUT DELETE PATCH （都不用自己写，我记得 Spring 有现成的 Filter ）；前端从 HTTP Client 库那边拦截修改一下即可。

楼主和楼里的各位，我觉得我们参考大厂就好了
国内的包括阿里云 百度 网易等等接口都有 PUT 的，把这个直接甩给客户看就好了

搜关键词：X-Method-Override ( www.ibm.com/docs/en/odm/8.10?topic=methods-overriding-security-restrictions-http )

各位总是从技术角度讨论。
最近新闻，国美监控员工上班上网流量行为。
很简单，你们客户网管那边的防火墙，还监控不了 put 和 delete ，只能监控统计 get 和 post 的请求。
所以你们就按要求改就是了。说再多也没用，本来就不是技术问题。
[狗头]

实际测试，nginx minimal 在反向代理的时候支持所有函数，不需要编译 dva 模块。

所以说如果你使用的是反向代理，是不需要编译 dva 模块的，如果不需要编译 dva 模块，那么也就不会因为 put 而产生漏洞，也不需要去禁止 put 函数。

＃51

这篇明显是有问题的，网上转过来也得自己思考下。
如果实实在在地打印过 http 请求中的内容，看过 http 的格式就知道 method 的最大区别就是第一行的格式。
（ http 是基于 tcp 的，只要你把 http 请求收到的 tcp 内容打出来看看就知道了）

我还算了解一点 tcp 和 http ，我这有一份手撸的 golang poller tcp 框架，支持了 http 异步解析，其中包括一份完整的 http parser：
github.com/lesismal/nbio/blob/master/nbhttp/parser.go

什么叫“从 Java 代码的角度考虑问题”？这跟什么语言都根本没关系，是 http 协议的内容。
“在研发的代码里，终端（浏览器或客户端）过来的流量，最终通过 java 的注解，携带参数进入到了研发写了一个
方法里来了。”写这篇文章的人，明显就是直接上手 spring boot ，连基本的 http 协议都没了解过。

不管是不是 spring boot ，我都没出来你说这篇文章明显有问题是指什么问题。那篇文章作者的意思是从运维、安全部门部署的网关 /代理软件的层面不能允许 PUT/DELETE 这些方法，而从开发的层面不管什么 Method 都能拿到相关参数进行验证。
“这跟什么语言都根本没关系” —— 这句是对的。

至于什么 nginx 会遇到问题，那就去配啊。

nginx 的问题，，
我转的帖子的作者的意思是不同部门 /工种在整个工程实践的不同层上的安全考量角度，这跟用什么语言或者 java 用什么框架没关系，甚至 nginx 怎么配置都不适合这么实践——这一点我在上一楼（＃43 ）回复前面小哥的内容里面也提到过了，层主也可以看下

蹭住也可以多思考下，然后再看看我是不是转帖时候没思考 :joy:

现代人的心智是有多脆弱啊，restful 都成心智负担了，像相对论这种东西根本就不该存于世间吧

楼上说了这么多，还是没懂到底啥安全问题

其实没什么安全问题，只是存在上面所说的安全风险

客户逗比还是得按着他的意思来，不然防火墙的钱就白花了

“PUT 请求全部被拦截，也不知道家防火墙商干的好事，默认把 PUT 请求全部给禁了，还给客户培训说 PUT 请求就是不安全”

1 、PUT 本来就是幂等不安全啊，从这个角度来说确实是的。
2 、禁用也是能理解的，国内大量低素质程序员，统一成 post 会防止很多弱智错误。

HTTP 协议中的 "safe" 不是信息安全上的 "safe"，POST 也是 unsafe 方法，那都用 GET 好了。

＃64
“全站遵循 RESTful 设计的呀”
楼主说的全站遵循 RESTful ，我说的是 RESTful 规则，post 是我记错了。

PUT 不安全这个观点毫无依据，是应用垃圾才不安全，却怪到 PUT 方法本身，这观点一点都不正确。如果 PUT 修改数据就不安全，那么 POST 新增数据就安全了吗？我们公司做云平台项目和产品，云厂商的 Rest API 全都有 PUT DELETE ，还需要 OPTIONS 支持跨域，云厂商可都是安全合规的，所以现在还说 PUT DELETE 不安全的都是瞎扯。

＃66 sofish.github.io/restcookbook/http%20methods/idempotency/ 你说你连幂等性和安全性都不知道，你来对什么线？我说的安全指 “不修改资源的 HTTP 方法。”

由于 PUT 方法自身不带验证机制
到底啥个验证机制啊，安不安全不是程序的问题吗，怎么还由 method 决定你安全性的？
照这么说 restful 就是个垃圾了

感觉没啥特殊要求的话还是直接 get post 就行了，别按 restful 接口规范，那个规范明显是有点问题，至少在 wen 开发的时候前后端联调有很多的不方便，比如浏览器 network 查看到是接口名称语义化不强，很难受，深受其害

通篇读下来，我还是没懂

[我是废物.jpg]

这文章说的跟研发有一毛钱关系？

既然你了解 http 就好说了。

1. 有人说 PUT 、DELETE 方法是不安全的，我第一个问题就是“为什么 post 是安全的，而 put 就不安全呢？（毕竟 http 的内容基本上是一样的）”
2. 你给出的文章根本就没有回答这个问题，只是说对于 nginx 来说 put 和 delete 是不安全的，不让用。我第二个问题就是“为什么对于 nginx 来说 put 和 delete 是不安全的呢？（毕竟 http 的内容基本上是一样的）”
3. 你所转载的文章说到“开启后，恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。”。但这时候我又有问题了：“PUT 能把病毒文件发上去，为什么 POST 就不会呢？（毕竟 http 的内容基本上是一样的）”
   所以这篇文章根本就没有回答“为什么 put 是不安全的？”这个问题啊。
   而且根据＃ 47 等楼的回答，“对于 nginx 来说 put 和 delete 是不安全的”这个观点根本就是站不住脚的，至少不是 nginx 的问题而是运维人员的问题啊。
   找到问题才能对症下药啊！！！

文章中唯一有价值的就是“不同部门 /工种在整个工程实践的不同层上的安全考量角度”这点。
如果运维那边说用的软件有问题又不能升级，我觉得后端可以配合一下改。
如果客户说防火墙老旧有问题，后端也可以配合一下改。
如果运维自己水平不行配不来，还直接来句“PUT 和 DELETE 不安全”直接让后端改，这 tm 就是纯甩锅。

为整体考虑可以，但拒绝背锅

莫名想到了那个用 GET 方法删除，结果被 Google 的爬虫删了所有文章的帖子，GET 也不安全啊 ~

首先，你知不知道 PUT 和 DELETE 主要是可以用来上传和删除资源的 :joy:

＃74 如果不知道这个，那我能理解为啥好几位说没看懂了。

了解 RESTFUL 的人都知道吧

有什么关系吗？说到底，只要能传递信息，你用 get 、post 、还是 put 都是能做增删改查的。
get 不安全还能理解，因为信息直接显示在 URL 里面，可能会被浏览器书签等功能保存下来被别人看到什么的，至少是有理由的。
而 post 和 put 的内容都是放在请求体里，你倒是告诉我请求头里一个单词变了下，为什么就是不安全的了？

那 PUT 是不是多了一点被人上传恶意文件的可能？
转的帖子里有：
“恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。”

至于黑客怎么玩，我不懂、不瞎吹。

如果说运维、安全人员、以及开发人员都对开放 PUT 的路由做好控制就没事，但就像我上面说的整个工程、团队协作各种耦合成本甚至审批流程，都提高了许多，尤其楼主这种好像还是不同公司之间的。

＃77
不要只当成 api 接口服务，还有可能同一套 nginx 有文件服务，系统还可能有其他的风险，能减少一个漏洞的点就减少一个，能减少一点工种上的耦合就减少一点耦合（最主要的是 PUT api 接口完全不是不可替代的）

＃77 你不要对牛弹琴了,他根本没有论据支撑"PUT 方法不安全"这个论点.

我得谢谢你夸我牛，哈哈哈，这一点我认，，

达克效应：越无知的人越自信。
总是有“高人”恨不得重新发明整个互联网。。。

另外再跟你们说吧，我自己的 api 类项目里，连 GET 都不用的，统一 POST+结构化 body(json/pb/msgpack/...)

本来交互协议主要两点：
一是路由，RPC 里叫方法，有的游戏为了节省流量和性能会用数值类型、叫命令号之类的，各个领域自定义协议的项目叫法都类似
二是参数。

HTTP 协议本身算是互联网早期产品，设计者当年也都是摸着石头过河，但因为整个互联网不是自家项目，一旦协议定下来，要考虑全网兼容性，所以即使是缺点也不好及时匡正。包括不限于本帖里说的 METHOD 安全性，还有比如 keepalive 之前的短连接、请求不带 id 无法向多数 rpc 那样可以乱序响应所以即使支持 keepalive 和 server side pipeline 了仍然有线头阻塞的问题，甚至再往４层说，tcp 也渣，４层本身也存在线头阻塞的问题，所以各位可以看到，为啥 http2.0 还没普及，quic/http3.0 都出来了并且更被认可，而 quic/http3.0 是 udp 的，可以解决更多问题。

REST 是 REST
RESTful 是 RESTful
两者不一样。

现代的 web 开发全是基于 REST“表现层状态转换”理念设计的，HTTP 的 URL/URI 就是 REST 的典型代表，而 RESTful api 只是 REST 风格的接口，比如基于 HTTP 的 SOAP 接口由于把请求内容、参数等都隐藏在请求 body 里面，无脑使用同一个个 HTTP URL 地址的就不是 RESTful 接口，而 RESTful 接口简单的说就是 URL 明确的指明了要操作的资源对象，这是区别接口是否 RESTful 的最大特点。

所以如果和 SOAP 那样，即使使用了 PUT 、DELETE 方法的 HTTP 接口也不是 RESTful 接口。

en.wikipedia.org/wiki/Representational_state_transfer＃Applied_to_web_services

达克效应：越无知的人越自信。

提出这句的时候也可以先送给自己，思考下自己是否听懂了别人在说什么。。。

总是有“高人”恨不得重新发明整个互联网。。。

第一，我没说过要重新发明，不是非要重复造轮子而是减少使用上的坑，少即是多
第二，我上一楼聊了点 http2.0 3.0 的，历史、社区兼容性占了很大因素，否则可能早就被优化了。考虑兼容，所以没法只能慢慢先从标准上推进、逐渐更迭，就像老龄社会一样只能等老旧项目自然死亡。
优化不意味着重新发明，而是软着陆，否则，如果不需要优化，你以为谷歌闲的蛋疼搞 quic 、社区闲的蛋疼接纳 quic 并且成为实际的 3.0 ?

拜托楼上某些位大神夸人或者讽刺之前先多了解下技术本身的点，比如 tcp http 协议的实现、历史时期的局限、有那些缺点、以后的优化方向，而不是只看眼下大家都这么用就跟着一块用，人云亦云不知所云也就算了，至少拿出点你们的观点、论据好吧，有论据 vs 无论据口嗨，我嫌累了

本来交互协议主要两点：
一是路由，RPC 里叫方法，有的游戏为了节省流量和性能会用数值类型、叫命令号之类的，各个领域自定义协议的项目叫法都类似
二是参数。

之前楼写完上面的落了几句，补充上：
本来简单化一和二就搞定的事情，HTTP 协议非要搞成 Method + 路由 + 参数 三个层次，而且参数还可能有 header 里的 kv form ，还可能有 trailer 的 header 、body ，body 还可能 content-length 或者 trunked ，考虑到社区、历史、兼容因素，可以理解这样的做法。但是你说实际上这协议好不好，我是真没法说好。

饿殍遍野难民潮的时候，富人家施舍点粥米穷人都觉得香。
自己技术积累不够的阶段，社区、别人随便给个能用的轮子就觉得好用、牛逼。

美好的事物不能普遍占据主流——这才是主流的现实情况，劣币驱逐良币的历史故事和当下正在发生、未来也会不断发生的事情都多了去了，都是什么天时地利人和、顺应时代、场景者得天下罢了。

但美，仍然是美。

看了楼上的争论才知道还有这么个历史。

这个用法也能用，不过看起来就像说： http 、mqtt 、mysql 、redis 这么多种协议让人头疼，结构复杂、数据容易、还带来了设计的复杂度，我们就全部用的 TCP 流，内部定义一些字段区分不同含义。

复杂的工具（ RESTRull ）是为了解决复杂问题，一代代人总结整理出来的经验，你不能说自己目前这么干够用就认死了只这么干（ post+body ）。

我们就尽量按照 RESTFull 设计接口，用起来没觉得复杂，查接口、查日志也方便，开发功能、定位问题等等分类也比较合理，如果现在让我们全都用 post ，接口多起来以后简直要吐血。

如果把 post+body 比作 txt 文档，RESTFull 就跟带标签的 PDF 或者带目录的 word 一样，一两页资料看不出差别，几十上百页呢？

另外说的安全问题，这些早就没了，要说不安全也是使用的人没做好处理，跟什么方法没关系。

这个用法也能用，不过看起来就像说： http 、mqtt 、mysql 、redis 这么多种协议让人头疼，结构复杂、数据容易、还带来了设计的复杂度，我们就全部用的 TCP 流，内部定义一些字段区分不同含义。

层主可以多了解一些类型的项目，这世界上不是只有 http/mqtt 之类的这几种协议，有太多自定义协议了，只是因为自定义协议多是自家项目、不会形成广大社区、行业的这种 RFC 级别的协议规范，mysql/redis 其实就应该归类于非广泛社区的协议，同样地，它俩也不需要 RFC

复杂的工具（ RESTRull ）是为了解决复杂问题，一代代人总结整理出来的经验，你不能说自己目前这么干够用就认死了只这么干（ post+body ）。
我们就尽量按照 RESTFull 设计接口，用起来没觉得复杂，查接口、查日志也方便，开发功能、定位问题等等分类也比较合理，如果现在让我们全都用 post ，接口多起来以后简直要吐血。
如果把 post+body 比作 txt 文档，RESTFull 就跟带标签的 PDF 或者带目录的 word 一样，一两页资料看不出差别，几十上百页呢？

确实需要复杂的基础设施的地方，我也会用，我并不是反对复杂的东西。
我是反对本来可以简单解决的、却把问题搞复杂了。
比如你说的查日志，并非必须 Method 才能搞定，路由分段一样可以解决，比如 /aaa/bbb/...

我上面一楼也有补充的，协议交互主要就两点，而 路由 /命令 这里，我也没限制只能一个层次比如只能 /aaa 不能 /aaa/bbb ，这至少比 HTTP method/路由 /headerbody 各种参数要少了一元设计成本

另外，你的这种观念形成过程可能是反的：是因为从学习到使用都是按社区或者自家项目这样经历下来的，因为用并且用习惯了并且有人说它好、所以自己也觉得它好，可能没有尝试过自己从底向上设计这些基础设施的思考。就像我上一楼补充里说的，别人给你个轮子，能用，就觉得好，所以你对它的好的判断欠缺真正参照物来对比。

可以尝试下了解多一些类型的项目，或者自己自底向上设计基础设施，然后你就会面对这些设计上的关于美的丑的性能优的劣的各种细节考量，然后才能得出更全面的结论。

另外说的安全问题，这些早就没了，要说不安全也是使用的人没做好处理，跟什么方法没关系。

这个我前面楼层说过，安全问题不只是代码逻辑，安全还有很多工程逻辑在里面。很多场景都可能因为人没使用好导致安全问题，但是 PUT/DELETE 的问题相对明显，并且这两个方法并非不可替代、禁用它俩用其他简单方案替代成本也不高

如果楼主遵循 restful ，put 和 post 方法肯定是有 pathvalue 这个区别的，所以可以批量替换。例如新增订单是 post:/xxx/orders ，和修改订单：put:/xxx/orders/{id}

未读提醒里没有你的回复，所以才看到

PUT 方法和 Nginx + PUT 组合在云厂商的服务里多得是，配置类 API 大量使用 PUT ，对象存储上传文件也用 PUT ，CDN 既用 Nginx 也用 PUT 。自认能“快捷简单地入侵”的快去 SRC 提交漏洞，有这本事拿个几万美金奖励轻轻松松

专用场景用来对比安全部门的通用场景合适吗？ PUT/DELETE 跟 POST 存在上传、删除资源的区别，代理也有不同的 api 、文件服务，能都统一处理吗？而且，我之前楼提到过了，就算按路由配置放行策略，开发、运维、安全部门耦合，这样好吗？并且 POST 替代 PUT 成本很高吗

你举例子的，比如特定厂商的特定的服务或者业务，比如上传配置，接口做好了处理，比如对象存储基本是内部服务代码内网调用的不对外开放的所以也不怕，但是跟通用场景两码事，我好几个楼解释了很多，不只是 nginx 是否可配置、怎么配置，不只是接口代码可不可以处理，还有工程、跨工种协作上的，还有 HTTP 协议本身的

如果都考虑自己眼下这点代码逻辑，那倒是万事大吉。

"那 http1.1 设计就太冗余了" ——事实就是这样子的，不只是 http1.1, tcp 、http2.0 都有缺陷，互联网创世年代摸石头过河，都可以理解，但不好或者不够好就是不好或者不够好。

你自己逻辑搞笑，安全厂商屏蔽 PUT 的理由是你说的幂等不安全吗？你用这个来说明厂商是对的，这不是牛头不对马嘴吗？防火墙厂商认为是 PUT 修改数据不安全，我说 POST 也修改数据那也一样安全，逻辑上哪有问题

你自己逻辑搞笑，安全厂商屏蔽 PUT 的理由是你说的幂等不安全吗？你用这个来说明厂商是对的，这不是牛头不对马嘴吗？防火墙厂商认为是 PUT 修改数据不安全，我说 POST 也修改数据那也一样安全，逻辑上哪有问题

以前公司前端同学说过一个 bug ，最终发现是早期的支付宝小程序版本 PUT 方法不传 body 导致的。

＃90 不是所有人都有全局观啊，有些人没接触过全局的事情，只会专注于自己眼把前那点东西，很正常的，你这样给他们解释，他们脑袋里没那个概念，讲不通的

就像现在谁要是丢个市政|府的指导意见问题给我，我也是个只看得见自己眼把前东西的瞎子，因为我也没接触过市政|府政策制定到底会影响到哪些方方面面

现在很多主流软件和云厂商的大量 API 都有 PUT DELETE ，在你眼里居然都算专用场景，那什么叫通用？不仅云资源配置、对象存储，其他云厂商服务或软件我随便找几个 API 都有 PUT DELETE 。

Azure 翻译文档 API
docs.microsoft.com/en-us/azure/cognitive-services/translator/document-translation/reference/cancel-translation

阿里云日志索引更新
help.aliyun.com/document_detail/74912.html

MongoDB Atlas
docs.atlas.mongodb.com/api/

ELasticSearch 删除 API
www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete.html＃docs-delete-api-request

国际云厂商都是通过众多安全合规标准的，他们有 PUT DELETE 也能通过，凭什么说有 PUT DELETE 就是不安全？在我看来，安全问题并不是 PUT DELETE 本身造成的，但部分安全部门和厂商只会一刀切，这就是懒惰、不思进取、推卸责任。

你们就想着自己的业务系统，防火墙哪里就是防你一个的？
业务网络肯定还有许多各个时代的系统，你安全代表他们的安全？

你如果有兴趣辩，可以把我回复的多楼层都看一下，先明确下 带上传 /删除文件的服务和 api 的区别、通用场景包括比如安全部门的需要与你说的云厂 api 的区别，你的云厂 api 自己处理好了那是你云厂自己的事情，所以云厂 api 就代表通用全场景了吗（比如这个帖子说的安全部门的需求）？

其他的，工程逻辑、多工种与部门协作，如果你只站在 curd 这种层次考虑问题，我前面楼层已经包含了的一些基本点你们都不看，那烦请不要跟我继续辩了

是啊，解释这么多，真心累，好多写 curd 的人舒适区里呆久了，就不乐意把自己提到高一点的层面看问题，但凡高看一点，就不至于停留在 "程序员 /码农" 的水准，至少能搞个 "架构师级程序员 /码农" 的水平。
太多从业者都只考虑眼前这点，真的是不配叫工程师了。

请问谁可以复现一下 nginx 在 put 情况是否真得可以上传病毒文件？

扯那么多，不就管安全的不想花精力，抱着落后的知识，摇着安全的大旗，故步自封，把问题丢给开发呗。