An Internet media type is metadata in the form of a short name (e.g., "text/html") that associates the data with a specific format specification and preferred interpretation. The association is formally accomplished through registration of the media type in the IANA media type registry. For example, "text/html" in the IANA registry is associated with , which in turn states that:

A media type is not simply an indication of data format; it also refers to a preferred interpretation of that data format. This preferred interpretation may impact the recipient's functional decisions, such as whether the data is rendered, stored, or executed. In practice, media types are often used as the key for selecting an appropriate handler to interpret the data received. It is possible for a single data format to be associated with multiple media types and for a single media type to describe a superset of many different data formats.

As explained above for representation metadata in general, we refer to the media type as describing the sender's preferred, intended, and definitive interpretation of the data, rather than as defining a specific processing model for the recipient. Each agent will interpret received data according to its own function and configuration, perhaps informed by the media type, and all that is required for Web interaction is that the intention be faithfully communicated. It is assumed that the recipient software will follow those intentions, when appropriate, to the extent that it has been instructed to do so by the agent's user.

If the authoritative media type of a representation were to be determined by inspection of embedded metadata in a self-descriptive format, then a sender could not indicate different interpretations for a single representation based on the declared media type. For example, an owner might want to provide links to separate resources that differ only in how a given HTML representation is intended to be rendered. A message containing the header field Content-Type: text/html would indicate that the sender intends the recipient to interpret the representation as hypertext, using the rendering process defined by the HTML standard, whereas the header field Content-Type: text/plain would indicate that the sender intends the recipient to treat the data as plain text without HTML rendering. Since the representation data is the same in both messages, this functionality is only possible if metadata of the containing message is considered more authoritative in describing the data than whatever could be learned from inspection of the data itself.

Placing authoritative metadata in message fields also enables more efficient processing of messages. It is far easier to dispatch behavior on the basis of inspecting metadata (typically a short string) than it is to invoke a generic document parser and try to divine the purpose of data by inspecting the data itself (with no guarantee of success).

If the authoritative media type of a representation were to be determined by external reference, then resources could be prevented from evolving independently from their references. For example, standards for hypermedia data formats evolve over time, whereas it is preferred that URIs remain persistent over time. If metadata guessed by inspecting the identifier were to be considered authoritative, then references would break when the representation media type changes. Similarly, a type attribute provided with a reference would suffer the same problem it were considered authoritative.

Intermediaries (i.e., proxies and gateways) perform significant functions in Web architecture, such as encapsulating legacy services, enhancing client functionality, and moderating the risk of interactions across firewalls. Those functions can only be performed correctly if the semantics of a given message are expressed within that message. In contrast, metadata associated by an external reference is only visible to the user agent that selects the reference: intermediaries are not aware of that context. If a message recipient treats external metadata as authoritative over that found in the message, then the intermediaries are effectively bypassed and their functionality is lost.

Finally, external references are usually made by third-parties: people who are neither the resource owner nor the user. Allowing a third-party to override the intent of the sender of a message means that the client must trust both the resource owner and the supplier of the reference, introducing yet another attack vector and its associated complications to secure configuration and monitoring.

There are, of course, times when a representation is provided without any containing metadata, such as when the sender is not certain of the intended metadata or when the protocol being used does not support metadata. That is why the HTTP/1.1 specification states:

In other words, when there is no authoritative metadata, the receiving agent MAY attempt to guess the appropriate metadata based on inspection of the data and/or the reference, though such guessing should be limited to media types that are safe to use in that context.

Although there are benefits to separating representation metadata from data, there are risks as well. In particular, the resource owner may create inconsistencies by misconfiguring resources or by failing to reassign metadata after a change of representation. Inconsistency between representation data and metadata is an error.

Recipients SHOULD detect inconsistencies between representation data and metadata.

Examples of inconsistencies between metadata and representation data that are frequently observed on the Web include:

Web software developers, webmasters, and resource owners can help reduce inconsistency through careful assignment of representation metadata.

Server software designers (implementers) SHOULD provide a means to set representation metadata at the same level of granularity and permission that is needed to author those representations.

Metadata configuration needs to be authored by the same people who have the ability to change the data being described. If all of the authoring is done by the webmaster, then it makes sense to have one central location for defining the metadata configuration. In contrast, if the right to author representations has been delegated, such as through varying ownership within the server's hierarchical URI space, then the ability to author metadata configuration should be delegated as well.

Server managers (webmasters) SHOULD provide each resource owner (author) with the means and permission to set the configuration of metadata for any representations under the author's control.

