记一次使用企鹅大帝对象存储API触发的高端BUG(2019-03-01 18:00 BUG 已经修复)

事件起因：

使用了一个月的项目，突然在调试过程中导致登陆验证失败，跟踪发现为，企鹅大帝的对象存储服务异常（后成为cos），潜意识的登陆了企鹅大帝的云控制台，发现控制台bucket列表中存在，单击进入单个bucket时，提示不存在，心中一万匹????在蹦腾。删除重建，又复现了此问题，只能请求工单。

各种耐心等待之后，到了晚上10点左右，告诉我说，我在某个时候删除了bucket操作。（WTF）使用cos 的c api，就用了三个函数，cos_put_object_from_buffer； cos_get_object_to_buffer ；cos_delete_object 然后严重怀疑我调用了cos_delete_bucket。改测试用例，把put，get，delete 放到一个循环里面执行了1024次，正常，11点，睡觉了。

第二天早上上班，问题又出现，表扬下，腾讯客服响应很积极。电话沟通，再次强调我使用有问题，调用了删除bucket操作，并提供了后台截图。

 分不清请求链接是什么区别，提供了我的代码给了腾讯，然后走读了代码豁然开朗。于是有了如下测试

发现cos_delete_object与cos_delete_bucket 仅仅为 URL 后半段参数不一样的区别。继续测试：

当我cos_delete_object时参数写为 空字符串时，见证奇迹的时候发生了，居然与cos_delete_bucket是一样的请求。到此问题找到，下面是腾讯客户的表演时刻。

嗯，是我参数使用错了，不应该传入空字符串，你的cos_delete_object发现参数错了你告诉我错了就好了，为什么你要如此热心的删了我的bucket了 ？

最后通过分析URL地址发现，企鹅大帝的API级别的操作太过华丽，服务器判断URL来区分是删除ojbect还是删除bucket。作为一个提供了基础服务的公司，发不出来的API居然还有如此高深的BUG，然后告知我参数错误。

最后感谢surge（付费版），能够让我抓包分析Https，不然无法验证问题的所在。

PS：2019-02-28 16：20 企鹅客户打电话沟通表示正在修复此问题。