http - 如何在接受 header 字段中指定接受具有特定内容类型的多部分/相关内容类型的正文部分

Question

RFC 7231 - HTTP/1.1 Semantics and Content, 5.3 Content Negotiation未定义如何指定接受具有特定内容类型的多部分/相关内容类型在接受 header 字段中的正文部分。

例如，如何用 text/html body 部分表达对 multipart/related 内容的接受

Accept: multipart/related;type=text/html

或者

Accept: multipart/related,text/html

如果您想为不同的 html 风格指定优先级？

Accept: multipart/related;type=text/html;q=0.7,
   multipart/related;type=text/html;level=1,
   multipart/related;type=text/html;level=2;q=0.4

或者

Accept: multipart/related,text/html;q=0.7,
   text/html;level=1,
   text/html;level=2;q=0.4

什么是对的？两个都？

Answer 1

首先，HTTP 是一种类似于 MIME 的协议(protocol)，而不是符合 MIME 的协议(protocol)。报价 RFC 7230, section 2.1 :

Messages are passed in a format similar to that used by Internet mail [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [RFC7231] for the differences between HTTP and MIME messages).

记住这一点很重要，因为这在处理 MIME 内容时给予我们一些自由。
Accept标题以 RFC 7231, sec. 5.3.2 为准.那里描述的语法允许一个逗号分隔的媒体类型列表(参见 RFC 7230, sec. 7)，除了 HTTP 特定的权重参数 q 之外，每个媒体类型的参数都具有任意数量的特定参数。 (见 RFC 7231, sec. 5.3.1)。

Section 3.1.1.1讨论哪些媒体类型被认为对 Accept 有效和 Content-Type标题:

HTTP uses Internet media types [RFC2046] in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation. [...] Internet media types ought to be registered with IANA according to the procedures defined in [BCP13]

[BCP13] 指的是 RFC 6838 ，最终导致 IANA Media Types Registry .

值得一提的是 Accept 的语法header 不需要任何参数；就 HTTP 规范而言，它们都是可选的。如果有必需的参数，它们必须由相关的媒体类型直接要求:

The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.

multipart/related MIME 类型本身受 RFC 2387 约束. Section 3.1其中明确地使 type参数必填。它也是一个单一的值，而不是一个列表。有趣的是，HTTP 规范强调了 boundary 存在的重要性。参数结束 RFC 2046, section 5.1.1 .来自 RFC 7231, section 3.1.1.4 :

All multipart types share a common syntax, as defined in Section 5.1.1 of [RFC2046], and include a boundary parameter as part of the media type value.

我的猜测是，作者从未想过将多部分媒体类型放入 Accept 中。 header ，这会使边界变得无用。这确实可能是勘误表的候选者(朱利安？)。所以从技术上讲，请求这个绝对正确的方法是:

Accept: multipart/related; type=text/html; boundary=--my-top-notch-boundary-

实际上，实现者似乎倾向于故意忽略这些要求，如 this example显示。我通常不反对遵循 RFC，但我认为在这里跳过 boundary 实际上是有意义的。范围。请记住，这是用于内容协商的请求 header ，而不是对消息部分之间具有指定边界的 seom 实际内容的描述，我想不出请求这种边界是合法的用例；除非你是因为造成一些恶作剧。但话又说回来，你是在为自己请求一个被操纵的请求。我还没有决定是否省略 type参数，虽然。恕我直言，这样做意味着 type=*/* ，这实际上是“我不在乎，发送您认为合适的任何内容”。虽然这可能会导致完全符合 RFC2387 的响应，但我个人对对返回的内容类型进行这种小控制感到不安。 (旁注:您可能总是想检查响应的内容类型。2xx 代码并不能保证您得到了您所要求的内容)

现在，如果您使用 Accept: mutlipart/related, text/html 发出请求，您正在请求未指定类型的多个部分或单个 HTML 文档。如果您想协商内容，您将需要请求 multipart/related 的多个变体。不同类型:

Accept: multipart/related; type=text/html,
        multipart/related; type=text/plaintext

(注意:为了提高易读性而添加了行继续。请注意，行继续是 deprecated，不应再在 HTTP 上下文中使用。)

关于你的例子，我很惊讶地发现这个媒体类型的语法在参数方面非常严格。情况如下:

Accept header 本身受 RFC 7231, sec. 5.3.2

媒体类型和子类型直接来自 IANA 媒体类型注册表，符合 RFC 6838

参数处理如下:

q受 RFC 7231, sec 授权。 5.3.1

boundary受 RFC 2046 的授权，秒。 5.1.1

其余参数受制于媒体类型各自的 RFC。在这种情况下，这意味着 type是必需的，后跟可选参数 start和 start-info

按照 RFC 2046, section 1 丢弃无法识别的参数:

MIME implementations must also ignore any parameters whose names they do not recognize.

所以，如果 level是一个公认的参数(目前这甚至不是 text/html mediatype 的情况。是的，我知道它出现在多个示例中)，正确的解决方案确实是这样的:

Accept: multipart/related; type=text/html; q=0.7,
        multipart/related; type=text/html; level=1,
        multipart/related; type=text/html; level=2; q=0.4

但是去掉 level参数，我们归结为:

Accept: multipart/related; type=text/html; q=0.7,
        multipart/related; type=text/html,
        multipart/related; type=text/html; q=0.4

这在本质上与以下内容相同:

Accept: multipart/related; type=text/html