基于C++ Socket的HTTP音频下载遇307重定向返回HTML的问题求助

• 处理307重定向时直接丢失了原始请求携带的全量AWS S3签名查询参数
  你首次请求的URL是带一长串X-Amz-*签名的有效预签名地址，服务端返回的重定向Location是不带任何参数的同域相对路径/minio/fe-see/monday.mp3。你构造第二次请求时直接把这个裸路径作为GET请求目标，完全没有拼接第一次请求携带的签名串。MinIO作为S3兼容的对象存储服务，收到不带有效签名的对象访问请求时，会直接触发匿名访问的兜底逻辑，返回MinIO Browser前端控制台的HTML页面——也就是你抓取到的2281字节、Content-Type为text/html的响应，并非目标音频文件。
• 未按照HTTP规范处理307重定向
  按照HTTP RFC定义，307临时重定向要求客户端完整保留原请求的方法、请求头、查询参数、请求体，仅替换URL对应的路径/域名部分，不能随意删除带身份校验作用的参数。你当前的实现相当于给服务端发送了一个和初始请求完全脱节的全新匿名请求，和Chrome浏览器的重定向处理逻辑不一致——Chrome碰到这类相对路径重定向，会自动把原请求的查询参数拼接到新路径后，因此可以正常拿到音频文件。

• 修正重定向路径拼接规则
  收到307/302响应的Location头时，先解析路径格式：
  • 如果Location是不带查询串的同域相对路径，就把原请求中?后面的全量签名参数完整拼接到Location路径末尾，再作为第二次请求的GET目标
  • 正确构造示例：原请求路径为/fe-see/monday.mp3?X-Amz-Algorithm=...（完整签名），Location为/minio/fe-see/monday.mp3，第二次请求的GET路径应为/minio/fe-see/monday.mp3?X-Amz-Algorithm=...（和首次请求完全一致的完整签名串）
• 修正请求头构造逻辑
  处理307重定向时不要重新拼接一套固定的请求头，把首次请求发送过的所有请求头（Host、User-Agent、Accept等）原样复用即可，仅修改请求行中的路径部分，配合你开启的keep-alive逻辑直接复用现有TCP连接，不需要重新建立socket。
• 增加响应合法性校验
  拿到200响应后不要直接将读取到的缓冲区内容当作目标文件存储，先检查响应头的Content-Type字段：如果返回的是text/html类型，说明触发了匿名访问的兜底页面，需回头检查重定向路径是否丢失了签名参数。

• 不要随意修改Host头：当前场景下的Location是同域相对路径，Host值和首次请求保持一致即可，只有当Location返回跨域的完整绝对地址时，才需要修改Host、甚至重新建立TCP连接。
• 不要简化请求头构造逻辑：你当前的Accept头只声明了网页类资源的接收类型，可以补充audio/*的MIME类型支持，减少部分服务端的内容协商异常。

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