For example, the Apache httpd has a configuration directive, AllowOverride FileInfo, which delegates the authority to define metadata to the owners of each directory. It follows, therefore, that "AllowOverride FileInfo" should be set for any directory containing representations that are authored by people who do not have permission to change the central server configuration.

Resource owners (authors) SHOULD test for correct metadata and inform server managers of metadata misconfigurations.

This requires that authors be able to detect errors, which will be discussed below.

Server software designers (implementers) SHOULD NOT specify default representation metadata, such as media type, character encoding, or content language, within the standard configuration shipped with the server.

Instead of specifying a default for metadata, it is better for representations to be sent without that metadata. That allows the recipient to guess the metadata instead of being forced to either accept incorrect metadata or be tempted to violate Web architecture by ignoring it.

Server managers (webmasters) SHOULD NOT specify an arbitrary Internet media type (e.g., "text/plain" or "application/octet-stream") when the media type is unknown.

It is better to send no media type if the resource owner has failed to define one for a given representation.

Authoritative metadata SHOULD NOT be provided external to the representation if it does not add clarity to that communication.

For example, the character encoding of XML data formats is self-descriptive within the data and SHOULD NOT be included in a charset parameter of the media type unless that distinction is significant to the resource (e.g., for comparison during content negotiation of multiple XML representations that differ only by character encoding).

As described above, inconsistency between representation data and metadata is an error. However, the tendency for some agents to attempt silent recovery from such errors is also an error. Silent recovery from error perpetuates what could be easily fixed if the resource owner is simply informed of that error during their own testing of the resource.

Web agents SHOULD have a configuration option that enables the display or logging of detected errors.

Revealing errors when they occur need not be disruptive of the user experience. For example, a graphical browser might display a small "bug" button in the user interface to indicate a detected error so that an interested user (i.e., the resource owner) can select the button, inspect the error, and perhaps modify the agent's choice on how to recover from that error. Naturally, the appropriate mechanism will be unique to each type of receiving agent and application context.

Some applications of the Web cannot tolerate error. For example, medical information systems must be designed so as to detect errors that might cause relevant information to be rendered invisible. In general, it is better to design Web systems that are capable of fulfilling more stringent requirements, even if their default configuration is to be lenient.

A user agent represents the user for protocol-level interactions with resource providers. A user agent that does not respect the Web protocol specifications can violate user privacy, introduce security holes, and otherwise create confusion. For example, a broken user agent could trigger a security failure by ignoring a received "Content-Type" header with value "text/plain", guessing that representation data is a shell script, and then executing the script on the user's machine without the user's awareness. The other agents in the system (origin server and intermediaries) have sent or forwarded the message with the expectation that the user agent will not attempt to execute the script, at least not without some additional action deliberately chosen by the user. If the user agent violates those expectations, it violates the protections that may have been put in place for the user's self-protection.

An agent MUST NOT ignore or override authoritative metadata without the consent of the party employing the agent.

Consent does not imply that the receiving agent must interrupt the user and require selection of one option or another. User consent may be achieved in the form of pre-selected configuration options, modes, or selectable user interface toggles, with appropriate reporting to the user when the agent detects an error. Naturally, the appropriate consent mechanism will be unique to each type of receiving agent and application context. It is therefore beyond the scope of this finding to anticipate the range of possible errors and ways in which interface designers might obtain user feedback to address them.

Likewise, consent may be implied by the nature or type of interaction being performed by the agent. For example, a script that "mirrors" content from the Web into files on an FTP server is probably going to ignore metadata. Similarly, XInclude processing has the implied consent of the user to transform data from one source to another and thus should only result in errors when the transformation is unsuccessful. Note, however, that this functionality imposes a social burden on XInclude processors to be sure that the resulting composed document does not violate the user's security constraints.

Stuart runs his own Web server at "http://www.example.org/". He creates an HTML page and means to serve it as "text/html", but misconfigures the Web server so that the content is served via HTTP/1.1 as "text/plain". Janet's browser retrieves the page and displays the content as plain text. Tim's browser retrieves the page, detects some markup that suggests it is an HTML document (e.g., a <!DOCTYPE declaration or <html> element) and, without informing Tim, proceeds as though the content was declared to be "text/html", rendering it according to the HTML and CSS specifications.

Which party has neglected a constraint of Web architecture: Stuart for the server misconfiguration, Tim's browser for silently overriding the HTTP headers from the server, or Janet's browser for not detecting that the content looked like HTML?

Answer: By silently overriding the authoritative metadata from the HTTP headers, Tim's browser did not respect Web architecture constraints that promote shared understanding and security.

