The following are the key architectural points of this finding:

For example, when an HTTP message contains a representation as its payload (within its message body), the HTTP header field "Content-Type", if present, defines the Internet media type of that representation. The recipient is not allowed to "guess" the media type unless no such metadata was provided with the representation.

Section 2 presents scenarios where these principles/points have been ignored and poses the question of what has been ignored and by whom. Section 3 discusses the motivation for a Web architecture where origin metadata is authoritative. Section 4 examines the potential harm caused by user agents that misrepresent the user or silently disregard authoritative metadata. Section 5 discusses the interaction between metadata hints in format specifications and protocol headers. Section 6 suggests ways in which server management can alleviate problems due to inconsistencies between provided content and configured metadata.

Scenario 1: 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 server so that the content is served via HTTP/1.1 as text/plain rather than as text/html. Tim's browser looks inside the page, detects some markup that suggests that this is an HTML document (e.g., a <!DOCTYPE declaration or <title> element), and quietly renders it according to the HTML specification rather than as plain text. Janet's browser displays the content as plain text.

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

Answer 1: By silently overriding authoritative metadata, Tim's browser did not respect Web architecture principles that promote shared understanding.

Scenario 2: Norm publishes an XHTML document that includes:

Norm's "cool-style" is an XSLT style sheet, but Norm has set type to text/css. Stuart has configured the server so that "cool-style" is 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 element. As it loads the page, Janet's user agent reads the type hint and does not fetch "cool-style."

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 "cool-style" sheet is served as text/css when in fact it's served with a different content type, or Janet's user agent for not double-checking the content type with the server?

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

In the sections below, we explore these answers in more detail.

Successful communication between two parties about a piece of information relies on shared understanding of the meaning of the information. On the Web, thousands of independent parties can identify and communicate about a Web resource. To give these parties the confidence that they are all talking about the same thing when they refer to "the resource identified by the following URI ..." the design choice for the Web is, in general, that the owner of a resource assigns the authoritative interpretation of its representations. In terms of Web architecture, the authoritative interpretation of representations is communicated as follows:

Interpretation of bits on the Internet is governed by protocol specifications. The HTTP/1.1 specification, for example, delegates assignment of the interpretation for a message entity (the representation enclosed within a message) to the header fields "Content-Encoding" and "Content-Type", where the latter's value is defined by an Internet media type (e.g., text/html or image/jpeg) that, in turn, identifies a registered data format specification (e.g., XHTML, CSS, PNG, XLink, RDF/XML, etc.).

There are benefits to allowing different interpretations of a bag of bits depending on context. For flexibility, protocols like HTTP/1.1 allow resource owners to direct the interpretation of a bag of bits by sending metadata along with the bits. A response from the server includes both the bag of bits (the "entity body") and metadata about those bits (the "entity headers", including Content-Type, Content-Language, and Content-Encoding). In Web architecture terms, a bag of bits plus metadata is called a representation of a resource. HTTP's use of Content-prefixed header fields originated with MIME (RFC2046) and thus is common to most Internet application-level protocols.

This model does not imply that a given set of bits can only be interpreted as the author intended. The model is designed to enable global understanding by having parties agree to follow a small set of rules for interpreting bits (starting with the media type). Parties may reach local agreements independently, but they do not change the authoritative interpretation of the bits.

Another benefit of signaling interpretation by metadata is improved efficiency. For instance, when a server sends XML data and labels the data correctly through metadata header fields, a client can dispatch processing to a handler specific to that media type after rapid inspection of the metadata (typically short strings). It would be considerably more expensive for the client to start up an XML parser to guess the content type.

A particularly important piece of metadata is indicated by the "Content-Type" header field, which instructs a client on which specification to follow next in order to interpret a bag of bits; that specification may invoke others recursively. The media type refers to the Internet registry of data formats to format specifications maintained by the Internet Assigned Numbers Authority . For instance, in the IANA registry, the content type text/html is associated with , which in turn states that:

Thus, by serving a bag of bits with content type text/html, the resource owner declares that the HTML 4.01 Recommendation governs the authoritative interpretation. By serving a bag of bits (even HTML bits) with content type text/plain, the resource owner declares that and govern the authoritative interpretation. This is the first piece of explaining why Tim's browser in scenario 1 is the culprit.

A user agent represents the user for interactions with servers. User agent behavior that misrepresents the user or misrepresents the server ultimately undermines trust on the Web and is thus considered harmful. Misrepresentation may lead to violations of privacy, security holes, and just plain confusion. Some examples of potential security violations include:

A client that ignores authoritative server headers without informing the user undermines the goal of creating a shared information space.

In scenario 1, in terms of Web architecture, Stuart is innocent; misconfiguration of the server is not an architectural error, it's just a human error. Instead, Tim's browser is the culprit since it misrepresents the server by ignoring the authoritative headers, without informing Tim. Janet's browser respected the text/plain header, and by doing so, helps Janet and Stuart detect a server misconfiguration.

Examples of inconsistencies between headers and a bag of bits that have been observed on the Web include:

Clients should detect such inconsistencies but should not resolve them without involving the user (e.g., by securing permission or at least providing notification).

Another form of inconsistency is when the client expects a MIME header and the server doesn't send one. For instance, HTTP/1.1 , section 7.2.1 describes client behavior in the case when the server sends no content type header:

This excerpt is consistent with the principle that the content type header, when present, is authoritative. HTTP/1.1 allows a client to guess when no content type is present; in this case, content that is self-describing is likely to lead to a coherent interpretation.

For this reason, servers should only supply a character encoding header when there is complete certainty as to the encoding in use. Otherwise, an error will cause a perfectly usable representation to be rejected by an architecturally sound client. Section 7.1 of states:

However, a receiving application can, with very high reliability, determine the character encoding of an XML document by reading it, without reference to any external headers and this is reflected by RFC 3023 in section 8.9, 8.10, and 8.11. Thus there is no ambiguity when the character encoding header is omitted, and the STRONGLY RECOMMENDED injunction to use the character encoding header is misplaced for application/xml and for non-text +xml types.

We recommend that section 7.1 be amended to something like the following:

Some format specifications allow authors to include in content "hints" for servers and clients. For instance, the http-equiv attribute of the HTML meta element is intended for servers (not clients). In HTML 2.0 , section 5.2.5, the attribute is specified as follows:

The HTML 4.01 attribute type for the link element (used in Scenario 2) gives clients a hint about what the content type of the linked resource is likely to be.

A format specification that includes hints for clients should make clear that when these hints interact with server headings, they are advisory only. Format specifications should not include requirements for clients to override server headers without user consent. An architecturally sound description of an advisory attribute might read:

The W3C Recommendation SMIL 2.0 is outmoded in this regard since the definition of the type attribute (section 7.3.1) specifies circumstances in which type is supposed to take precedence over server headers.

The rationale frequently provided by specification designers for why the author should be able to override server headers in content is to work around misconfigured servers. In many environments, authors do not have sufficient access to server managers to request that the server be configured for a new or special MIME type. The TAG does not believe that author-specified overrides is the proper solution to this problem (for the reasons cited above, including security risks and masking of the problem). Instead the TAG recommends the following (in addition to suggested client behavior):

Dan Connolly generously provided significant input to this finding. Stuart Williams, Norm Walsh, and Rob Lanphier also provided valuable input. Many thanks to all reviewers for their contributions to this finding.