应用层（二）——HTTP协议

最新推荐文章于 2024-05-10 18:11:25 发布

wanger61

最新推荐文章于 2024-05-10 18:11:25 发布

阅读量323

点赞数

分类专栏：计算机网络

本文链接：https://blog.csdn.net/wanger61/article/details/102837645

版权

计算机网络专栏收录该内容

12 篇文章 0 订阅

订阅专栏

应用层（二）

HTTP协议

HTTP请求报文

在这里插入图片描述

HTTP请求报文分为请求行，请求头，请求体：

请求行：

格式：请求方式资源路径协议/版本
例如：POST /chapter17/user.html HTTP/1.1
请求方式：

get请求:将请求参数追加在url后面，不安全
url长度限制get请求方式数据的大小
没有请求体
post请求：
请求参数在请求体处，较安全。
请求数据大小没有限制
head请求：
跟GET相似，不过服务端接收到HEAD请求时只返回响应头，不发送响应内容。
所以，如果只需要查看某个页面的状态时，用HEAD更高效，因为省去了传输页面内容的时间。
delete请求：
删除某一个资源。
OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*’的请求来测试服务器的功能性。
PUT：向指定资源位置上传其最新内容。
TRACE：回显服务器收到的请求，主要用于测试或诊断。
CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
PATCH：PATCH方法出现的较晚，它在2010年的RFC-5789标准中被定义。PATCH请求与PUT请求类似，同样用于资源的更新。二者有以下两点不同：
PATCH一般用于资源的部分更新，而PUT一般用于资源的整体更新。
当资源不存在时，PATCH会创建一个新的资源，而PUT只会对已在资源进行更新。

请求头：

Header	解释	示例
Accept	指定客户端能够接收的内容类型	text/plain, text/html
Accept-Charset	浏览器可以接受的字符编码集	iso-8859-5
Accept-Encoding	指定浏览器可以支持的web服务器返回内容压缩编码类型。	compress, gzip
Accept-Language	浏览器可接受的语言	en,zh
Accept-Ranges	可以请求网页实体的一个或者多个子范围字段	bytes
Cache-Control	指定请求和响应遵循的缓存机制	no-cache
Connection	表示是否需要持久连接。（HTTP 1.1默认进行持久连接）	close
Content-Length	请求的内容长度	348
Content-Type	请求的与实体对应的MIME信息	application/x-www-form-urlencoded
Date	请求发送的日期和时间	Tue, 15 Nov 2010 08:12:31 GMT
Host	指定请求的服务器的域名和端口号	www.zcmhi.com
If-Modified-Since	如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码（条件请求）	Sat, 29 Oct 2010 19:43:31 GMT
Pragma	用来包含实现特定的指令（缓存相关）	no-cache
Range	只请求实体的一部分，指定范围（断点传输）	bytes=500-999
Referer	先前网页的地址（防盗链）	http://www.zcmhi.com/archives/71.html
User-Agent	发出请求的用户信息	Mozilla/5.0 (Linux; X11)
Cookie	HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。	$Version=1; Skin=new;

请求体

当请求方式是post的时，请求体会有请求的参数，格式如下：username=zhangsan&password=123

HTTP响应报文

HTTP的响应报文：响应行，响应头，响应体
在这里插入图片描述

响应行：

格式：报文协议+状态码
状态码：
1xx：指示信息，表示请求已接收，继续处理

2xx：成功，表示请求已被成功接受，处理。
- 200 OK：客户端请求成功
- 204 No Content：无内容。服务器成功处理，但未返回内容。一般用在只是客户端向服务器发送信息，而服务器不用向客户端返回什么信息的情况。不会刷新页面。
- 206 Partial Content：服务器已经完成了部分GET请求（客户端进行了范围请求）。响应报文中包含Content-Range指定范围的实体内容
3xx：重定向
- 301 Moved Permanently：永久重定向，表示请求的资源已经永久的搬到了其他位置。
- 302 Found：临时重定向，表示请求的资源临时搬到了其他位置
- 303 See Other：临时重定向，应使用GET定向获取请求资源。303功能与302一样，区别只是303明确客户端应该使用GET访问
- 307 Temporary Redirect：临时重定向，和302有着相同含义。POST不会变成GET
- 304 Not Modified：表示客户端发送附带条件的请求（GET方法请求报文中的IF…）时，条件不满足。返回304时，不包含任何响应主体。虽然304被划分在3XX，但和重定向一毛钱关系都没有
  
  4xx：客户端错误
  - 400 Bad Request：客户端请求有语法错误，服务器无法理解。
  - 401 Unauthorized：客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
  - 403 Forbidden：资源不可用。服务器理解客户的请求，但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。
  - 404 Not Found：请求资源不存在。比如，输入了错误的url
  - 415 Unsupported media type：不支持的媒体类型
  5xx：服务器端错误，服务器未能实现合法的请求。
  - 500 Internal Server Error：服务器发生不可预期的错误。
  - 501 Not Implemented：服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求。
  - 502 Bad Gateway 服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。
  - 503 Server Unavailable：务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头。
  - 504 Gateway Timeout 由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。（HTTP 1.1新）
  - 505 HTTP Version Not Supported 服务器不支持请求中所指明的HTTP版本。（HTTP 1.1新）
    ————————————————
    版权声明：本文为CSDN博主「有抱负的小狮子」的原创文章，原文链接：https://blog.csdn.net/weixin_38087538/article/details/82838762

