Source: https://trac.ietf.org/trac/httpbis/changeset/2050
Timestamp: 2019-08-18 00:41:42
Document Index: 232454078

Matched Legal Cases: ['art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art4', 'art4', 'art4', 'art5', 'art5', 'art5', 'art7', 'art7', 'art7', 'art4', 'art4', 'art4', 'art5', 'art5', 'art5', 'art7', 'art7', 'art7', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5', 'art5']

Changeset 2050 – Hypertext Transfer Protocol Wiki
Dec 13, 2012, 4:39:56 PM (7 years ago)
Clean up of MIME and conneg; partly addresses #419
content: "Expires June 16, 2013";
<meta name="dct.issued" scheme="ISO8601" content="2012-12-13">
<td class="right">December 13, 2012</td>
<td class="left">Expires: June 16, 2013</td>
<p>This Internet-Draft will expire on June 16, 2013.</p>
<p id="rfc.section.3.1.1.2.p.1">HTTP uses charset names to indicate or negotiate the character encoding scheme of a textual representation <a href="#RFC6365" id="rfc.xref.RFC6365.2"><cite title="Terminology Used in Internationalization in the IETF">[RFC6365]</cite></a>. A charset is identified by a case-insensitive token.
<p id="rfc.section.3.1.1.2.p.1">HTTP uses <dfn>charset</dfn> names to indicate or negotiate the character encoding scheme of a textual representation <a href="#RFC6365" id="rfc.xref.RFC6365.2"><cite title="Terminology Used in Internationalization in the IETF">[RFC6365]</cite></a>. A charset is identified by a case-insensitive token.
<p id="rfc.section.3.1.1.3.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
<p id="rfc.section.3.1.1.3.p.2">When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and
in a charset that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte charsets, HTTP
allows the use of whatever octet sequences are defined by that charset to represent the equivalent of CR and LF for line breaks.
This flexibility regarding line breaks applies only to text media in the payload body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
<p id="rfc.section.3.1.1.3.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.
<p id="rfc.section.3.1.1.3.p.1">Internet media types are registered with a canonical form in order to be interoperable among systems with varying native encoding
formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described
by MIME <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly
different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the
sake of compatibility with older mail transfer protocols do not apply to HTTP (see <a href="#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix&nbsp;A</a>).
HTTP elements outside the payload body (e.g., header fields).
<p id="rfc.section.3.1.1.3.p.3">If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being
<p id="rfc.section.3.1.1.4.p.2">In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. HTTP does
<p id="rfc.section.3.1.1.4.p.3">A recipient <em class="bcp14">MUST</em> treat an unrecognized multipart subtype as being equivalent to "multipart/mixed".
<div class="note" id="rfc.section.3.1.1.4.p.4">
<h4 id="rfc.section.3.1.1.5"><a href="#rfc.section.3.1.1.5">3.1.1.5</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h4>
<p id="rfc.section.3.1.1.5.p.1">The "Content-Type" header field indicates the media type of the representation, which defines both the data format and how
that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics) after any <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is decoded. For responses to the HEAD method, the media type is that which would have been sent had the request been a GET.
<p id="rfc.section.3.1.1.5.p.1">The "Content-Type" header field indicates the media type of the associated representation: either the representation enclosed
in the message payload or the selected representation, as determined by the message semantics. The indicated media type defines
both the data format and how that data is intended to be processed by a recipient, within the scope of the received message
semantics, after any content codings indicated by <a href="#header.content-encoding" class="smpl">Content-Encoding</a> are decoded.
<div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.type" class="smpl">media-type</a>
<p id="rfc.section.3.1.2.2.p.8">An origin server <em class="bcp14">MAY</em> respond with a status code of <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> if a representation in the request message has a content coding that is not acceptable.
<td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
languages, or using different charsets.
<p id="rfc.section.3.4.p.2">This specification defines two patterns of content negotiation that can be made visible within the protocol: "proactive",
where the server selects the representation based upon the user agent's stated preferences, and "reactive" negotiation, where
the server provides a list of representations for the user agent to choose from. Other patterns of content negotiation include
"conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent
parameters, "active content", where the representation contains a script that makes additional (more specific) requests based
on the user agent characteristics, and "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>), where content selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs
of <a href="#request.conneg" title="Content Negotiation">Section&nbsp;6.3</a> and implicit characteristics, such as the client's network address or parts of the <a href="#header.user-agent" class="smpl">User-Agent</a> field.
to describe to a user agent, or when the server desires to send its "best guess" to the user agent along with the first response
improve the server's guess, a user agent <em class="bcp14">MAY</em> send request header fields that describe its preferences.
<p id="rfc.section.3.4.1.p.3">Proactive negotiation has serious disadvantages: </p>
to view it on screen or print it on paper?);
and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.3.2</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.3.3</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3.4</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.3.5</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;6.5.3</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
<p id="rfc.section.3.4.1.p.7">The <a href="#header.vary" class="smpl">Vary</a> header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;8.2.1</a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation.
of responses have multiple representations) and a potential risk to the user's privacy;
<li>It complicates the implementation of an origin server and the algorithms for generating responses to a request; and,</li>
<li>It limits the reusability of responses for shared caching.</li>
<p id="rfc.section.3.4.1.p.4">A user agent cannot rely on proactive negotiation preferences being consistently honored, since the origin server might not
implement proactive negotiation for the requested resource or might decide that sending a response that doesn't conform to
<p id="rfc.section.3.4.1.p.5">An origin server <em class="bcp14">MAY</em> generate a <a href="#header.vary" class="smpl">Vary</a> header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;8.2.1</a>) in responses that are subject to proactive negotiation to indicate what parameters of request information might be used
<p id="rfc.section.3.4.2.p.1">With <dfn>reactive negotiation</dfn> (a.k.a., <dfn>agent-driven negotiation</dfn>), selection of the best representation for a response is performed by the user agent after receiving an initial response
from the origin server with a list of alternative resources. If the user agent is not satisfied by the initial response, it
can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to
obtain a different form of representation. Selection of alternatives might be performed automatically by the user agent or
manually by the user selecting from a generated (possibly hypertext) menu.
<p id="rfc.section.3.4.2.p.2">The <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes indicate reactive negotiation when the origin server is unwilling or unable to provide a varying response using
such a mechanism from being developed as an extension.
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h1>
<p id="rfc.section.5.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
<p id="rfc.section.5.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
<p id="rfc.section.5.3.4.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
<p id="rfc.section.5.3.4.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
<td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
<td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
<td class="left"><a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;6.3.2</a></td>
<td class="left"><a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.3.2</a></td>
<td class="left"><a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;6.3.3</a></td>
<td class="left"><a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.3.3</a></td>
<td class="left"><a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;6.3.4</a></td>
<td class="left"><a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3.4</a></td>
<td class="left"><a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;6.3.5</a></td>
<td class="left"><a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.3.5</a></td>
<td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;6.5.3</a></td>
<td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;6.5.3</a></td>
<h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
<p id="rfc.section.7.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
<p id="rfc.section.7.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
<td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
<td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
<td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
<td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.4" title="Accept">Section&nbsp;6.3.2</a>
<td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;6.3.2</a>
<td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;6.3.3</a>
<td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;6.3.3</a>
<td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Section&nbsp;6.3.4</a>
<td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;6.3.4</a>
<td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.3" title="Accept-Language">Section&nbsp;6.3.5</a>
<td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;6.3.5</a>
<td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;6.5.3</a>
<td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;6.5.3</a>
<td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Section&nbsp;6.3.4</a>
<p id="rfc.section.10.1.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;6.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;8.4.2</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
<p id="rfc.section.10.1.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;6.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;8.4.2</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
<p id="rfc.section.A.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;3.1.1.3</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
<p id="rfc.section.C.p.15">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section&nbsp;6.3.3</a>)
<p id="rfc.section.C.p.15">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;6.3.3</a>)
<p id="rfc.section.C.p.16">Requirements for sending the Date header field have been clarified. (<a href="#header.date" id="rfc.xref.header.date.4" title="Date">Section&nbsp;8.1.1.2</a>)
<li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.1.1.1</a>, <a href="#rfc.xref.header.accept.2">3.4.1</a>, <a href="#rfc.xref.header.accept.3">6.3</a>, <a href="#rfc.iref.a.1"><b>6.3.2</b></a>, <a href="#rfc.xref.header.accept.4">9.3.2</a></li>
<li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">3.4.1</a>, <a href="#rfc.xref.header.accept-charset.2">6.3</a>, <a href="#rfc.iref.a.2"><b>6.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.3">9.3.2</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li>
<li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.1.1.1</a>, <a href="#rfc.xref.header.accept.2">6.3</a>, <a href="#rfc.iref.a.1"><b>6.3.2</b></a>, <a href="#rfc.xref.header.accept.3">9.3.2</a></li>
<li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">6.3</a>, <a href="#rfc.iref.a.2"><b>6.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.2">9.3.2</a>, <a href="#rfc.xref.header.accept-charset.3">C</a></li>
<li>Accept-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-encoding.1">3.1.2.1</a>, <a href="#rfc.xref.header.accept-encoding.2">6.3</a>, <a href="#rfc.iref.a.3"><b>6.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">9.3.2</a>, <a href="#rfc.xref.header.accept-encoding.4">9.4.2</a></li>
<li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">6.3</a>, <a href="#rfc.iref.a.4"><b>6.3.5</b></a>, <a href="#rfc.xref.header.accept-language.2">9.3.2</a></li>
<li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.3</a>, <a href="#rfc.xref.Part5.2">5.3.1</a>, <a href="#rfc.xref.Part5.3">5.3.1</a>, <a href="#rfc.xref.Part5.4">5.3.4</a>, <a href="#rfc.xref.Part5.5">6.1</a>, <a href="#rfc.xref.Part5.6">6.2</a>, <a href="#rfc.xref.Part5.7">7.1</a>, <a href="#rfc.xref.Part5.8">7.1</a>, <a href="#rfc.xref.Part5.9">7.1</a>, <a href="#rfc.xref.Part5.10">8.4</a>, <a href="#Part5"><b>12.1</b></a><ul>
<li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">7.1</a></li>
<li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">7.1</a></li>
<li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">7.1</a></li>
<li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">8.4</a></li>
<li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.3</a>, <a href="#rfc.xref.Part5.4">5.3.4</a></li>
<li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">6.2</a></li>
<li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">5.3.1</a>, <a href="#rfc.xref.Part5.5">6.1</a></li>
<li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1.1.4</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">5.3.1</a>, <a href="#rfc.xref.Part5.4">5.3.1</a>, <a href="#rfc.xref.Part5.5">5.3.4</a>, <a href="#rfc.xref.Part5.6">6.1</a>, <a href="#rfc.xref.Part5.7">6.2</a>, <a href="#rfc.xref.Part5.8">7.1</a>, <a href="#rfc.xref.Part5.9">7.1</a>, <a href="#rfc.xref.Part5.10">7.1</a>, <a href="#rfc.xref.Part5.11">8.4</a>, <a href="#Part5"><b>12.1</b></a><ul>
<li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">7.1</a></li>
<li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">7.1</a></li>
<li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">7.1</a></li>
<li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.11">8.4</a></li>
<li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.5">5.3.4</a></li>
<li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">6.2</a></li>
<li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">5.3.1</a>, <a href="#rfc.xref.Part5.6">6.1</a></li>
<li><em>RFC2049</em>&nbsp;&nbsp;<a href="#RFC2049"><b>12.2</b></a>, <a href="#rfc.xref.RFC2049.1">A.2</a><ul>
<li><em>RFC2049</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.1">3.1.1.3</a>, <a href="#RFC2049"><b>12.2</b></a>, <a href="#rfc.xref.RFC2049.2">A.2</a><ul>
<li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.2">A.2</a></li>
<li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.4.1</a>, <a href="#rfc.xref.header.user-agent.2">6.5</a>, <a href="#rfc.iref.u.1"><b>6.5.3</b></a>, <a href="#rfc.xref.header.user-agent.3">9.3.2</a>, <a href="#rfc.xref.header.user-agent.4">10.1</a></li>
<li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">6.5</a>, <a href="#rfc.iref.u.1"><b>6.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">9.3.2</a>, <a href="#rfc.xref.header.user-agent.3">10.1</a></li>
<x:anchor-alias value="rule.charset"/>
HTTP uses charset names to indicate or negotiate the character encoding
scheme of a textual representation <xref target="RFC6365"/>.
HTTP uses <x:dfn>charset</x:dfn> names to indicate or negotiate the
character encoding scheme of a textual representation
<xref target="RFC6365"/>.
A charset is identified by a case-insensitive token.
addition, if the text is in a charset that does not
some multi-byte charsets, HTTP allows the use of whatever octet
sequences are defined by that charset to represent the
Internet media types are registered with a canonical form in order to be
interoperable among systems with varying native encoding formats.
Representations selected or transferred via HTTP ought to be in canonical
form, for many of the same reasons described by MIME
<xref target="RFC2049"/>.
However, the performance characteristics of email deployments (i.e., store
and forward messages to peers) are significantly different from those
common to HTTP and the Web (server-based information services).
Furthermore, MIME's constraints for the sake of compatibility with older
mail transfer protocols do not apply to HTTP
(see <xref target="differences.between.http.and.mime"/>).
MIME's canonical form requires that media subtypes of the "text"
type use CRLF as the text line break. HTTP allows the
use octets 13 and 10 for CR and LF, respectively.
This flexibility regarding line breaks applies only to text within a
representation that has been assigned a "text" media type; it does not
apply to "multipart" types or HTTP elements outside the payload body
(e.g., header fields).
data ought to be in a form defined above prior to being encoded.
A recipient &MUST; treat an unrecognized multipart subtype
as being equivalent to "multipart/mixed".
&Note; The "multipart/form-data" type has been specifically defined
HTTP message framing does not use the multipart boundary as an indicator
of message body length, though it might be used by implementations that
generate or process the payload. For example, the "multipart/form-data"
type is often used for carrying form data in a request, as described in
<xref target="RFC2388"/>, and the "multipart/byteranges" type is defined
by this specification for use in some <x:ref>206 (Partial Content)</x:ref>
responses <xref target="Part5"/>.
representation, which defines both the data format and how that data
&SHOULD; be processed by the recipient (within the scope of the request
method semantics) after any <x:ref>Content-Encoding</x:ref> is decoded.
For responses to the HEAD method, the media type is
associated representation: either the representation enclosed in
the message payload or the selected representation, as determined by the
message semantics. The indicated media type defines both the data format
and how that data is intended to be processed by a recipient, within the
scope of the received message semantics, after any content codings
indicated by <x:ref>Content-Encoding</x:ref> are decoded.
Media types are defined in <xref target="media.type"/>. An example of the field is
Media types are defined in <xref target="media.type"/>. An example of the
that is always compressed, then that encoding would not be restated in
An origin server &MAY; respond with a status code of
<x:ref>415 (Unsupported Media Type)</x:ref> if a representation in the
request message has a content coding that is not acceptable.
or using different charsets.
<x:anchor-alias value="content negotiation"/>
When responses convey a representation, whether indicating a success or
an error, the origin server often has different ways of representing that
information; for example, in different formats, languages, or encodings.
Likewise, different users or user agents might have differing capabilities,
characteristics, or preferences that could influence which representation,
among those available, would be best to deliver. For this reason, HTTP
provides mechanisms for <x:ref>content negotiation</x:ref>.
This specification defines two patterns of content negotiation that can
be made visible within the protocol:
upon the user agent's stated preferences, and "reactive" negotiation,
where the server provides a list of representations for the user agent to
choose from. Other patterns of content negotiation include
"conditional content", where the representation consists of multiple
parts that are selectively rendered based on user agent parameters,
"active content", where the representation contains a script that
makes additional (more specific) requests based on the user agent
characteristics, and "Transparent Content Negotiation"
(<xref target="RFC2295"/>), where content selection is performed by
an intermediary. These patterns are not mutually exclusive, and each has
trade-offs in applicability and practicality.
Note that, in all cases, the supplier of representations to the origin
server determines which representations might be considered to be the
"same information".
<x:anchor-alias value="proactive negotiation"/>
<x:anchor-alias value="server-driven negotiation"/>
When content negotiation preferences are sent by the user agent in a
request in order to encourage an algorithm located at the server to
select the preferred representation, it is called
<x:dfn>proactive negotiation</x:dfn>
(a.k.a., <x:dfn>server-driven negotiation</x:dfn>). Selection is based on
the available representations for a response (the dimensions over which it
might vary; e.g., language, content-coding, etc.) compared to various
information supplied in the request, including both the explicit
negotiation fields of <xref target="request.conneg"/> and implicit
characteristics, such as the client's network address or parts of the
<x:ref>User-Agent</x:ref> field.
describe to a user agent, or when the server desires to send its
"best guess" to the user agent along with the first response (hoping to
guess, the user agent &MAY; include request header fields (<x:ref>Accept</x:ref>,
<x:ref>Accept-Language</x:ref>, <x:ref>Accept-Encoding</x:ref>, etc.) which describe its
guess, a user agent &MAY; send request header fields that describe
potential risk to the user's privacy;
sending a response that doesn't conform to the user agent's preferences is
better than sending a <x:ref>406 (Not Acceptable)</x:ref> response.
(<xref target="header.accept-charset"/>), <x:ref>Accept-Encoding</x:ref>
(<xref target="header.accept-encoding"/>), <x:ref>Accept-Language</x:ref>
(<xref target="header.accept-language"/>), and <x:ref>User-Agent</x:ref>
(&header-user-agent;).
&Note; In practice, <x:ref>User-Agent</x:ref> based negotiation is fragile,
The <x:ref>Vary</x:ref> header field (<xref target="header.vary"/>) can be
used to express the parameters the server uses to select a representation
that is subject to proactive negotiation.
consistently honored, since the origin server might not implement proactive
negotiation for the requested resource or might decide that sending a
response that doesn't conform to the user agent's preferences is better
than sending a <x:ref>406 (Not Acceptable)</x:ref> response.
<x:anchor-alias value="reactive negotiation"/>
<x:anchor-alias value="agent-driven negotiation"/>
With <x:dfn>reactive negotiation</x:dfn>
(a.k.a., <x:dfn>agent-driven negotiation</x:dfn>), selection of the best
representation for a response is performed by the user agent after
receiving an initial response from the origin server with a list of
alternative resources. If the user agent is not satisfied by the initial
response, it can perform a GET request on one or more of the alternative
resources, selected based on metadata included in the list, to obtain a
different form of representation. Selection of alternatives might be
performed automatically by the user agent or manually by the user selecting
from a generated (possibly hypertext) menu.
The <x:ref>300 (Multiple Choices)</x:ref> and
<x:ref>406 (Not Acceptable)</x:ref> status codes indicate reactive
negotiation when the origin server is unwilling or unable to provide a
varying response using proactive negotiation.
Reactive negotiation suffers from the disadvantages of transmitting
a list of alternatives to the user agent, which degrades user-perceived
latency if transmitted in the header section, and needing a second request
to obtain an alternate representation. Furthermore, this specification
does not define a mechanism for supporting automatic selection, though it
does not prevent such a mechanism from being developed as an extension.
target resource. The format problem might be due to the request's
indicated <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>,
or as a result of inspecting the data directly.