Azure Blob Storage REST API上传遇InvalidAuthenticationInfo错误及传参疑问

• 请求头字典存在语法级拼接错误：你写的字典项"x-ms-copy-source" : ""后面漏了逗号，会直接把相邻的"x-ms-blob-type": "BlockBlob"字段名拼接成一个无效的长键名，直接导致整个请求头格式不合法，触发InvalidAuthenticationInfo报错。
• 认证逻辑存在体系混淆：代码同时混用了SharedKey认证、SAS令牌两套Azure完全独立的认证机制：
  • 用SharedKey认证时，签名计算的原文必须严格按照Azure指定的规则拼接（包含请求动词、文件大小、x-ms-date、x-ms-version、资源路径等固定字段），不能直接把sas_token当作签名原文计算HMAC值；同时你直接用str()转换base64编码的签名结果，会把二进制字符串的前后缀b'、'带入最终的Authorization值，进一步破坏认证格式。
  • 如果你已经生成了具备写权限的SAS令牌，完全不需要计算SharedKey签名、设置Authorization请求头，只需要把sas_token拼接在请求URL的查询参数位置即可完成认证。
• 请求头字段存在非法值：
  • 不需要使用x-ms-copy-source字段时直接删除即可，传空字符串的字段值会被Azure判定为非法参数。
  • 硬编码的x-ms-date为2021年的固定值，和Azure服务端时间差远超允许的15分钟容错范围，会直接被判定为认证失败。
  • 硬编码的Content-Length为1MB固定值，和实际上传的PDF文件大小不匹配时，会触发请求格式校验失败。

本地路径的文件不需要做特殊格式转换，以二进制流的形式作为PUT请求的主体传入即可：

• 提前读取目标路径的PDF文件二进制内容：

  OBJECT_LOCATION = "/home/meera/Downloads/download.pdf"
  with open(OBJECT_LOCATION, "rb") as file_handler:
      upload_content = file_handler.read()
  

• 按照你选择的认证方式构造合法请求头后，在调用requests.put()时把读取到的upload_content作为data参数传入即可，requests库会自动计算匹配的Content-Length值，不需要手动硬编码。
• 两类认证的精简请求头参考：
  • SharedKey模式：只保留x-ms-date（实时生成的GMT格式时间戳）、x-ms-version、x-ms-blob-type: BlockBlob，替换正确格式的Authorization头即可。
  • SAS令牌模式：完全移除Authorization头，把sas_token拼在请求URL的查询参数后，仅保留必要的x-ms开头的请求头即可。

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