当服务器在正文中发送带有HTML文档的HTTP响应时，通常会使用text/html内容类型。如果响应是HTML的片段，内容类型是否应该不同？
例如，如果请求是来自客户端脚本的AJAX，并且整个响应正文是<div><p>New text</p></div>，则响应不是HTML文档。应用程序是否应将内容类型设置为text/html以外的其他内容？如果是这样，是什么？
答案 0 :(得分：3)
这是个人偏好。如果它只是你的应用程序，那么无所谓。我会保留它text/html因为它仍然是HTML标记，即使不是完整的文档。
答案 1 :(得分：2)
关于XML / HTML文档片段，除了评论中引用的xml-fragment（现在标记为“不再维护”），似乎没有任何明确的官方文档片段引用和内容类型标题。但是，有些要考虑的要点：
xml-fragment规范处理与b-elem相关的完整文档和片段。
MIME Types上的MDN文档不区分完整文档和片段（强调添加）：
应使用此类型提供所有HTML内容。替代MIME XHTML的类型（如application / xml + html）几乎没用 如今（HTML5统一了这些格式）。
W3规范8.4 Parsing HTML Fragments明确规定了处理HTML文档片段的案例。除非解析器失败（遇到解析器错误），否则它假定给定的字符串是HTML。此外，浏览器非常频繁地接收无效/部分HTML，并且尽可能地呈现（而不是正确的失败）。
完整的无效HTML文档的minimum tags required是：
Content-Type - 声明文档模式，特别是规范要求他们“for legacy reasons”<!DOCTYPE html> 省略这些必需元素不会改变内容的性质。实际上，<title>My Page</title>几乎被普遍解释为HTML，它只是一个有效的文档。
RFC标准defining MIME types仅明确定义<p>hello world，但RFC Content-Type header spec引用text/plain。这显然没有提供明确的指导，但也没有定义可能的替代方案。
鉴于来自W3状态的唯一相关参考，完整的XML文档和片段被视为相同（并且HTML是XML的子集），W3片段解析算法没有区别（并且假设它正在接收HTML），MDN建议反对使用任何替代标题，并且没有广泛接受（或甚至任何值得注意的）替代方案，使用text/html作为文档片段将是明确的选择。我没有找到先例建议否则，使用一些自定义MIME类型可能只会引起混淆（或更糟）。
如果你真的想在你的应用程序中区分完整文档和片段，你可以用JSON包装它，或者从你的服务器发送一个额外的自定义标题（我找不到关于这个的任何常见做法的引用，可能只是让其他开发者感到困惑。）
答案 2 :(得分：0)
是的，我也在解决这个问题。但是，如果您对现有的HTTP用例的映射不完全满意，那么创建自己的HTTP标头是完全可以的。在那个方向，http://tools.ietf.org/html/rfc6648＆＃34; X - ＆＃34;现已弃用基于标头的标头。基本上，只要你选择一个足够独特和有意义的哑剧类型，你就可以自由发明自己的。但正如@Wrikken在评论中提到的那样，这可能会有问题。所以要避免所有这些，你可以回退text / html或者通过JSON方式，而不是<div>方式。在理想和可扩展的世界中，服务器端应该不会创建HTML / DIV