作者:张医博
什么是 404
404 标准的 http code 状态码,代表用户请求的资源在服务端不存在, 404 并不是一个异常状态码?而是一个正常的响应。换句话说 404 已经成为了一个结果,这种响应常见在 client 端下载 OSS 的资源时出现。
做好预防
很多情况如果服务端的历史日志保存时间有限,那么出现问题时也无法查证,所以建议使用 OSS 先把日志功能开启,将 OSS 每天的数据都自动备份到用户指定的目录下,费用低廉。
why 404
- 检查 客户端提供的 objectname 是否正确,确保不存在低级的拼写错误。
- 客户端之前上传是否成功,如果成功 OSS 会返回 requestid,凡事没有 requestID 的并不能保证已经上传到 OSS 成功。
- 客户端可以根据开启的 log 查询下对应时间点 OSS 出现 404 的情况。
- OSS 是否开启过 生命周期 功能,开启这个功能,触发生命周期管理规则后,会将满足条件的 URL 完全上除掉。
客户端上传成功,但是下载返回 404
首先这种情况是不存在,如果已经上传到 OSS 的文件,除了会冗余写多份,也受到权限的严格限制,匿名非法的访问是不可能直接删除的,除非使用者自己把 bucket 设置为公共读写(高危权限)
一般对上传成功有个误区,认为返回 200 就代表文件已经上传成功其实这并不准确。会造成两种情况
- 收到状态码 200 的情况后立刻取请求 OSS ,返回了 404 ,等一会再访问就 200 ,怀疑到 OSS 返回 200 和真实的写入成功不同步。
- 上传成功收到 200 状态码,但访问一直都是 404
- 分片上传或者断点续传已经收到了 200 并切有 requestID 的情况下,访问 OSS 仍然返回 404。
其实以上两种情况都是对返回状态的判断不准确导致,可靠的判断方式是,if result.status==200 && result.requestID != None 的情况下才是上传成功。有的 http 请求被 http 劫持的情况下会收到一个伪造的 200 状态码并不是真实的返回。
另外分片上传或者断点续传比叫特殊,是采用将原文件切片的形式上传,每一个分片 multipart 上传成功都会返回 200 和 requestID,这种情况应该以 complete 合并分片后返回的 200 & requestID 为准。
极特殊的情况是客户端使用分片上传时对用的 uploadID 凭证是 A,但是完成合并时用的 uploadID 凭证是 B,OSS 找不到原始的 A 凭证,所以报 404 无法完成上传。
文件之前一直存在,突然访问 404
有以下几个原因
- 客户端的子账号有权限,把 OSS 的文件删除了。
- 具备客户合法的 AK SK 通过 API 删除了。
- 具备合法账号密码的人在控制台删除了。
- 拥有者设置过生命周期过期被删除了。
- bucket 和其他 bucket 有跨区复制的关系,其他的 bucket 执行了删除操作,同步到当前的 bucket,所以文件被删除。