HTTP协议中的“报头”(header)和 “正文“ (body)详解

简介: HTTP协议中的“报头”(header)和 “正文“ (body)详解

一、请求“报头”(header)详解


header 的整体的格式也是 "键值对" 结构. 每个键值对占一行. 键和值之间使用 冒号+空格 分割。报头的种类有很多, 下面仅介绍几个常见的.


1. Host


例: Host: www.bilibili.com


描述了服务器主机的地址/端口号,其中地址可以是域名,也可以是IP,Host这里的内容是和首行中的URL中表示得服务器地址是基本是一样的


1667912205426.jpg


2.Content-Length


表示 body 中的数据长度,单位是字节。如果没有body(GET),此时也就可以没有Content-Length。


3.Content-Type


表示请求的 body 中的数据格式,form (application/x-www-form-urlencoded)表单提交的数据格式 . 此时 body 的格式形如: title=test&content=hello,这种格式和query string 是差不多的;

form(multipart/form-data) 表单提交的数据格式(在 form 标签中加上 enctyped="multipart/form - data"),一般用于提交图片或者文件,此时body的格式如下:

1667912219628.jpg

application/json: 数据为 json 格式. body 格式形如:

{"username":"123456789","password":"xxxx","code":"jw7l","uuid":"d110a05ccde64b16
a861fa2bddfdcd15"}

关于 Content-Type 的详细情况 :

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types

4.User-Agent (简称 UA)

UA就描述了系统+浏览器的版本信息

1667912261379.jpg

关于UA,随着浏览器的逐渐升级,面对更加丰富的前后端交互,不同浏览器所支持的功能不一样,那么程序员就会根据对方的浏览器不同,来决定返回一个对应的页面。


但是随着时间的推移,目前的浏览器都已经差别不大了,那么此时UA又有一个新的作用,那就是区别PC端和移动端,因为pc端和移动端的网页排版是不一样的。但是通过UA来区分是手机还是电脑,来返回不同板式的页面,这虽然是一种实现方式,但是这似乎对程序员不太友好,因为需要同时维护两个版本的代码。现在更加主流的实现方式是“响应式布局”,大概就是基于CSS3中的“媒体查询功能”,大概就是能够获取到当前页面的宽度,然后根据宽度来决定样式,从而达到一份代码可以适用于不同宽度的屏幕。


5. Referer

表示这个页面是从哪个页面跳转过来的,形如:

1667912272292.jpg

注意:如果直接在浏览器中输入URL, 或者直接通过收藏夹访问页面时是没有 Referer 的.


Referer其实可以用到网站搜索广告的点击计费模式。


6.Cookie


Cookie 的值是一个字符串(程序员自己定义的),Cookie相当于浏览器这边进行本地存储的一种机制。


1667912284615.jpg


一般Cookie用来存储用户的登陆信息,比如用户名和密码。当你后续继续访问的时候,这个时候浏览器会自动的把保存的值给带上,往往可以通过这个字段实现 "身份标识" 的功能。


一下是大概就是登陆以及访问过程:


1667912298950.jpg


这里就会衍生一个问题,就是浏览器能不能把信息写到磁盘里面?答案是,绝对不能!!!


因为这样会有非常大的风险,如果有病毒,那么就直接入侵你的电脑了!因此Cookie就是解决这一问题的的一种机制,这也是浏览器提供的一种机制。


但是现在的浏览器,有更多的本地存储机制了,现在的网页也不完全依赖Cookie了。比如:


1. LocalStorage


HTML5开始引入的一个机制,浏览器支持 一种“键值对”方式来进行存储,通过JS提供了一组API来操作数据。


2. IndexDB


这是比较新的浏览器才支持的机制,浏览器内部集成了一个“数据库”,支持类似于sql的方式来进行操作数据。    


二、请求 "正文" (body)详解


正文(body)中的内容格式和 header 中的 Content-Type 密切相关。具体的可以通过抓包来观察。


三、响应 "报头" (header)详解


响应报头的基本格式和请求报头的格式基本一致。


四、响应 "正文" (body)详解


与请求正文格式基本一致,正文的具体格式取决于 Content-Type。


响应中的 Content-Type 常见取值有以下几种 :

text/html:body 数据格式是 HTML

text/css:body 数据格式是 CSS

application/javascript:body 数据格式是 JavaScript

application/json:body 数据格式是 JSON


相关文章
|
2月前
|
缓存 监控 搜索推荐
301重定向实现原理全面解析:从HTTP协议到SEO最佳实践
301重定向是HTTP协议中的永久重定向状态码,用于告知客户端请求的资源已永久移至新URL。它在SEO中具有重要作用,能传递页面权重、更新索引并提升用户体验。本文详解其工作原理、服务器配置方法(如Apache、Nginx)、对搜索引擎的影响及最佳实践,帮助实现网站平稳迁移与优化。
446 68
|
1月前
HTTP协议中请求方式GET 与 POST 什么区别 ?
GET和POST的主要区别在于参数传递方式、安全性和应用场景。GET通过URL传递参数,长度受限且安全性较低,适合获取数据;而POST通过请求体传递参数,安全性更高,适合提交数据。
343 2
|
2月前
|
存储 网络协议 安全
HTTP 协议及会话跟踪机制详解
本文详解了 HTTP 协议的核心知识,包括其定义(超文本传输协议,基于 TCP,规定客户端与服务器通信规则)及与 HTTPS 的区别(安全性、端口、资源消耗)。 介绍了 GET 与 POST 请求的差异(参数限制、安全性、应用场景),以及 Restful 风格(通过 URL 定位资源,请求方式决定操作)。列举了常见 HTTP 状态码(如 200 成功、404 资源未找到),对比了转发与重定向的区别(服务器端一次请求 vs 客户端两次请求)。 还阐述了会话跟踪机制:Cookie 基于客户端存储,通过Set-Cookie和Cookie头实现,安全性较低;Session 基于服务端存储,依赖 C
239 1
|
1月前
|
缓存 网络协议 UED
深度解析HTTP协议从版本0.9至3.0的演进和特性。
总的来说,HTTP的演进是互联网技术不断发展和需求日益增长的结果。每一次重要更新都旨在优化性能,增进用户体验,适应新的应用场景,而且保证了向后兼容,让互联网的基础架构得以稳定发展。随着网络技术继续进步,我们可以预期HTTP协议在未来还会继续演化。
339 0
|
2月前
|
XML 安全 网络架构
深度对比SOAP与HTTP协议:详细理解它们的工作原理和差异
在设计服务和系统交云策略时,考虑到上述差异是至关重要的。SOAP适合需要高安全性、可靠性和事务支持的企业级应用。而HTTP适合Web界面浏览、RESTful服务和需要快速响应的轻量级通信。根据具体需求和上下文,开发者可以选择合适的协议以实现最优的系统性能和用户体验。
300 0
|
3月前
|
缓存
HTTP协议深度剖析:常见请求头信息讲解
这就是HTTP请求头背后的工作原理,希望通过比作“邮差”和“标签”,可以让你对这个繁琐技术更有感触,更得心应手。尽管这些信息可能很琐碎,但了解了它们的含义和工作方式,就等于揭开了HTTP协议神秘的面纱,掌控了网络交流的核心。你还等什么,赶快动手尝试一下吧!
132 17
|
2月前
HTTP协议中常见的状态码 ?
HTTP协议状态码分为1xx、2xx、3xx、4xx、5xx五类。常见状态码包括:101(切换协议)、200(请求成功)、302(重定向)、401(未认证)、404(资源未找到)、500(服务器错误)。
280 0
|
3月前
|
存储 缓存 前端开发
http协议调试代理工具,Fiddler免费版下载,抓包工具使用教程
Fiddler是一款功能强大的HTTP协议调试代理工具,能记录并检查电脑与互联网间的HTTP通信,支持断点设置和数据编辑。相比其他网络调试器,Fiddler操作更简单且用户友好,支持查看Cookie、HTML、JS、CSS等文件内容。它还具备HTTPS抓包、过滤设置、统计页面总重量等功能,适用于安全测试与功能测试。通过插件扩展,用户可自定义视图或分析缓存行为。支持多种HTTP请求方法(如GET、POST等)及状态码分类(1xx-5xx),是开发者调试网络请求的得力工具。同类工具有HttpWatch、Firebug、Wireshark等。
383 1
|
3月前
|
网络协议 算法 调度
深入探讨HTTP/2.0协议的细节
在理解了所有这些细节后,你现在应该更加清楚HTTP/2.0是如何让数据高效地在互联网上快速移动的。而这只是一个简化的类比,实际的技术细节和协议规范更加丰富和复杂。随着时间的推移,HTTP/2.0的实现将继续优化,为我们提供更可靠、高效的网络体验。
81 0