Misconfiguration of the server is a fixable error. If Stuart had been using Janet's browser to test, he would have seen the error immediately and fixed it long before either Tim or Janet made their requests. However, if Stuart used the same browser as Tim for his testing, Stuart would not have been informed of the error. The software developers of Tim's browser are the culprit here because the product misrepresents the resource owner by ignoring the authoritative metadata without Tim's consent. Janet's browser respected the "Content-Type" header field and, in doing so, helps Janet detect a server misconfiguration.

Stuart runs his own Web server at "http://www.example.org/". He creates a text page that describes an example of a security vulnerability in a client-side scripting language using sample code. Since Stuart wants users to read the code, not execute it, he assigns the media type "text/plain" to the representation. Janet's browser retrieves the page and displays the content as plain text. Tim's browser retrieves the page, detects the script language, and executes it, promptly sending a rude message to everyone on Tim's address list (including Tim's mom).

Which party has neglected a constraint of Web architecture: Stuart for serving content about a vulnerability or Tim's browser for silently overriding the HTTP headers from the server?

Answer: By silently overriding the authoritative metadata from the HTTP headers, Tim's browser did not respect Web architecture constraints that promote shared understanding and security.

Authoritative metadata is an important aspect of Web architecture. Agents that ignore authoritative metadata are broken, sometimes dangerously so, and should not be used. Software cannot assume that a configuration is wrong just because it is unusual.

Norm publishes an XHTML document that includes this link:

Although the link refers to an XSLT style sheet, Norm has set the type attribute to "text/css". Stuart has configured the Web server so that representations of the resource "cool-style" are served via HTTP/1.1 as "application/xslt+xml". With a user agent that understands XSLT but not CSS, Janet requests the content that includes this link. As it interprets the representation data, Janet's user agent reads the type hint and does not fetch the style sheet.

Which party is responsible for the fact that Janet did not receive content she should have: Stuart for the server configuration, Norm for stating that the style sheet is served as "text/css" when in fact it's served with a different media type, or Janet's user agent for not double-checking the media type with the server?

Answer: Norm's mislabeling of content deprived Janet of content she should have received.

Norm is responsible for Janet not having access to representation data she was meant to receive. The HTML 4.01 Recommendation states that Authors who use [the type] attribute take responsibility to manage the risk that it may become inconsistent with the content available at the link target address. Janet's client could have done more than merely read the type hint and decide to skip the style sheet, but the specific purpose of that hint is to reduce unnecessary requests and the associated latency.

Users often benefit from agents that perform metadata consistency checks as part of special "authoring" or "testing" modes. Such checks might query the server and check for inconsistency, thus allowing the metadata to be tested by authors without incurring overhead during operation by normal users.

The meaning of any HTTP message is defined by the contents of that message as interpreted according to the HTTP standard. If a client requests that a server store a representation at a given URI and the server's configuration states that the given URI implies metadata inconsistent from what has been provided by the client, then the server should reject the request using an appropriate HTTP status code.

For example, if a WebDAV client performs a

and example.org knows that it has been configured such that all resources with identifiers ending in in ".html" are represented in the "text/html" format (i.e., the server has been configured not to simply accept whatever the client wants for any given identifier), then the server could choose one of four potential choices for handling the request:

Ignoring the "application/pdf" metadata provided by the client (1) is clearly a bad idea because the inconsistency is an error and failing to report an error is bad design.

Automatically changing the conflicting configuration (2) is appropriate if and only if the author has the ability to selectively override the server's configuration on a per-representation basis, has configured their Web space to do so, and the result of accepting the PUT does change that configuration. The primary use-case for this style of override is to continue supporting well-known "cool" URIs even though the identifier appears to contain metadata that is inconsistent with the current media type. A better solution, though, is to simply redirect the old identifier to a new URI that does not contain an apparent file extension. Unfortunately, the main problem with accepting the override is that the inconsistency may have been due to pilot error rather than user intention. A good rule of thumb is to provide this behavior as a configuration option that is not the default.

Performing on-the-fly type conversion, as in (3), is a complicated option that preserves Web semantics but can lead to unexpected results for authors that consider the Web interface to be just another dumb filesystem. This should only be done when the resource owner has specifically configured the resource (or space of resources) to process state changes in this manner. A better solution is to redirect the user to a codependent resource that provides "application/pdf" views of the shared state; the user can then choose whether or not to apply the state change to that resource, which will have a metadata configuration consistent with the representation being PUT, and thus preserve both Web and filesystem semantics.

Responding with a "415 Unsupported Media Type" error (4) is, in most cases, the right answer unless the server has been specifically configured for options (2) or (3). Although it costs time and bandwidth, responding with an informative error message allows the user to inspect both the request being made and the server's current configuration, change whichever one is incorrect, and thereby establish the correct metadata for the resource's representations before allowing the PUT to succeed.