@lesismal 额，，，不会的，新项目我依然会坚持做这样的设计

考虑的点是基于这样几个考虑

1. 产品设计应该尽量统一，采用流行的模式，方便交付，以及和其他厂商同行对接，流行的规范，大多数人更容易接受，读到你是 delete 请求，自然知道这里是要删除一个什么东西，读到 post 的时候，知道这里是新增了一个什么东西，不是 and,create,built 一堆动词的滥用

2. 哪怕我改成全 POST 封装，实际还是会在 POST 的不管是 body 或者 url 中描述这个操作是 query ，还是 edit 或者 delete ，和写 header 里面的 method 头没区别，只是小聪明的重复造轮子了

3.不是每个客户都这么恼火，也有甲方，默认给关了，但是你提出需求，就直接放行了，不是每个客户都这么固执

4.这次坚持了，下一次同一个甲方再遇到这个问题，哪怕是其他同行就不存在沟通成本了

嗯，暂时想到这么多，突然想起两句话，其他地方不一定对，在这里我觉得可以参考“用户是需要被教育的”，“用户不会提前告知你什么是更好的”

我去，，，下班回来直接麻了，这破事儿居然吵热了

给各位汇报一下这个事儿的进展
最后的方案，是甲方也不想再花钱，我们写一个承诺书，我写了一句话，其他甩给商务去扩展了
------------------------------------
因为我司产品遵循 restful 设计原则导致的网络安全问题，由我方承担全部相关责任
------------------------------------
下午还有个小故事

最开始电话和网络中心主任沟通的，表示我们能说明是安全的就行，问题不大，
十分钟后又打电话来，说他问了他们专门管安全的专员，说这个就是风险！！！最后怎么变成修承诺说的就不知道商务怎么周旋的了


我前面已经说过了，这事儿其实也不是个什么事儿，

但是，我明明没有错，为什么要为别人的无知买单？要去“委曲求全”的“绕过”？

GET/POST+结构化 body ，省去了 method 设计这块的心智成本
-----------
这个看不先去了哈，那 http1.1 设计就太冗余了，按这个说法最安全的最好的浏览器发展方向，应该把包括 GET 在内的所有方法，都自动封装为一个 WANT 发送

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

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

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

确实给了私钥的哈

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

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

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

@liliclinton 真心老火
@unco020511 真的要吐了

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

@xmumiffy 这波反向有道理，哈哈哈

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

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

请问 planet 需要固定 ip 嘛？

@dreamramon 肯定用 bitwarden_rs 呀，自己部署自用

@lyhiving 那就难怪了，哎，太累了

@idguardoffline 什么意思？是 bitwarden 的方案有问题吗？

bitwardenrs 项目慢慢会成为个人密码方案的主流工具吧

有结果了，因为 7 月 24 日 提交的证据里含有中文，对方知道了我的主语言是中文。
8 月 6 日 收到 icann 的邮件居然是中英双语的，，，让我确认我发送的证据公开给第三方

>In the meantime, ICANN requests that you confirm your permission for ICANN to forward any information or attachment you may provide to ICANN, to the registrar and/or registry operator and any other party with whom ICANN may consult to address your complaint.
在此同时，请确认您是否同意 ICANN 将您投诉中所提供的信息和附件发送至当前注册商或任何相关人士，以便能进一步协助您的域名转移要求。

上周接到某云客服的电话，正在出差，简直像催命一样的希望让我提供 DNSSEC 的配置信息，并承诺会在今年年底完成 DNSSEC 配置产品化并上线，为了表示歉意给了几百块的无门槛代金券

估计是被 ICANN 合规考核了吧，始终没有透露 ICANN 的处罚措施，，，有点遗憾

http://lede-k3.test.tossp.com/wm%20%282%29.png

http://lede-k3.test.tossp.com/wm%20%281%29.png

蛋疼，imgur 貌似被墙了，，，囧

@Cooky 嗯？有图的呀。。。。https://imgur.com/Tulfgf5.png 这个地址看不到吗？

今天终于收到 ICANN 要求我提供证据的邮件了

> ICANN reviewed your complaint and is requesting additional information. Please provide ICANN the following before 31 July 2019

客服的态度倒是挺好的，半夜 11 点都在帮我处理，但是这个事情超出他能力范围了，最后，只有选择走 ICANN 的工单了。期待 ICANN 的答复吧~
https://forms.icann.org/en/resources/compliance/complaints/registrars/standards-complaint-form

airfoil “ Play to Multiple Outputs, in Sync ”不过是收费的，就没试用了

@bestkayle echo 用户随时等着复用