30 html ajax content-type http
当服务器在正文中发送带有HTML文档的HTTP响应时,它通常会使用text/html内容类型.如果响应是HTML的片段,内容类型是否应该不同？
例如,如果请求是来自客户端脚本的AJAX,并且整个响应主体是<div><p>New text</p></div>响应不是HTML文档.应用程序是否应将内容类型设置text/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 被浏览器非常频繁地接收，并尽可能地呈现（而不是完全失败）。
<!DOCTYPE html>- 声明文档模式，特别是规范要求它们“出于遗留原因”<title>My Page</title>省略这些必需元素不会改变内容的性质。在实际意义上，<p>hello world它仍然几乎被普遍解释为 HTML，它只是不是一个有效的文档。
定义 MIME 类型的 RFC 标准仅明确定义text/plain，尽管RFCContent-Type标头规范引用了text/html。这显然没有提供明确的指导，也没有定义可能的替代方案。
鉴于来自 W3 的唯一相关参考，完整的 XML 文档和片段被视为相同（并且 HTML 是 XML 的子集），W3 片段解析算法没有区分（并假设它正在接收 HTML），MDN 建议不要使用在任何替代标题中，并且没有被广泛接受（甚至没有任何值得注意的）替代方案，使用text/htmlfor 文档片段将是明确的选择。我找不到其他建议的先例，并且使用某些自定义 MIME 类型可能只会导致混淆（或更糟）。
If you really wanted to make a distinction in your application between full documents and fragments, you could wrap it in JSON, or send an additional custom header from your server (I could find no references to any common practice in regards to this, and may just be confusing to other devs).
这是个人喜好。如果这只是您的应用程序，那么没关系。我会保留它，text/html因为它仍然是 HTML 标记，即使不是完整的文档。