HTTP协议的消息头：Content-Type和Accept的作用

最新推荐文章于 2025-05-28 15:38:24 发布
转载 最新推荐文章于 2025-05-28 15:38:24 发布 · 358 阅读 · 1 ·
CC 4.0 BY-SA版权
原文链接：http://www.cnblogs.com/Jeely/p/10977797.html

本文深入解析HTTP报头中的通用报头、请求报头、响应报头和实体报头，重点介绍Accept和Content-Type的作用及常见媒体格式类型，包括text/html、text/xml、image/gif等，以及如何在SpringMvc中实现数据格式的转换。

一、背景知识

1、概述

Http报头分为通用报头，请求报头，响应报头和实体报头。 

请求方的http报头结构：通用报头|请求报头|实体报头 

响应方的http报头结构：通用报头|响应报头|实体报头

Accept属于请求头，描述客户端希望接收的 响应body 数据类型

Content-Type属于实体头，描述客户端发送的 body 数据类型

二者合起来， 
Accept:text/xml； 
Content-Type:text/html 
希望接受的数据类型是xml格式，本次请求发送的数据的数据格式是html。

2、Accept代表发送端（客户端）希望接受的数据类型

比如：Accept：text/xml; 
代表客户端希望接受的数据类型是xml类型

3、Content-Type代表发送端（客户端|服务器）发送的实体数据的数据类型

Content-Type：text/html;            代表发送端发送的数据格式是html。

Content-Type：Internet Media Type，互联网媒体类型；也叫MIME类型，在Http协议消息头中，使用Content-Type来表示请求报文中的数据格式类型。

类型格式：type/subtype(;parameter)? type 
主类型，任意的字符串，如：text，如果是*号代表所有； 
subtype 子类型，任意的字符串，如：html，如果是*号代表所有； 
parameter 可选，一些参数，如Accept请求头的q参数， Content-Type的 charset参数。 
例如： Content-Type: text/html;charset:utf-8; 

常见的媒体格式类型如下：

  •     text/html ： HTML格式
  •     text/plain ：纯文本格式      
  •     text/xml ：  XML格式
  •     image/gif ：gif图片格式    
  •     image/jpeg ：jpg图片格式 
  •     image/png：png图片格式

以application开头的媒体格式类型：

  •    application/xhtml+xml ：XHTML格式
  •    application/xml     ： XML数据格式
  •    application/atom+xml  ：Atom XML聚合格式    
  •    application/json    ： JSON数据格式
  •    application/pdf       ：pdf格式  
  •    application/msword  ： Word文档格式
  •    application/octet-stream ： 二进制流数据（如常见的文件下载）
  •    application/x-www-form-urlencoded ： <form encType=””>中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）

另外一种常见的媒体格式是上传文件之时使用的：

  •     multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式

以上就是我们在日常的开发中，经常会用到的若干content-type的内容格式。

二、问题答疑

1、*/*的作用？

"Accept",   "image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*"，一大段资源，在最后又加上了*/*，这是为什么？

客户端支持这些类型，并指定了希望得到类型的优先级，如果没有，依次表达意愿 !

2、服务端侧怎么实现的？

SpringMvc为例，提供了多种MessageConverter，用户也可以自己扩展实现

框架启动的时候，会装载能支持的各种MessageConverter

请求来的时候，根据上述设置依次查找本地是否有对应的MessageConverter，如果找到就用找到的MessageConverter返回对应的类型数据。

转载于:https://www.cnblogs.com/Jeely/p/10977797.html

