text/html
This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.
charset
The charset
parameter may be provided to
definitively specify the
document's character encoding, overriding any character encoding
declarations in the document. The parameter's value must be the
name of the character encoding used to serialize the file, must be
a valid character encoding name, and must be an ASCII case-insensitive match for
the preferred MIME name for that
encoding. [IANACHARSET]
Entire novels have been written about the security considerations that apply to HTML documents. Many are listed in this document, to which the reader is referred for more details. Some general concerns bear mentioning here, however:
HTML is scripted language, and has a large number of APIs (some of which are described in this document). Script can expose the user to potential risks of information leakage, credential leakage, cross-site scripting attacks, cross-site request forgeries, and a host of other problems. While the designs in this specification are intended to be safe if implemented correctly, a full implementation is a massive undertaking and, as with any software, user agents are likely to have security bugs.
Even without scripting, there are specific features in HTML
which, for historical reasons, are required for broad compatibility
with legacy content but that expose the user to unfortunate
security problems. In particular, the img
element can be used in conjunction with
some other features as a way to effect a port scan from the user's
location on the Internet. This can expose local network topologies
that the attacker would otherwise not be able to determine.
HTML relies on a compartmentalization scheme sometimes known as the same-origin policy. An origin in most cases consists of all the pages served from the same host, on the same port, using the same protocol.
It is critical, therefore, to ensure that any untrusted content that forms part of a site be hosted on a different origin than any sensitive content on that site. Untrusted content can easily spoof any other page on the same origin, read data from that origin, cause scripts in that origin to execute, submit forms to and from that origin even if they are protected from cross-site request forgery attacks by unique tokens, and make use of any third-party resources exposed to or rights granted to that origin.
html
" and "htm
"
are commonly, but certainly not exclusively, used as the extension
for HTML documents.TEXT
Fragment identifiers used with text/html
resources either refer to
the indicated part of the document or provide state information
for in-page scripts.
multipart/x-mixed-replace
This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.
boundary
(defined in RFC2046) [RFC2046]multipart/x-mixed-replace
resource can be of any type, including types with non-trivial
security implications such as text/html
.multipart/mixed
. [RFC2046]multipart/x-mixed-replace
resource.Fragment identifiers used with multipart/x-mixed-replace
resources apply to each body part as defined by the type used by
that body part.
application/xhtml+xml
This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.
application/xml
[RFC3023]application/xml
[RFC3023]application/xml
[RFC3023]application/xml
[RFC3023]application/xml
[RFC3023]application/xhtml+xml
type
asserts that the resource is an XML document that likely has a root
element from the HTML namespace. Thus, the relevant
specifications are the XML specification, the Namespaces in XML
specification, and this specification. [XML]
[XMLNS]application/xml
[RFC3023]application/xml
[RFC3023]xhtml
" and "xht
"
are sometimes used as extensions for XML resources that have a root
element from the HTML namespace.TEXT
Fragment identifiers used with application/xhtml+xml
resources have the same semantics as with any XML MIME type. [RFC3023]
application/x-www-form-urlencoded
This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.
In isolation, an application/x-www-form-urlencoded
payload poses no security risks. However, as this type is usually
used as part of a form submission, all the risks that apply to HTML
forms need to be considered in the context of this type.
application/x-www-form-urlencoded
payloads are defined in this specification.application/x-www-form-urlencoded
payloads.Fragment identifiers have no meaning with the application/x-www-form-urlencoded
type.
text/cache-manifest
This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.
Cache manifests themselves pose no immediate risk unless sensitive information is included within the manifest. Implementations, however, are required to follow specific rules when populating a cache based on a cache manifest, to ensure that certain origin-based restrictions are honored. Failure to correctly implement these rules can result in information leakage, cross-site scripting attacks, and the like.
CACHE
MANIFEST
", followed by either a U+0020 SPACE character, a
"tab" (U+0009) character, a "LF" (U+000A) character, or a "CR"
(U+000D) character.appcache
"Fragment identifiers have no meaning with text/cache-manifest
resources.
web+
scheme prefixThis section describes a convention for use with the IANA URI scheme registry. It does not itself register a specific scheme. [RFC4395]
Schemes using the web+
prefix must have
names starting with the four characters "web+
" followed by one or more letters in the range
a
-z
.
Registrations of such schemes should specify the syntax and semantics of the scheme. Registrations should define what applications and/or protocols use the scheme.
All "web+
" schemes should use UTF-8
encodings were relevant.
Any Web page is able to register a handler for all "web+
" schemes. As such, these schemes must not be used
for features intended to be core platform features (e.g. network
transfer protocols like HTTP or FTP). Similarly, such schemes must
not store confidential information in their URLs, such as
usernames, passwords, personal information, or confidential project
names.
Registrations should reference the description of web+
schemes in Custom scheme and content
handlers, HTML5: http://www.w3.org/TR/html5/system-state-and-capabilities.html#custom-handlers