通过python request库获取文件大小和文件类型(解决报错:KeyError: ‘content-length‘)

本文介绍了在Python中使用requests库时遇到的获取content-length和content-type的问题,特别是针对存在鉴权的私有文件。通过设置requests.head的Accept-Encoding参数和使用Range头在GET请求中获取Content-Range,解决了获取文件真实大小的难题。
摘要由CSDN通过智能技术生成


背景

把同一份文件分别存放到了两个oss(可以理解为两个存储商),通过两个oss 返回的下载 url 获取 两个文件的content-length 和 content-type信息,对比是否一致

遇到的问题:

1、当通过response header 获取content-length 的时候,千牛的url 没有返回 content-length

2、涉及到鉴权的私有文件url 获取不到真正的content-length

通过curl -i url 是可以返回同一个文件 存在两个url 的content-length 的,那怎么通过python解决以上两个问题呢(方法不一定最好,欢迎拍砖!)
在这里插入图片描述

一、解决获取不到content-length问题

方法:通过python 的requests.head(url,headers)指定header 里的Accept-Encoding参数,来获取文件流真实的content-length

原因:请求参数 headers里不指定文件流的Accept-Encoding,当服务器有对文件做了压缩后返回时,content-length就有可能获取不到

参考了博文:https://blog.csdn.net/chouhuan1877/article/details/100808814 有说明获取不到content-length的原因

实验对比:

