共计 1194 个字符，预计需要花费 3 分钟才能阅读完成。
这篇文章给大家介绍 http 请求如何确定边界，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
S3 上传有两种 method 方式 PUT 请求：这个上传请求上传对象协议明确携带 Content-length 的；POST 请求：这个不要求知名 Content-length，而是通过一种流式的数据传输，但是总归还是要知道边界在哪里？有以下几种方式让服务端知道数据的边界； HTTP 数据怎么确定边界？
S3 是基于 HTTP 的协议，HTTP 是基于 TCP 协议的应用层协议，而 TCP 是面向数据流的协议，是没有边界的。HTTP 作为应用层协议需要自己明确定义数据边界。
HTTP 边界判定由于 http1.1 协议之后，http 可以是一个 keep-alive 的，可以是一个流式协议。那么我们需要有办法去标识 body 边界，有三种方式：
http 包头部显式设置 Content-Lengthhttp 传输编码方式用 Transfer-Encoding: chunked 短连接（连接断开）（第 3 种情况，一般作为异常场景看待。所以下面我们就讨论前两种情况）
这两种情况都取决于客户端的协议是否遵守。正常情况，如果传输了 Content-Length，就要和 body 一致。如果头部没有这个字段，那么也可以客户端采用 Transfer-Encoding：chunked 的编码方式传输 body，也能让服务器正确的识别 body 的边界。
分四种情况讨论
情况一：如果只设置了 Content-Length，但是 body 不准，怎么办？
Content-Length 比 body 大？服务器一般实现会设置一个超时。服务端主动断开连接，报告超时。这个当前线上系统由 nginx 完成，1 分钟超时。客户端自己 ctrl+c，客户端主动断开连接服务一般是卡主，服务器等待读完客户端声明的数据。解决方法两种：Content-Length 比 body 小？请求成功，数据截断
情况二：如果没有 Content-Length，设置了 Transfer-Encoding：Chunked？
这个时候能正确识别到边界，以 Chunked 模式为准。有无 Content-Length 没区别。就算设置了 Content-Length，也不会依赖用这个值，不准也没关系。只要是按照 chunked 的模式，以实际取到的 body 为准。
情况三：Content-Length 和 Transfer-Encoding 都设置？
以 chunked 传输为准。
情况四：Content-Length 和 Transfer-Encoding 都没设置？
这种情况和 Content-Length= 0 是一样处理的。
截图示例 Chunked 的包
Content-Length 的包
关于 http 请求如何确定边界就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
