Content type for HTML fragments
When a server sends an HTTP response with an HTML document in the body, it would usually use the text/html content type. Should the content type be different if
-
In regards to XML/HTML document fragments, other than the xml-fragment referenced in the comments (now labeled as "no longer maintained"), there don't appear to be any explicit, official references to document fragments and the content type header. However, some points to consider:
The xml-fragment spec treats full documents and fragments the same in regards to the
Content-Type.The MDN documentation on MIME Types makes no distinction between full documents and fragments (emphasis added):
All HTML content should be served with this type. Alternative MIME types for XHTML (like application/xml+html) are mostly useless nowadays (HTML5 unified these formats).
The W3 spec 8.4 Parsing HTML Fragments explicitly lays out cases for handling an HTML document fragment. Unless the parser fails (hits a parser error), it assumes the string given is HTML. Furthermore, invalid/partial HTML is received by browsers extremely frequently, and is rendered to the fullest extent possible (as opposed to out right failing).
The minimum tags required for a full void HTML document are:
- The DOCTYPE:
<!DOCTYPE html>- declares the document mode, notably the spec requires them "for legacy reasons" - The title:
<title>My Page</title>
Omission of the these required elements does not change the nature of the content. In a practical sense,
<p>hello worldis still nearly-universally interpreted to as HTML, it is just not a valid document.- The DOCTYPE:
The RFC standard defining MIME types only explicitly defines
text/plain, although the RFC Content-Type header spec referencestext/html. This obviously provides no clear guidance, but also defines no possible alternatives.
Given the only relevant reference from the W3 states full XML documents and fragments be treated the same (and HTML is subset of XML), the W3 fragment parsing algorithm does not make a distinction (and assumes it's receiving HTML), MDN advises against the usage of any alternative headers, and there's no widely accepted (or really even any notable) alternatives, using
text/htmlfor document fragments would be the clear choice. I could find no precedent to suggest otherwise, and using some custom MIME type would probably just cause confusion (or worse).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).
讨论(0) -
It's a personal preference. If it is only your app, then it doesn't matter. I would keep it
text/htmlbecause it is still HTML markup, even if not a complete document.讨论(0) -
Yes, I am also in a fix for this. But it is perfectly okay to create your own HTTP headers if you are not fully satisfied with the mapping of an existing one to your use case. In that direction, http://tools.ietf.org/html/rfc6648 "X-" based headers are now deprecated. Basically, as long as you choose a sufficiently unique and meaningful mime type, you're free to invent your own. But as @Wrikken mentioned in his comment, that could be problematic. So to avoid all of it, you could fallback on text/html OR do it via a JSON way , and not
<div>way. In an ideal and scalable world, server side should be left free from creating HTMLs/DIVs讨论(0)
加载中...
- 热议问题