被客户告知 HTTP 的 PUT 请求不安全，甩锅给我们要求整改

[TossPig]

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

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

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

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

[TossPig]

@shyangs @Joker123456789 有点反智了哈，我认为在实际过程中，怎么做是一回事，但心里还是要知道什么规范的，什么是不太规范的，我前面说了，如果真的 http 不适合你的项目，又非得 B/S 化建议直接使用 Websocket

@patrickyoung 感谢哈，就是直接给怼回去了哈，我在前面的帖子中已经说了后续的处理了

@lesismal http 是无状态，不管什么原因，选择了这个协议，就该按这个思路来。除非是特殊原因的变相使用，把 http 当承载协议。否则设计系统通信的时候，就该按无状态设计

[lesismal]

看来这个帖子是我再次犯二了，不能奢望搬砖逻辑程序员级别的人去理解到稍微复杂一点的超过他们技术认知范围的东西，就像我听不懂更牛逼的程序员、科学家的日常一样。
我散了，节省点自己时间。

[Nich0la5]

看完这个贴惊为天人，真的有完全活在自己世界自动把其他人话套一遍滤镜拉踩全场单方面宣布胜利的啊

[codingbody]

以我浅薄的知识和经验，并限定讨论的范围是某个 web 服务使用了不同的 http method 会不会造成安全问题，我认为不会因为使用不同的 method 导致不同的结果，因为不同的 method 对同一个服务来说最多只是语义不同。

但如果跳出当前的服务，从整个请求链路上看，不同的 method 会不会产生安全问题，我持保留态度。

另外，我们还遇到过客户认为我们的 URL 的 path 出现了某个关键词是不安全的。

[zhouxuchen]

信我者客观公正，不同意见者包括但不限于断章取义、出门右转、多读点书，乐死了

[buffzty]

一大堆人为了用而用,啥也不懂就随大流. 还以为自己是高手

[ERRASYNCTYPE]

自定义个 method 吧，反正也是随便写的

[SteveWoo]

如果楼主公司是做的 2b 业务，特别是私有化项目，建议就此吸取经验，在后续的开发中约定规范：只用 GET 和 POST ； GET 不带参数，header 长度控制在 1000 字节内。
-- 来自 5 年私有云从业者的经验

[namaketa]

算是开发和运维的一般矛盾。运维觉得不安全统统关掉，开发嫌弃运维抱残守缺。

[siweipancc]

打脸楼，哈哈哈，转载农场内容记得检验哦，又不是外行人了(´▽｀)

[shm7]

@lesismal 完全赞同，复读一遍。

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

[Joker123456789]

@TossPig 规范不止 restful 一种啊，还有 RPC ， 甚至自定义都行，而且 post 和 put 的请求报文没什么不同吧，服务器解析的方式也是一样的，无论是从效率，安全 还是什么角度来看， 都没什么区别。 个人认为这仅仅是 为了区分行为 而出现的请求方式。

但是行为不是已经通过接口区分了吗，请求 A 接口是 A 行为，请求 B 接口是 B 行为，这多清晰，实在不行的话像 RPC 通过参数指定 行为，也很清晰啊。

而且规范都是人定的，并不是上帝定的，他不是必须遵守的教条， 只要你的设计是有章法的，有讲究的，那就可以了。

[TossPig]

@SteveWoo 感谢提供宝贵从业经验

@Joker123456789 ？？？弟弟你在说啥？ restful 和 RPC 是两个东西呀
RPC 规范并不是对 http 的，RPC 本身就是跨越了传输层和应用层的存在。
restful 是对 HTTP 中 web api 开发中的规范，http 可以理解为是最常用的承载 RPC 的通信协议之一
不管是 TCP 还是 UDP 甚至 ICMP 都可以设计 RPC ，我这样表达不知道说清楚没有

你要再用 HTTP 再去实现一次 RPC 的想法，有没有问题？
我前面已经表达了，使用了 HTTP 除非是不依赖常规浏览器，又由于环境限制必须使用 HTTP ，否则基于 HTTP 设计 web api 还是要应该遵循 restful
这不是教条 restful 本身就是实践出来的东西。你非不遵循 restful 没问题，你知道这样做是不规范的就 OK 。
明明业内有推荐规范，为什么非要自己去摸着石头过河呢？简单的举例 GET 和 PUT 在失败后是可以允许自动重试的，POST 作为大多数时候作为新增数据或者过程变更的操作可以随便发起重试？重试、限流、容错这些基本功能，你们的系统里面都没有的吗？都用 RPC 自己从头设计一遍？

------
嗯，为什么今天还来扯这个，今天甲方来电话，说是防火墙厂商表示不支持目的地 IP 放行，要么全放要么全关，请我们准备好和深信服的实施供应商现场对线~

[Joker123456789]

@TossPig

首先：RPC 这方面，你只能说是说对了一大半， 还有一小部分 你没了解到的 建议去了解一下，RCP 并不完全 100%指 [远程调用过程封装]， 还有另一种实现规范，就是 请求的 URL 是定死的就是 http://xxxx.xx ，但是参数需要符合某些规范，里面要指定 本次请求的意图，最常见的就是把要调用的方法 当参数传进去， 在区块连上 这种实现方式有很多。

其次：谁告诉你 resultful 是标准规范？ 还有 你看看你自己，把 resultful 当成 真理，非遵守不可，还说不是 教条？？

你就举一个例子吧，直接说，什么场景下 必须用 请求方式去区分 意图， 否则会很麻烦，或者造成代码很烂。 你直接说一个这样的场景出来，你说出来了，我就承认我错了。

本来不想跟你争的，你一来就说我反智，然后又喊我弟弟， 你的语气如此看不起我，我还真得跟你争到底了，除非你拉黑我。