繁体 English 中英

HTML片段的内容类型

[英]Content type for HTML fragments

原文 2013-10-10 18:24:51 5 3 html/ ajax/ http/ content-type

服务器在正文中发送带有HTML文档的HTTP响应时，通常会使用text/html内容类型。 如果响应是HTML的一部分，内容类型是否应该不同？

例如，如果请求是来自客户端脚本的AJAX，并且整个响应正文是<div><p>New text</p></div>则响应不是HTML文档。 应用程序是否应将此类片段的内容类型设置为text/html以外的其他类型？ 如果是这样，该怎么办？

3 个解决方案

这是个人喜好。 如果只是您的应用程序，那就没关系了。 我将其保留为text/html因为它仍然是HTML标记，即使不是完整的文档也是如此。

关于XML / HTML文档片段，除了注释中引用的xml-fragment （现在标记为“不再维护”）之外，似乎没有任何对文档片段和内容类型标头的明确官方引用。 但是，需要考虑以下几点：

xml-fragment规范将完整文档和片段视为与Content-Type 。
关于MIME类型的MDN文档在完整文档和片段之间没有区别（强调）：

所有HTML内容都应使用这种类型。 如今，XHTML的其他MIME类型（例如application / xml + html）几乎没有用（HTML5统一了这些格式）。

W3规范8.4解析HTML片段明确规定了处理HTML文档片段的情况。 除非解析器失败（遇到解析器错误），否则它将假定给定的字符串为HTML。 此外，浏览器会非常频繁地接收无效/部分HTML，并将其呈现到最大程度（与完全失败相对）。
完全无效的HTML文档所需的最少标记为：
- DOCTYPE： <!DOCTYPE html> -声明文档模式，特别是规范要求它们“ 出于传统原因 ”
- 标题： <title>My Page</title>
省略这些必需元素不会更改内容的性质。 从实际意义上讲， <p>hello world仍然几乎被普遍解释为HTML，它只是无效的文档。
尽管RFC Content-Type标头规范引用了text/html ，但是定义MIME类型的RFC标准仅明确定义了text/plain 。 显然，这没有提供明确的指导，但也没有定义任何可能的替代方法。

假设W3的唯一相关参考指出完整的XML文档和片段都被视为相同（HTML是XML的子集），则W3片段解析算法没有区别（并假定它正在接收HTML），MDN建议不要使用在任何其他标头中，也没有广泛接受的（甚至实际上甚至没有任何显着的）替代方法，使用text/html作为文档片段将是显而易见的选择。 我找不到先例可以暗示否则，使用某些自定义MIME类型可能只会引起混乱（或更糟）。

如果您确实希望在应用程序中区分完整文档和片段，则可以将其包装在JSON中，或者从服务器发送一个附加的自定义标头（我对此没有任何常见做法的引用，并且可能只是让其他开发人员感到困惑）。

是的，我也正在为此解决问题。 但是，如果您不完全满意将现有的HTTP头映射到用例，则可以创建自己的HTTP头。 在此方向上，现在不建议使用基于http://tools.ietf.org/html/rfc6648基于“ X-”的标题。 基本上，只要选择足够独特且有意义的哑剧类型，您就可以自由发明自己的哑剧类型。 但是正如@Wrikken在他的评论中提到的那样，这可能是有问题的。 因此，要避免所有这些，您可以回退到text / html上，或者通过JSON方式（而不是<div>方式）进行操作。 在理想的和可扩展的世界中，应该避免服务器端创建HTML / DIV