def head_getcontent(file,srcDownloadUrl,distDownloadUrl):
    session = requests.session()
    headers = {
   
        "Accept-Encoding": "identity"
    }
    # 通过requests.head()填入不同的参数处理千牛的文件url
    src_only_url = requests.head(url=srcDownloadUrl)
    src_url_headers = requests.head(url=srcDownloadUrl, headers=headers)
    src_url_headers_stream = requests.head(url=srcDownloadUrl, stream=True, headers=headers)

    print("src_only_url headers= {}".format(src_only_url.headers))
    print("src_url_headers headers= {}".format(src_url_headers.headers))
    print("src_url_headers_stream headers= {}"
<think>好的,我现在要帮用户分析一个HTTP 400 Bad Request的错误。用户提供了响应头HTML内容,需要解释这些调试信息,特别是在连接HTTP服务器时出现的问题。首先,我得回忆一下常见的HTTP状态码,400错误属于客户端错误,表示服务器无法理解请求。接下来,我需要分解用户提供的响应内容,逐条解释每个字段的含义,并分析可能的原因。 首先,状态行是HTTP/1.1 400 Bad Request,这说明服务器认为请求有问题。常见的导致400错误的原因包括语法错误、无效的请求消息、大小过大或者畸形的请求头。我需要逐一检查这些可能性。 然后看响应头里的Server字段显示awselb/2.0,这说明服务器使用的是AWS的弹性负载均衡器。这可能意味着后端服务器负载均衡器之间有一些配置问题,或者是负载均衡器本身处理请求时出现了问题。不过400错误通常是客户端的问题,但也不能完全排除服务器配置的可能。 Date字段显示的时间是2025年,这可能是个测试时间,或者是系统时间设置错误,但通常不会导致400错误。Content-Type是text/html,说明返回的内容是HTML格式的错误页面,这也是标准做法。Content-Length是122,对应返回的HTML内容长度。Connection: close表示服务器在响应后会关闭连接,这可能是为了节省资源,或者是处理错误时的默认行为。 接下来看HTML部分,内容很简单,就是显示一个400错误页面。没有额外的信息,所以需要依赖响应头其他信息来分析问题。 现在需要思考用户可能遇到的情况。用户是在连接HTTP服务器时遇到这个问题,可能是在发送某个请求时触发了400错误。需要引导用户检查他们的请求是否符合HTTP标准,是否存在语法错误,比如请求行、请求头是否正确,或者请求体是否格式正确。 常见的具体原因可能包括: 1. URL格式不正确,比如包含非法字符或格式错误。 2. 请求头字段不正确,比如缺少必要的Host头,或者头字段值格式错误。 3. Cookie或授权头信息过大,超过服务器限制。 4. 请求体数据格式错误,比如JSON或表单数据不符合规范。 5. 使用了不被支持的HTTP方法,或者方法名拼写错误。 6. 请求中包含了无效的编码字符。 另外,用户可能使用了工具或代码发送请求,需要检查工具或代码是否正确生成请求。例如,使用curl命令时,是否正确转义了特殊字符;在编程时,是否设置了正确的请求头内容类型。 针对AWS的ELB,虽然大部分情况问题出在客户端,但也需要确认负载均衡器的配置是否正确,比如监听器协议端口是否正确,是否转发到了正确的后端实例。不过通常ELB不会导致400错误,除非后端实例返回了400,但ELB可能透传了该错误。 用户可能需要检查他们的请求是否符合RFC规范,使用工具如Postman或浏览器开发者工具查看实际发送的请求,对比是否与预期一致。此外,查看服务器日志可能会有更多线索,但如果是第三方服务,可能无法访问日志,这时候需要客户端详细检查。 总结下来,回复需要结构清晰,先解释每个响应字段的意义,然后列出可能的原因,最后给出排查步骤建议。需要避免技术术语过于复杂,用易懂的语言让用户理解问题所在,并提供可行的解决方案。</think>以下是HTTP 400 Bad Request错误响应的逐层解析及排查建议: --- ### **一、响应头关键字段解析** 1. **`HTTP/1.1 400 Bad Request`** - **核心含义**:服务器认为客户端请求存在语法或格式错误,无法解析或处理。 - **触发场景**:请求头/体格式错误、URL非法字符、请求体过大、缺少必要字段等。 2. **`Server: awselb/2.0`** - **标识服务器类型**:AWS Elastic Load Balancer(AWS弹性负载均衡器),表明请求由AWS负载均衡器代理,实际错误可能来自后端服务器。 3. **`Content-Type: text/html`** - **响应格式**:错误信息以HTML形式返回(默认浏览器展示界面)。 4. **`Connection: close`** - **连接行为**:服务器主动关闭TCP连接,防止无效请求占用资源。 --- ### **二、常见原因分类** #### 1. **客户端请求格式错误** - **URL问题**:包含非法字符(如未转义空格`%20`)、路径错误(如`http://domain.com//api`多斜杠)。 - **请求头缺失或错误**:缺少`Host`头、`Content-Length`与实际数据长度不匹配。 - **请求体格式错误**:JSON/XML语法错误、表单数据未编码(如未用`&`分隔键值对)。 #### 2. **服务器限制或配置** - **请求体过大**:超过服务器设置的`client_max_body_size`(如Nginx默认1MB)。 - **不支持的方法**:尝试使用非标准HTTP方法(如`PURGE`)或拼写错误(如`GETT`)。 #### 3. **代理/负载均衡器问题** - **AWS ELB配置**:监听器协议不匹配(如客户端用HTTP但ELB监听HTTPS)。 - **后端服务器超时**:后端未及时响应导致ELB返回400(需结合日志排查)。 --- ### **三、排查步骤** #### 1. **客户端请求验证** - **检查URL编码**:确保特殊字符(如`?`, `#`, `空格`)使用百分比编码(如`%20`)。 - **验证请求头**:强制添加`Host`头(某些服务器严格依赖),检查`Content-Type`与数据格式匹配。 - **简化请求**:逐步删除请求参数/头字段,定位具体错误位置。 #### 2. **工具辅助测试** - **使用`curl`模拟请求**(示例): ```bash curl -v -X POST http://example.com/api \ -H "Content-Type: application/json" \ -d '{"key": "value"}' ``` - **观察输出**:检查请求头响应细节(`-v`参数启用详细模式)。 - **浏览器开发者工具**:通过Network面板捕获原始请求头/体。 #### 3. **服务器端日志** - **AWS ELB日志**:启用访问日志(需配置S3存储桶),分析`client_error`类型错误。 - **后端服务器日志**:检查Nginx/Apache日志中的`400`错误记录及上下文。 --- ### **四、修复建议** 1. **标准化请求格式** - 使用工具(如Postman)生成规范请求模板。 - 对URL参数进行编码:`encodeURIComponent()`(JavaScript)或`urllib.parse.quote()`(Python)。 2. **缩小请求规模** - 分页处理大数据请求,或压缩请求体(如gzip)。 3. **检查代理配置** - 确认AWS ELB监听器协议与客户端一致(HTTP/HTTPS)。 - 验证后端服务器健康状态(ELB健康检查配置)。 --- ### **五、扩展知识** - **HTTP 400 vs 其他错误**: - `400 Bad Request`:客户端请求语法错误。 - `401 Unauthorized`:未提供有效身份凭证。 - `403 Forbidden`:服务器拒绝执行(权限不足)。 - `404 Not Found`:资源不存在。 - **AWS ELB行为**: ELB可能透传后端错误,也可能因自身配置(如SSL证书过期)返回4xx/5xx错误,需结合`X-Amz-Cf-Id`等头字段区分来源。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值