HTTP范围请求multipart/byteranges - 结尾是否有CRLF？

Question

HTTP范围请求multipart/byteranges - 结尾是否有CRLF？

3

RFC7233非常清晰明了，除了换行符。

我特别关心multipart/byteranges响应的HTTP响应体。我假设每行都像HTTP头一样以CRLF结尾，但是这个文档没有明确说明。我完全困惑的是最后一行: --THIS_SEPARATOR_SEPARATES--。它后面跟着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参考文献。

- zupa

2个回答

0

该规范涉及以下内容：

https://www.rfc-editor.org/rfc/rfc2046#section-5.1.1

明确声明如下：

 --gc0pJq0M:08jU534c0p
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.

- Evert

你所引用的内容涉及 MIME 部分之间的第一个和后续边界，但不包括最终的结束边界，该边界不以 CRLF 结束（除非存在 epilogue）。 - Remy Lebeau

1

感谢指出rfc2046和非常快的回应Evert。因为Remy也回答了CRLF部分，所以我不得不接受他的回答。感谢你的时间。 - zupa

没问题 =) 很高兴你得到了答案。 - Evert

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Remy Lebeau · Accepted Answer

如果您仔细阅读RFC 7233，附录A将RFC 2046第5.1节用于HTTP正文中MIME数据的实际格式：

当206（部分内容）响应消息包括多个范围的内容时，它们作为多部分消息体([RFC2046]，第5.1节)中的主体部分传输，其媒体类型为“multipart / byteranges”。

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

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

边界分隔符必须出现在一行的开头，即在CRLF之后，并且初始的CRLF被视为附加到边界分隔符行而不是前面部分的一部分。边界可以后跟零个或多个线性空格字符。然后，它由另一个CRLF和下一部分的标头字段终止，或者由两个CRLF终止，在这种情况下，下一部分没有标头字段。如果不存在Content-Type字段，则假定在“multipart/digest”中为“message/rfc822”，否则为“text/plain”。

注意：边界分隔符行之前的CRLF在概念上附加到边界，因此可能存在不以CRLF（换行符）结尾的部分。因此，必须将必须考虑为以换行符结束的正文部分具有两个CRLF，第一个是前面部分的一部分，第二个是封装边界的一部分。

...

最后一个正文部分后面的边界分隔符行是一个特殊的分隔符，表示不会再有更多的正文部分跟随。这样的分隔符行与之前的分隔符行相同，只是在边界参数值后面添加了两个连字符。

--gc0pJq0M:08jU534c0p--

实现者注意：边界字符串比较必须将边界值与每个候选行的开头进行比较。不需要完全匹配整个候选行；只要边界完整地出现在CRLF之后即可。

...

“multipart” 媒体类型的唯一必需全局参数是边界参数，该参数由一组已知通过电子邮件网关非常健壮的1到70个字符组成，并且不以空格结束。（如果边界分隔符行似乎以空格结尾，则必须假定是网关添加的空格，并将其删除。）它由以下 BNF 正式指定：

boundary:=0*69bcharsnospace bchars:=bcharsnospace/" " bcharsnospace:=DIGIT/ALPHA/"'"/"("/")"/"+"/"_"/","/"-"/"."/ "/" / ":" / "=" / "?"

总体而言，“multipart” 实体的正文可以指定如下：

dash-boundary:="--" boundary ;boundary 取自 Content-Type 字段的 boundary 参数。

multipart-body:=[preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue]

transport-padding:=*LWSP-char ; 作曲家不得生成长度非零的传输填充， ; 但接收器必须能够处理消息传输添加的填充。

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 ; 可被忽略或丢弃。

body-part:=MIME-part-headers [CRLF *OCTET] ; 正文部分中的行不得以指定的 dash-boundary 开头， ; 并且分隔符不能出现在正文部分的任何位置。 ; 请注意，body-part 的语义与消息的语义不同， ; 如本文所述。

OCTET:= 每个新部分开头的分界符都以CRLF结尾，任何紧接着分界符之前的CRLF都被解析为边界的一部分而不是前一个部分的数据。然而，在最后一个结束边界上没有CRLF，除非有一个epilogue出现（在电子邮件中很少使用，在HTTP中我从未见过它被使用，因为没有办法确定epilogue何时结束，除非有一个有效的Content-Length头存在，这不应该与类似MIME的自终止内容类型一起使用）。