使用PUT请求向Azure Blob传Zip文件返回201但无文件问题排查

以下是针对该问题的具体排查方向：

• 确认请求体是否完整发送
  虽然你设置了Calculate content length，但如果请求代码未正确读取并写入Zip文件的全部内容到请求体，即便返回201状态码，Blob也可能为空或不完整。对比Postman的请求逻辑，检查你的代码是否：

  • 正确打开了Zip文件的数据流
  • 确保流的全部内容都被写入PUT请求的body中
  • 未在写入操作完成前关闭流或截断内容

• 检查签名URL的Blob名称编码一致性
  你的签名URL中Blob名称是编码后的GHD%20Forecast%20Interface%20BY.xml，需确认生成签名URL时使用的是原始未编码的Blob名称（即带空格的GHD Forecast Interface BY.xml）。若签名生成时用了编码后的字符串，会导致实际创建的Blob路径与预期不一致——你在存储账户中查找的是带空格的名称，但实际创建的是编码后的名称。建议用Azure Storage Explorer搜索所有Blob名称进行确认。

• 验证存储账户视图的缓存问题
  Azure门户的Blob存储视图可能存在缓存延迟，建议通过以下方式确认Blob是否存在：

  • 使用Azure CLI执行命令：az storage blob exists --account-name symphnytstcjgrk509 --container-name dmf --name "GHD Forecast Interface BY.xml"
  • 用Azure Storage Explorer连接账户后刷新容器，查看目标Blob是否存在

• 核对请求头的一致性
  对比Postman的请求头和代码发送的请求头，确保无差异：

  • 确认x-ms-blob-type确实设置为BlockBlob
  • 检查Content-Length是否与Zip文件实际大小一致，Postman会自动计算该值，代码手动计算可能出现错误
  • 确认无额外自定义头干扰Blob创建

• 排查签名URL的权限有效期
  虽然返回了201，但如果请求发送时签名URL已过期（比如代码时间处理有误），边缘情况下可能导致状态码异常。确认请求发送时间处于签名的st（2022-11-30T12:59:44Z）和se（2022-11-30T13:34:44Z）区间内。

内容的提问来源于stack exchange，提问作者Fathima AM