响应头：

Header	解释	示例
Accept-Ranges	表明服务器是否支持指定范围请求及哪种类型的分段请求	bytes
Cache-Control	告诉所有的缓存机制是否可以缓存及哪种类型	no-cache
Content-Location	请求资源可替代的备用的另一地址	/index.htm
Content-Range	在整个返回体中本部分的字节位置	bytes 21010-47021/47022
Expires	响应过期的日期和时间	Thu, 01 Dec 2010 16:00:00 GMT
Location	用来重定向接收方到非请求URL的位置来完成请求或标识新的资源	http://www.zcmhi.com/archives/94.html
refresh	应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）	5; url=http://www.zcmhi.com/archives/94.html
Set-Cookie	设置Http Cookie	UserID=JohnDoe; Max-Age=3600; Version=1
Content-Disposition	通过浏览器以下载方式解析正文取值	attachment;filename=xx.zip
Server	web服务器软件名称	Apache/1.3.27 (Unix) (Red-Hat/Linux)

更多请求头属性可以参考这篇文章:http://tools.jb51.net/table/http_header

Content-Type详解

在这里插入图片描述

application/x-www-form-urlencoded

最常见的post提交数据的方式。浏览器原生的form表单，如果不设置enctype属性，那么最终就会以application/x-www-form-urlencoded 方式提交数据
提交的数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。大部分服务端语言都对这种方式有很好的支持。

很多时候，我们用 Ajax 提交数据时，也是使用这种方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默认「application/x-www-form-urlencoded;charset=utf-8」。

multipart/form-data

使用表单上传文件时，必须让 form 的 enctyped 等于这个值。


POST http://39.108.107.149:8080/vk/app/rest/ddp/iDataSourcesBaseService/file HTTP/1.1
Content-Type: multipart/form-data; boundary=--------------------------629236571647111133881449
cache-control: no-cache
Postman-Token: 2146b4b3-2d30-469c-bbcd-fbc4693934d9
User-Agent: PostmanRuntime/7.1.1
Accept: */*
Host: 39.108.107.149:8080
cookie: JSESSIONID=6CD80B7028062D9190717CEE001C3194
accept-encoding: gzip, deflate
content-length: 435
Connection: keep-alive
 
----------------------------629236571647111133881449
Content-Disposition: form-data; name="file"; filename="test.txt"
Content-Type: text/plain
 
test upload
----------------------------629236571647111133881449
Content-Disposition: form-data; name="extCode"
 
test
----------------------------629236571647111133881449
Content-Disposition: form-data; name="extId"
 
3306

----------------------------629236571647111133881449--  //结束标识
————————————————

首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 mutipart/form-data 来编码，本次请求的 boundary 是什么内容。

消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着内容描述信息，然后是回车，最后是最后是字段具体内容（文本或二进制），如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。

上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，而且现阶段原生 form 表单也只支持这两种方式。但是随着越来越多的 Web 站点，尤其是 WebApp，全部使用 Ajax 进行数据交互之后，我们完全可以定义新的数据提交方式，给开发带来更多便利。
————————————————

application/json

用来告诉服务端消息主体是序列化后的 JSON 字符串


POST http://39.108.107.149:8080/vk/app/rest/ddp/vkIndexsService/queryVkIndxs HTTP/1.1
Content-Type: application/json
cache-control: no-cache
Postman-Token: 5014bc39-0777-49d5-bb8a-73db9a981e49
User-Agent: PostmanRuntime/7.1.1
Accept: */*
Host: 39.108.107.149:8080
cookie: JSESSIONID=6CD80B7028062D9190717CEE001C3194
accept-encoding: gzip, deflate
content-length: 132
Connection: keep-alive
 
{
    "name":"828验证继承",
    "getresultType":"2",
    "createTime":"Tue Sep 11 2018 00:00:00 GMT+0800 (中国标准时间)"
}
这种方案，可以方便的提交复杂的结构化数据，特别适合 RESTful 的接口。各大抓包工具如 Chrome 自带的开发者工具、Firebug、Fiddler，都会以树形结构展示 JSON 数据，非常友好

 
————————————————

text/xml

版权声明：本文为CSDN博主「有抱负的小狮子」的原创文章
原文链接：https://blog.csdn.net/weixin_38087538/article/details/82838762

wanger61

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
应用层（二）——HTTP协议

应用层（二）HTTP协议HTTP请求报文HTTP请求报文分为请求行，请求头，请求体：请求行：格式：请求方式资源路径协议/版本例如：POST /chapter17/user.html HTTP/1.1请求方式：get请求:将请求参数追加在url后面，不安全url长度限制get请求方式数据的大小没有请求体post请求：请求参数在请求体处，较安全。请求数据大小没有...
复制链接

扫一扫

专栏目录