http请求报文和响应报文 Day4

说说http请求报文包含什么？

HTTP 请求报文由3部分组成（请求行+请求头+请求体）：

① 是请求方法，GET 和 POST 是最常见的 HTTP 方法，除此以外还包括 DELETE、HEAD、OPTIONS、PUT、TRACE。不过，当前的大多数浏览器只支持 GET 和 POST。
② 为请求对应的 URL 地址，它和报文头的 Host 属性组成完整的请求 URL。
③ 是协议名称及版本号。
④ 是 HTTP 的报文头，报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。
⑤ 是报文体，它将一个页面表单中的组件值通过 param1=value1的键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数，请求 URL 也可以通过类似于“/chapter15/user.html? param1=value1”的方式传递请求参数。

https://blog.csdn.net/Hardworking666/article/details/123833192

Content-Length知道吗？如果Content-Length的长度大于报文的实际长度，分析下会有什么问题？

Content-Length使用十进制的数字表示了消息的长度, 服务端/客户端通过它来得知后续要读取消息的长度.

Content-Length

Content-Length是HTTP消息长度, 用十进制数字表示的八位字节的数目, 是Headers中常见的一个字段. Content-Length应该是精确的, 否则就会导致异常 (特别地, HTTP1.0中这个字段可有可无).

Content-Length首部指示出报文中实体主体的字节大小. 这个大小是包含了所有内容编码的, 比如, 对文本文件进行了gzip压缩的话, Content-Length首部指的就是压缩后的大小而不是原始大小.

长度和报文长度不一致

Content-Length, HTTP消息长度, 用十进制数字表示的八位字节的数目. 一般情况下, 很多工作都被框架完成, 我们很少去关注这部分内容, 但少数情况下发生了Content-Length与实际消息长度不一致, 程序可能会发生比较奇怪的异常, 如:

无响应直到超时.
请求被截断, 而且下一个请求解析出现错乱.

如果Content-Length比实际的长度大, 服务端/客户端读取到消息结尾后, 会等待下一个字节, 自然会无响应直到超时.

如果这个长度小于实际长度, 首次请求的消息会被截取, 而第二次没有发生预期的截断, 而是服务端抛出了异常，上一次请求被截取剩下的消息, 在第二次次请求出现了。导致这种情况的原因就是开启了Connection:keep-alive, 如果使用Connection:close, 所产生的现象就是每一次的请求都被截断, 但不会产生解析混乱(如将上一次剩下的消息拼接到后续的请求消息中).

无法预知报文长度怎么办

Content-Length首部指示出报文中实体主体的字节大小. 但如在请求处理完成前无法获取消息长度, 我们就无法明确指定Content-Length, 此时应该使用Transfer-Encoding: chunked。
数据以一系列分块的形式进行发送. Content-Length 首部在这种情况下不被发送. 在每一个分块的开头需要添加当前分块的长度, 以十六进制的形式表示，后面紧跟着 \r\n , 之后是分块本身, 后面也是\r\n. 终止块是一个常规的分块, 不同之处在于其长度为0.

Content-Length如果存在且生效, 必须是正确的, 否则会发生异常.(大于实际值会超时, 小于实际值会截断并可能导致后续的数据解析混乱)
如果报文中包含Transfer-Encoding: chunked首部, 那么Content-Length将被忽略.

Http的请求报文和响应报文各有哪几部分组成

HTTP 的响应报文也由三部分组成（响应行+响应头+响应体）：

① 报文协议及版本；
② 状态码及状态描述；
③ 响应报文头，也是由多个属性组成；
④ 响应报文体，即我们真正要的“干货”。