Question

除了行结尾之外，

RFC7233很清楚。

我特别感兴趣multipart/byteranges响应的HTTP响应主体。我假设每个行都是由CRLF终止的，因为HTTP头是，但是这个文档并没有明确说明它。最后一行是--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参考。

Answer 1

如果您更仔细地阅读RFC 7233，Appendix A会在RFC 2046 Section 5.1中提及HTTP正文中MIME数据的实际格式：

当206（部分内容）响应消息包含内容时多个范围，它们作为多部分的身体部位传播消息正文（[RFC2046]，第5.1节），媒体类型为＆＃34;多部分/字节范围＆＃34;

RFC 2046第5.1节定义了＆＃34; multipart＆＃34;的正式定义。媒体类型及其边界的格式和解析方式。

回答你的问题，这是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.

...

   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>

新部件开头的每个分隔符都由CRLF终止，紧接在分隔符之前的任何CRLF都被解析为边界的一部分而不是前一部分的数据。但是，在最终结束边界的末尾没有CRLF，除非存在结尾（在电子邮件中很少使用，并且我从未在HTTP中使用它，因为无法确定结尾何时结束除非存在有效的Content-Length标头，否则不应与MIME等自终止内容类型一起使用。

Answer 2

该规范引用：

https://tools.ietf.org/html/rfc2046#section-5.1.1

明确指出：

 --gc0pJq0M:08jU534c0p
边界定界符必须出现在一行的开头，即   在CRLF之后，初始CRLF被认为是附加的   到边界定界线而不是前面的一部分   部分。边界可以跟随零个或多个字符   线性空白。然后由另一个CRLF和
终止   下一部分的标题字段，或两个CRLF，在这种情况下为   下一部分没有标题字段。如果没有Content-Type
  字段存在它被假定为＆＃34; message / rfc822＆＃34;在一个   ＆＃34;多部分/消化＆＃34;和＆＃34; text / plain＆＃34;否则。

HTTP范围请求multipart / byteranges - 最后是否有CRLF？

2 个答案: