HTTP范围请求多部分/byteranges-末尾是否有CRLF？

除了行尾之外，其他的都很清晰

我对

多部分/byteranges

响应的HTTP响应体特别感兴趣。我假设每一行都像HTTP头一样由CRLF终止，但本文并没有明确说明这一点。我完全困惑的是最后一行：

——这个分隔符分隔了--

。它后面是CRLF吗

完整块：

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

很抱歉，我真的找不到它，非常感谢您的帮助。 注意：请不要凭直觉，只有RFC参考。

该规范参考：

其中明确规定：

边界分隔符必须出现在行首，即。， 在CRLF之后，初始CRLF被视为已附加
到边界分隔符行，而不是前面的一部分
部分边界后面可以有零个或多个字符
线性空白。然后由另一个CRLF和
下一部分的标题字段，或两个CRLF，在这种情况下
下一部分没有标题字段。如果没有内容类型
如果存在字段，则假定该字段为a中的“消息/rfc822”
否则为“多部分/摘要”和“文本/普通”

---

如果您更仔细地阅读RFC 7233，请参阅以了解HTTP正文中MIME数据的实际格式：

当206（部分内容）响应消息包括 多个范围，它们作为身体部位在多部分中传输 媒体类型为的消息正文（[RFC2046]，第5.1节） “多部分/byteranges”

RFC 2046第5.1节定义了“多部分”媒体类型的正式定义及其边界的格式化和解析方式

为了回答您的问题，以下是RFC 2046的正式语法：

The boundary delimiter MUST occur at the beginning of a line, i.e., following a CRLF, and the initial CRLF is considered to be attached to the boundary delimiter line rather than part of the preceding part. The boundary may be followed by zero or more characters of linear whitespace. It is then terminated by either another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part. If no Content-Type field is present it is assumed to be "message/rfc822" in a "multipart/digest" and "text/plain" otherwise. NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary. 边界分隔符必须出现在行首，即。， 在CRLF之后，初始CRLF被视为已连接 到边界分隔符行，而不是前一行的一部分 部分边界后面可以跟零个或多个字符 线性空白。然后由另一个CRLF和 下一部分的标题字段，或由两个CRLF组成，在这种情况下 下一部分没有标题字段。如果没有内容类型 如果存在字段，则假定字段中为“message/rfc822” 否则为“多部分/摘要”和“文本/普通”。 注意：边界分隔线之前的CRLF在概念上是 连接到边界，以便可以有一个 不以CRLF（换行符）结束。必须更换的身体部位 因此，被认为以换行结束，必须有两个CRLF 位于边界分隔符行之前，其中第一行是 身体的前一部分，第二部分是身体的一部分 封装边界。

最后一个主体部分后面的边界分隔线是 可分辨分隔符，指示没有其他正文部分 接下来就是。这样的分隔符行与前面的相同 分隔符行，在 边界参数值。 --gc0pJq0M:08jU534c0p-- 实现者注意：边界字符串比较必须比较 每个候选行开头的边界值。精确的 不需要匹配整个候选行；这就足够了 边界在CRLF之后整体出现。

“multipart”媒体类型的唯一必需全局参数是 边界参数，由来自 通过邮件网关已知非常健壮的字符集，以及 不以空格结尾。（如果显示边界分隔符行 以空格结尾，空格必须假定为 由网关添加，并且必须删除。）它是正式指定的 由下列BNF： 边界：=0*69 bcharsnospace bchars:=bcharsnospace/“” bcharsnospace:=数字/ALPHA/“/”（“/”）/ "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?" 总的来说，“多部分”实体的主体可以指定为 跟随： 破折号边界：=“--”边界 ; 边界取自 ; 边界参数 ; 内容类型字段。 多部分正文：=[前导码CRLF] 仪表板边界传输填充CRLF 身体部位*封装 关闭分隔符传输填充 [CRLF结语] 传输填充：=*LWSP字符 ; 作曲者不得生成 ; 非零长传输 ; 填充，但接收器必须 ; 能够处理填充 ; 由消息传输添加。 封装：=分隔符传输填充 CRLF车身部件 分隔符：=CRLF破折号边界 关闭分隔符：=分隔符“-” 序言：=放弃文本 结语：=放弃文本 丢弃文本：=*（*文本CRLF）*文本 ; 可能被忽略或丢弃。 主体部分：=MIME部分标题[CRLF*八位字节] ; 身体部位中的线条不得开始 ; 具有指定的破折号边界，并且 ; 分隔符不能出现在任何地方 ; 在身体部位。请注意 ; 身体部位的语义不同于 ; 消息的语义，如 ; 在文本中描述。 八位组：= 新部分开头的每个分隔符都由CRLF终止，紧跟在分隔符前面的任何CRLF都将被解析为边界的一部分，而不是前一部分的数据 The boundary delimiter MUST occur at the beginning of a line, i.e., following a CRLF, and the initial CRLF is considered to be attached to the boundary delimiter line rather than part of the preceding part. The boundary may be followed by zero or more characters of linear whitespace. It is then terminated by either another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part. If no Content-Type field is present it is assumed to be "message/rfc822" in a "multipart/digest" and "text/plain" otherwise. NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary. The boundary delimiter line following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter line is identical to the previous delimiter lines, with the addition of two more hyphens after the boundary parameter value. --gc0pJq0M:08jU534c0p-- NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the boundary value with the beginning of each candidate line. An exact match of the entire candidate line is not required; it is sufficient that the boundary appear in its entirety following the CRLF. The only mandatory global parameter for the "multipart" media type is the boundary parameter, which consists of 1 to 70 characters from a set of characters known to be very robust through mail gateways, and NOT ending with white space. (If a boundary delimiter line appears to end with white space, the white space must be presumed to have been added by a gateway, and must be deleted.) It is formally specified by the following BNF: boundary := 0*69 bcharsnospace bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?" Overall, the body of a "multipart" entity may be specified as follows: dash-boundary := "--" boundary ; boundary taken from the value of ; boundary parameter of the ; Content-Type field. multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] transport-padding := *LWSP-char ; Composers MUST NOT generate ; non-zero length transport ; padding, but receivers MUST ; be able to handle padding ; added by message transports. encapsulation := delimiter transport-padding CRLF body-part delimiter := CRLF dash-boundary close-delimiter := delimiter "--" preamble := discard-text epilogue := discard-text discard-text := *(*text CRLF) *text ; May be ignored or discarded. body-part := MIME-part-headers [CRLF *OCTET] ; Lines in a body-part must not start ; with the specified dash-boundary and ; the delimiter must not appear anywhere ; in the body part. Note that the ; semantics of a body-part differ from ; the semantics of a message, as ; described in the text. OCTET := <any 0-255 octet value>