簡體 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