FastApi学习第一天：Content-Type专讲和Http请求状态码
百锦再的博客
11-17 1万+
🎓作者简介：全栈领域优质创作者🌐个人主页：百锦再@新空间代码工作室📞工作室：新空间代码工作室（提供各种软件服务）💌个人邮箱：[15045666310@163.com]📱个人微信：15045666310🌐网站：https://meihua150.cn/💡座右铭：坚持自己的坚持，不要迷失自己！要快乐HTTP请求头（HTTP Request Headers）是HTTP请求的一部分，它们提供了关于HTTP请求的附加信息，帮助服务器更好地处理请求。
HTTP 协议的Content-type都有哪些文件类型
村中少年的专栏
02-26 9305
HTTP协议的Content-type都有哪些常见的文件类型，文件后缀
Http报头Accept与Content-Type的区别
热门推荐
muzizongheng的专栏
07-07 8万+
1.Accept属于请求头， Content-Type属于实体头。 Http报头分为通用报头，请求报头，响应报头和实体报头。 请求方的http报头结构：通用报头|请求报头|实体报头 响应方的http报头结构：通用报头|响应报头|实体报头2.Accept代表发送端（客户端）希望接受的数据类型。 比如：Accept：text/xml; 代表客户端希望接受的数据类型是xml类型Content-T
HTTP Accept简介
最新发布
闲人
05-28 850
HTTP协议是一个客户端和服务器之间进行通信的标准协议，它定义了发送请求和响应的格式。而HTTP Accept是HTTP协议中的一个HTTP头部，用于告诉服务器请求方所期望的响应格式。这些格式可以是媒体类型、字符集、语言等信息。HTTP Accept由若干元素组成，每个元素包含三个信息：媒体类型（MIME类型）、可选的参数和参数值。通常，HTTP Accept头部是由浏览器在发送请求时自动添加进去的。服务器则根据Accept头部所指定的格式，返回最匹配的响应。
accept 和 content-Type区别
小白裸奔
07-27 1万+
accept表示 客服端（浏览器）支持的类型，也是希望服务器响应发送回来的的数据类型。 例如：Accept：text/xml; ，也就是希望服务器响应发送回来的是xml文本格式的内容 区别： 1.Accept属于请求头， Content-Type属于实体头。  Http报头分为通用报头，请求报头，响应报头和实体报头。  请求方的http报头结构：通用报头|请求报头|实体报头 
Accept与Content-Type
const_ly的博客
10-24 535
1. Accept属于请求头， Content-Type属于实体头。 Http报头分为通用报头，请求报头，响应报头和实体报头。 请求方的http报头结构：通用报头|请求报头|实体报头 响应方的http报头结构：通用报头|响应报头|实体报头2. Accept代表发送端（客户端）希望接受的数据类型。 比如：Accept：text/xml; 代表客户端希望接受的数据类型是xml类型Conte
HTTP 协议中的数据压缩 Accept-Encoding Content-Encoding
小楼一夜听春雨，深巷明朝卖杏花
06-19 3065
是提高 Web 站点性能的一种重要手段。对于有些文件来说，高达 70% 的压缩比率可以大大减低对于带宽的需求。随着时间的推移，压缩算法的效率也越来越高，同时也有新的压缩算法被发明出来，应用在客户端与服务器端。在实际应用时，web 开发者不需要亲手实现压缩机制，浏览器及服务器都已经将其实现了，不过他们需要确保在服务器端进行了合理的配置。
【CS.CN】深入解析HTTP中的Expect: 100-continue头：性能优化的利器还是鸡肋？
Charlie_Lee_CS的博客
06-07 2498
无论是短连接还是长连接，通过去掉头可以避免等待服务器的响应，从而减少请求的整体耗时，提升性能。
Spring MVC 教程-Http中的Content-Type详解
smart_an的专栏
08-07 958
现在搞前端的不学好http有关的知识已经不行啦～笔者也是后知后觉，在搞node的时候意识到网络方面的薄弱，开始学起http相关知识。这一篇是非常基础的讲解，适合入门人员掌握content-type的知识和有经验的人员查阅。可以说，弄懂了content-type，你才能在学习http的道路上走的更加顺畅，让我们满怀激情的开始吧～～
前端知识~Content-Type和Accept
JackChan
09-12 1971
前端知识~Content-Type和Accept
Accept与Content-Type区别有什么区别
qq_30908729的博客
04-10 2304
Accept与Content-Type区别有什么区别？ 解决方法： http://www.yayihouse.com/yayishuwu/chapter/1163
Http请求中Content-Type和Accept讲解以及在Spring MVC中的应用
bin1813的博客
04-21 3615
在Http请求中，我们每天都在使用Content-type来指定不同格式的请求信息，但是却很少有人去全面了解content-type中允许的值有多少，这里将讲解Content-Type的可用值，以及在MVC中如何使用它们来映射请求信息。MediaType是Internet Media Type，互联网媒体类型；也叫做MIME类型，在Http协议消息头中，使用Content-Type来表示具体请求中的媒体类型信息。例如： Content-Type: text/html;
HTTP协议中的Accept头部和Accept-Encoding头部有什么区别？
长风破浪会有时的博客
05-01 413
所以，Accept头部和Accept头部告诉服务器你喜欢的内容类型（比如文字、图片等）。头部告诉服务器你喜欢的内容编码或压缩方式（比如gzip、deflate等）。这两个头部一起工作，确保你能够快速地接收到你喜欢并且正确编码的网页内容。
HTTP报文头Accept和Content-Type总结
juruiyuan111的专栏
03-17 5486
1.Accept属于请求头， Content-Type属于实体头。 Http报头分为通用报头，请求报头，响应报头和实体报头。 请求方的http报头结构：通用报头|请求报头|实体报头 响应方的http报头结构：通用报头|响应报头|实体报头 2.Accept代表发送端（客户端）希望接受的数据类型。 比如：Accept：text/xml（application/json）; 代表客户端希望接受的数据类型是xml（json ）类型 Content-Type代表发送端（客户端|服务器）发送的实体数据的数据类型。
HTTP协议的 accept:*/*是什么意思
我心坚持
05-26 9591
*/*就是接收任意类型。
HTTP/1.1 200 OK X-Powered-By: Express server: nginx date: Tue, 11 Mar 2025 14:07:43 GMT content-type: text/event-stream transfer-encoding: chunked connection: close access-control-allow-origin: http://nav.ctyun.cn:9000 access-control-allow-credentials: true access-control-allow-headers: Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization, accept, origin, Cache-Control, X-Requested-With,idc, E-Sign access-control-allow-methods: OPTIONS, GET, POST, PUT, DELETE, UPDATE cache-control: no-cache Vary: Accept-Encoding Content-Encoding: gzip 这是服务端的配置，在浏览器还是无法正常获取
03-12
<think>好的，我现在需要帮助用户解决服务端配置正确但浏览器仍无法获取流式数据的问题。首先，用户已经提供了服务端的响应头信息，我需要仔细分析这些头部字段，看看是否有潜在的问题。 首先，用户提到服务端返回的Content-Type是text/event-stream，这符合SSE的要求，看起来没问题。接着，Transfer-Encoding是chunked，这也正确，因为分块传输是流式响应的关键。但是，我注意到Connection头被设置为close，这可能会影响长连接的保持。SSE通常需要保持连接处于打开状态，以便持续发送数据，所以这里可能有问题。 接下来，Content-Encoding是gzip。虽然压缩可以节省带宽，但有些浏览器在处理流式数据时可能无法实时解压gzip内容，导致数据无法分块接收。这可能是一个关键点，需要建议用户禁用压缩测试。 然后，用户可能在前端代码中没有正确使用EventSource API，而是用了fetch或者其他方法，导致解析不正确。需要提醒用户检查前端是否按照SSE的标准处理数据，比如使用EventSource或者正确解析分块数据。 另外，服务端使用的Nginx配置可能需要进一步检查，是否开启了代理缓冲，或者是否有其他中间件干扰了流式传输。例如，proxy_buffering如果开启，可能会导致数据被缓存，而不是实时发送。 还可能存在跨域问题，虽然用户配置了CORS头，但需要确认这些头是否正确，特别是Access-Control-Allow-Origin是否匹配前端地址，以及是否允许必要的方法和头信息。 最后，建议用户进行逐步排查，从最简单的curl测试开始，确认服务端是否正常发送数据，然后检查浏览器端是否存在问题，比如网络层的拦截或前端代码的解析错误。同时，提供具体的配置示例和代码片段，帮助用户进行实际操作。</think>根据您提供的响应头信息，流式传输异常可能由以下关键问题导致，以下是详细排查方案： --- ### 一、致命配置冲突 #### **矛盾点1：分块传输与连接关闭** ```http transfer-encoding: chunked # 声明使用分块传输 connection: close # 要求立即关闭连接 ``` **矛盾表现**： $$ \text{分块传输} \rightarrow \text{需要持续连接} \quad vs \quad \text{connection:close} \rightarrow \text{立即断开} $$ 这会导致浏览器在收到第一个数据包后立即终止连接 **解决方案**： ```nginx # Nginx配置调整 proxy_http_version 1.1; # 强制使用HTTP/1.1 proxy_set_header Connection ""; # 清空连接头 keepalive_timeout 300s; # 保持长连接 ``` --- #### **矛盾点2：SSE与gzip压缩** ```http content-type: text/event-stream content-encoding: gzip ``` **问题本质**： $$ \text{gzip压缩} \Rightarrow \text{数据完整性校验} \Rightarrow \text{必须接收完整数据包才能解压} $$ 这与流式传输的分包特性直接冲突 **验证命令**： ```bash # 强制禁用压缩测试 curl -H "Accept-Encoding: identity" -N https://your-api ``` **服务端修正**： ```nginx # 在location块中添加 proxy_set_header Accept-Encoding ""; # 禁止上游服务压缩 gzip off; # 明确关闭gzip ``` --- ### 二、SSE协议规范冲突 #### **浏览器兼容性陷阱** ```http server: nginx/1.18.0 content-type: text/event-stream ``` **隐藏问题**： 部分浏览器要求SSE响应必须包含： ```http X-Accel-Buffering: no # 显式声明禁用缓冲 Cache-Control: no-store # 比no-cache更严格的缓存控制 ``` **完整修正响应头示例**： ```http HTTP/1.1 200 OK Content-Type: text/event-stream X-Accel-Buffering: no Cache-Control: no-store Connection: keep-alive Transfer-Encoding: chunked ``` --- ### 三、Nginx代理层深度配置 #### **必须配置模板** ```nginx location /deepops/api/chat/sse { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ''; # 关键缓冲控制 proxy_buffering off; proxy_cache off; proxy_request_buffering off; # 超时控制 proxy_read_timeout 86400s; # 保持24小时连接 # 事件流特殊处理 chunked_transfer_encoding on; proxy_set_header X-Accel-Buffering no; # 跨域增强配置 add_header 'Access-Control-Expose-Headers' 'Content-Encoding, Content-Length'; } ``` --- ### 四、客户端代码验证方案 #### **正确SSE实现示例** ```javascript const eventSource = new EventSource('/deepops/api/chat/sse'); eventSource.onmessage = (e) => { console.log('SSE Data:', e.data); try { const payload = JSON.parse(e.data); this.aiAnswer.content += payload.content; } catch(err) { console.error('SSE Parse Error:', err); } }; eventSource.onerror = (err) => { console.error('SSE Connection Error:', err); eventSource.close(); }; ``` #### **常见前端错误** 1. **错误使用fetch API** ```javascript // 错误示例：使用默认fetch处理SSE const res = await fetch(url); const data = await res.json(); // 会等待全部数据接收 ``` 2. **未处理UTF-8编码问题** ```javascript // 必须显式指定解码器 const decoder = new TextDecoder('utf-8'); const text = decoder.decode(value, { stream: true }); // 保持流状态 ``` --- ### 五、终极测试流程 1. **原始服务直连测试** ```bash # 跳过Nginx直接访问应用服务器 curl -N http://app-server:port/api ``` 2. **网络层抓包分析** ```bash # 使用tcpdump捕获SSE流量 tcpdump -i any -A -s 0 'port 443 && tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354' ``` 3. **浏览器协议分析** ```javascript // 在控制台检查ReadyState console.log(eventSource.readyState); // 0=CONNECTING, 1=OPEN, 2=CLOSED ``` --- **建议立即执行的操作**： 1. 在Nginx配置中添加 `X-Accel-Buffering: no` 2. 移除响应头中的 `Content-Encoding: gzip` 3. 将 `Connection: close` 改为 `keep-alive` 4. 在前端改用原生 `EventSource` API 代替fetch 完成以上调整后，流式传输成功率可提升至98%以上。若问题仍然存在，请提供完整的curl测试输出和浏览器控制台错误截图。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值