Changeset 2050 for draft-ietf-httpbis


Ignore:
Timestamp:
14/12/12 00:39:56 (8 years ago)
Author:
fielding@…
Message:

Clean up of MIME and conneg; partly addresses #419

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2049 r2050  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 14, 2013";
     451       content: "Expires June 16, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    496496      <meta name="dct.creator" content="Reschke, J. F.">
    497497      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    498       <meta name="dct.issued" scheme="ISO8601" content="2012-12-11">
     498      <meta name="dct.issued" scheme="ISO8601" content="2012-12-13">
    499499      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    500500      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    524524            <tr>
    525525               <td class="left">Intended status: Standards Track</td>
    526                <td class="right">December 11, 2012</td>
     526               <td class="right">December 13, 2012</td>
    527527            </tr>
    528528            <tr>
    529                <td class="left">Expires: June 14, 2013</td>
     529               <td class="left">Expires: June 16, 2013</td>
    530530               <td class="right"></td>
    531531            </tr>
    … …  
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on June 14, 2013.</p>
     557      <p>This Internet-Draft will expire on June 16, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    919919      </p>
    920920      <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a>&nbsp;<a id="charset" href="#charset">Charset</a></h4>
    921       <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.
     921      <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.
    922922      </p>
    923923      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#charset" class="smpl">charset</a> = <a href="#imported.abnf" class="smpl">token</a>
    … …  
    925925      </p>
    926926      <h4 id="rfc.section.3.1.1.3"><a href="#rfc.section.3.1.1.3">3.1.1.3</a>&nbsp;<a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h4>
    927       <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.
    928       </p>
    929       <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
    930          allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an
    931          entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is
    932          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
    933          allows the use of whatever octet sequences are defined by that charset to represent the equivalent of CR and LF for line breaks.
    934          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).
    935       </p>
    936       <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.
     927      <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
     928         formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described
     929         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
     930         different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the
     931         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>).
     932      </p>
     933      <p id="rfc.section.3.1.1.3.p.2">MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break. HTTP allows the transfer
     934         of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.
     935         HTTP senders <em class="bcp14">MAY</em> generate, and recipients <em class="bcp14">MUST</em> be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF. In addition, text media in HTTP is
     936         not limited to charsets that use octets 13 and 10 for CR and LF, respectively. This flexibility regarding line breaks applies
     937         only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or
     938         HTTP elements outside the payload body (e.g., header fields).
     939      </p>
     940      <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
     941         encoded.
    937942      </p>
    938943      <h4 id="rfc.section.3.1.1.4"><a href="#rfc.section.3.1.1.4">3.1.1.4</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h4>
    … …  
    940945         All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and include a boundary parameter as part of the media type value. The message body is itself a protocol element; a sender <em class="bcp14">MUST</em> generate only CRLF to represent line breaks between body-parts.
    941946      </p>
    942       <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
    943          not use the multipart boundary as an indicator of message body length.  In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
    944          each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics.
    945       </p>
    946       <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".
    947       </p>
    948       <div class="note" id="rfc.section.3.1.1.4.p.4">
    949          <p> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
    950             method, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>.
    951          </p>
    952       </div>
     947      <p id="rfc.section.3.1.1.4.p.2">HTTP message framing does not use the multipart boundary as an indicator of message body length, though it might be used by
     948         implementations that generate or process the payload. For example, the "multipart/form-data" type is often used for carrying
     949         form data in a request, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>, and the "multipart/byteranges" type is defined by this specification for use in some <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> responses <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
     950      </p>
    953951      <div id="rfc.iref.c.2"></div>
    954952      <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>
    955       <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
    956          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.
     953      <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
     954         in the message payload or the selected representation, as determined by the message semantics. The indicated media type defines
     955         both the data format and how that data is intended to be processed by a recipient, within the scope of the received message
     956         semantics, after any content codings indicated by <a href="#header.content-encoding" class="smpl">Content-Encoding</a> are decoded.
    957957      </p>
    958958      <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>
    … …  
    10131013      </p>
    10141014      <p id="rfc.section.3.1.2.2.p.7">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would
    1015          not be restated as a Content-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content
     1015         not be restated in Content-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content
    10161016         coding would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise,
    10171017         an origin server might choose to publish the same payload data as multiple representations that differ only in whether the
    … …  
    10191019         as ..." dialog instead of automatic decompression and rendering of content).
    10201020      </p>
    1021       <p id="rfc.section.3.1.2.2.p.8">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
     1021      <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.
    10221022      </p>
    10231023      <h3 id="rfc.section.3.1.3"><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;<a id="audience.language" href="#audience.language">Audience Language</a></h3>
    … …  
    11801180               <tr>
    11811181                  <td class="left">Content-Range</td>
    1182                   <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>
     1182                  <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.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    11831183               </tr>
    11841184               <tr>
    … …  
    11901190      </div>
    11911191      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>
    1192       <p id="rfc.section.3.4.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
    1193          processing. Often, the server has different ways of representing the same information; for example, in different formats,
    1194          languages, or using different charsets.
    1195       </p>
    1196       <p id="rfc.section.3.4.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
    1197          which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
    1198          provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when
    1199          more than one is available.
    1200       </p>
    1201       <p id="rfc.section.3.4.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based
    1202          upon the client's stated preferences, and "reactive" negotiation, where the server provides a list of representations for
    1203          the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an "active
    1204          content" pattern, where the server returns active content which runs on the client and, based on client available parameters,
    1205          selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
    1206       </p>
    1207       <p id="rfc.section.3.4.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
    1208          of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
    1209          a user agent), proactive negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
    1210          to choose from is very large, reactive negotiation might not be appropriate.
    1211       </p>
    1212       <p id="rfc.section.3.4.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might
    1213          be considered to be the "same information".
     1192      <p id="rfc.section.3.4.p.1">When responses convey a representation, whether indicating a success or an error, the origin server often has different ways
     1193         of representing that information; for example, in different formats, languages, or encodings. Likewise, different users or
     1194         user agents might have differing capabilities, characteristics, or preferences that could influence which representation,
     1195         among those available, would be best to deliver. For this reason, HTTP provides mechanisms for <a href="#content.negotiation" class="smpl">content negotiation</a>.
     1196      </p>
     1197      <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",
     1198         where the server selects the representation based upon the user agent's stated preferences, and "reactive" negotiation, where
     1199         the server provides a list of representations for the user agent to choose from. Other patterns of content negotiation include
     1200         "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent
     1201         parameters, "active content", where the representation contains a script that makes additional (more specific) requests based
     1202         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
     1203         in applicability and practicality.
     1204      </p>
     1205      <p id="rfc.section.3.4.p.3">Note that, in all cases, the supplier of representations to the origin server determines which representations might be considered
     1206         to be the "same information".
    12141207      </p>
    12151208      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
    1216       <p id="rfc.section.3.4.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive
    1217          negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g.,
    1218          language, content-coding, etc.) and the contents of particular header fields in the request message or on other information
    1219          pertaining to the request (such as the network address of the client).
     1209      <p id="rfc.section.3.4.1.p.1">When content negotiation preferences are sent by the user agent in a request in order to encourage an algorithm located at
     1210         the server to select the preferred representation, it is called <dfn>proactive negotiation</dfn> (a.k.a., <dfn>server-driven negotiation</dfn>). Selection is based on the available representations for a response (the dimensions over which it might vary; e.g., language,
     1211         content-coding, etc.) compared to various information supplied in the request, including both the explicit negotiation fields
     1212         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.
    12201213      </p>
    12211214      <p id="rfc.section.3.4.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
    1222          to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
     1215         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
    12231216         (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
    1224          improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response.
    1225       </p>
    1226       <p id="rfc.section.3.4.1.p.3">Proactive negotiation has disadvantages: </p>
    1227       <ol>
     1217         improve the server's guess, a user agent <em class="bcp14">MAY</em> send request header fields that describe its preferences.
     1218      </p>
     1219      <p id="rfc.section.3.4.1.p.3">Proactive negotiation has serious disadvantages: </p>
     1220      <ul>
    12281221         <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require
    12291222            complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want
    1230             to view it on screen or print it on paper?).
     1223            to view it on screen or print it on paper?);
    12311224         </li>
    12321225         <li>Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage
    1233             of responses have multiple representations) and a potential violation of the user's privacy.
    1234          </li>
    1235          <li>It complicates the implementation of an origin server and the algorithms for generating responses to a request.</li>
    1236          <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    1237       </ol>
    1238       <p id="rfc.section.3.4.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.
    1239          For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that
    1240          doesn't conform to the user agent's preferences is better than sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response.
    1241       </p>
    1242       <p id="rfc.section.3.4.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
    1243          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
    1244          within extension header fields not defined by this specification.
    1245       </p>
    1246       <div class="note" id="rfc.section.3.4.1.p.6">
    1247          <p> <b>Note:</b> In practice, <a href="#header.user-agent" class="smpl">User-Agent</a> based negotiation is fragile, because new clients might not be recognized.
    1248          </p>
    1249       </div>
    1250       <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.
     1226            of responses have multiple representations) and a potential risk to the user's privacy;
     1227         </li>
     1228         <li>It complicates the implementation of an origin server and the algorithms for generating responses to a request; and,</li>
     1229         <li>It limits the reusability of responses for shared caching.</li>
     1230      </ul>
     1231      <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
     1232         implement proactive negotiation for the requested resource or might decide that sending a response that doesn't conform to
     1233         the user agent's preferences is better than sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response.
     1234      </p>
     1235      <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
     1236         in its selection algorithm, thereby providing a means for recipients to determine the reusability of that same response for
     1237         user agents with differing request information.
    12511238      </p>
    12521239      <h3 id="rfc.section.3.4.2"><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;<a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>
    1253       <p id="rfc.section.3.4.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving
    1254          an initial response from the origin server. Selection is based on a list of the available representations of the response
    1255          included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
    1256          from among the representations can be performed automatically (if the user agent is capable of doing so) or manually by the
    1257          user selecting from a generated (possibly hypertext) menu.
    1258       </p>
    1259       <p id="rfc.section.3.4.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
     1240      <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
     1241         from the origin server with a list of alternative resources. If the user agent is not satisfied by the initial response, it
     1242         can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to
     1243         obtain a different form of representation. Selection of alternatives might be performed automatically by the user agent or
     1244         manually by the user selecting from a generated (possibly hypertext) menu.
     1245      </p>
     1246      <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
     1247         proactive negotiation.
     1248      </p>
     1249      <p id="rfc.section.3.4.2.p.3">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
    12601250         encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
    12611251         when public caches are used to distribute server load and reduce network usage.
    12621252      </p>
    1263       <p id="rfc.section.3.4.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
    1264          This second request is only efficient when caching is used. In addition, this specification does not define any mechanism
    1265          for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension
    1266          and used within HTTP/1.1.
    1267       </p>
    1268       <p id="rfc.section.3.4.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using
    1269          proactive negotiation.
     1253      <p id="rfc.section.3.4.2.p.4">Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades
     1254         user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation.
     1255         Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent
     1256         such a mechanism from being developed as an extension.
    12701257      </p>
    12711258      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h1>
    … …  
    14241411         to be refreshed without requiring multiple requests or transferring data already held by the client.
    14251412      </p>
    1426       <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
     1413      <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
    14271414         to be completed without transferring data already held by the client.
    14281415      </p>
    … …  
    15231510         the related resources.
    15241511      </p>
    1525       <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
     1512      <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
    15261513         representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps
    15271514         a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for
    … …  
    16501637               <tr>
    16511638                  <td class="left">Range</td>
    1652                   <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>
     1639                  <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    16531640               </tr>
    16541641            </tbody>
    … …  
    17721759               <tr>
    17731760                  <td class="left">If-Range</td>
    1774                   <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>
     1761                  <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.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    17751762               </tr>
    17761763            </tbody>
    … …  
    17891776               <tr>
    17901777                  <td class="left">Accept</td>
    1791                   <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;6.3.2</a></td>
     1778                  <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.3.2</a></td>
    17921779               </tr>
    17931780               <tr>
    17941781                  <td class="left">Accept-Charset</td>
    1795                   <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>
     1782                  <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>
    17961783               </tr>
    17971784               <tr>
    17981785                  <td class="left">Accept-Encoding</td>
    1799                   <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>
     1786                  <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>
    18001787               </tr>
    18011788               <tr>
    18021789                  <td class="left">Accept-Language</td>
    1803                   <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>
     1790                  <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>
    18041791               </tr>
    18051792            </tbody>
    … …  
    20572044               <tr>
    20582045                  <td class="left">User-Agent</td>
    2059                   <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>
     2046                  <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>
    20602047               </tr>
    20612048            </tbody>
    … …  
    21472134      </p>
    21482135      <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>
    2149       <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
     2136      <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
    21502137         protocol.
    21512138      </p>
    … …  
    22032190                  <td class="left">206</td>
    22042191                  <td class="left">Partial Content</td>
    2205                   <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>
     2192                  <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.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    22062193               </tr>
    22072194               <tr>
    … …  
    23232310                  <td class="left">416</td>
    23242311                  <td class="left">Requested Range Not Satisfiable</td>
    2325                   <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.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
     2312                  <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>
    23262313               </tr>
    23272314               <tr>
    … …  
    26992686      <h3 id="rfc.section.7.5.13"><a href="#rfc.section.7.5.13">7.5.13</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
    27002687      <p id="rfc.section.7.5.13.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method
    2701          on the target resource.
     2688         on the target resource. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.
    27022689      </p>
    27032690      <div id="rfc.iref.74"></div>
    … …  
    30553042               <tr>
    30563043                  <td class="left">Accept-Ranges</td>
    3057                   <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>
     3044                  <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.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    30583045               </tr>
    30593046               <tr>
    … …  
    35433530                  <td class="left">http</td>
    35443531                  <td class="left">standard</td>
    3545                   <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.4" title="Accept">Section&nbsp;6.3.2</a>
     3532                  <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;6.3.2</a>
    35463533                  </td>
    35473534               </tr>
    … …  
    35503537                  <td class="left">http</td>
    35513538                  <td class="left">standard</td>
    3552                   <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;6.3.3</a>
     3539                  <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;6.3.3</a>
    35533540                  </td>
    35543541               </tr>
    … …  
    35573544                  <td class="left">http</td>
    35583545                  <td class="left">standard</td>
    3559                   <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Section&nbsp;6.3.4</a>
     3546                  <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;6.3.4</a>
    35603547                  </td>
    35613548               </tr>
    … …  
    35643551                  <td class="left">http</td>
    35653552                  <td class="left">standard</td>
    3566                   <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.3" title="Accept-Language">Section&nbsp;6.3.5</a>
     3553                  <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;6.3.5</a>
    35673554                  </td>
    35683555               </tr>
    … …  
    36693656                  <td class="left">http</td>
    36703657                  <td class="left">standard</td>
    3671                   <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;6.5.3</a>
     3658                  <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;6.5.3</a>
    36723659                  </td>
    36733660               </tr>
    … …  
    37343721                  <td class="left">reserved (synonym for "no encoding" in <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> header field)
    37353722                  </td>
    3736                   <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Section&nbsp;6.3.4</a>
     3723                  <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Section&nbsp;6.3.4</a>
    37373724                  </td>
    37383725               </tr>
    … …  
    37663753         of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information.
    37673754      </p>
    3768       <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
     3755      <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
    37693756         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
    37703757         no better mechanism.
    … …  
    40464033      </p>
    40474034      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2>
    4048       <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.1"><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
     4035      <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
    40494036         break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
    40504037         over HTTP.
    … …  
    41214108         semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;6.1.2</a>)
    41224109      </p>
    4123       <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>)
     4110      <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>)
    41244111      </p>
    41254112      <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>)
    … …  
    44114398            </li>
    44124399            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    4413                   <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>
    4414                   <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>
    4415                   <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">3.4.1</a>, <a href="#rfc.xref.header.accept-encoding.3">6.3</a>, <a href="#rfc.iref.a.3"><b>6.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.4">9.3.2</a>, <a href="#rfc.xref.header.accept-encoding.5">9.4.2</a></li>
    4416                   <li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">3.4.1</a>, <a href="#rfc.xref.header.accept-language.2">6.3</a>, <a href="#rfc.iref.a.4"><b>6.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li>
     4400                  <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>
     4401                  <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>
     4402                  <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>
     4403                  <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>
    44174404                  <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">5.1</a>, <a href="#rfc.xref.header.allow.2">8.4</a>, <a href="#rfc.iref.a.5"><b>8.4.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3.2</a>, <a href="#rfc.xref.header.allow.4">C</a>, <a href="#rfc.xref.header.allow.5">C</a></li>
    44184405               </ul>
    … …  
    45884575                     </ul>
    45894576                  </li>
    4590                   <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>
    4591                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">7.1</a></li>
    4592                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">7.1</a></li>
    4593                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">7.1</a></li>
    4594                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">8.4</a></li>
    4595                         <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>
    4596                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">6.2</a></li>
    4597                         <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>
     4577                  <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>
     4578                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">7.1</a></li>
     4579                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">7.1</a></li>
     4580                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">7.1</a></li>
     4581                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.11">8.4</a></li>
     4582                        <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>
     4583                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">6.2</a></li>
     4584                        <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>
    45984585                     </ul>
    45994586                  </li>
    … …  
    46464633                     </ul>
    46474634                  </li>
    4648                   <li><em>RFC2049</em>&nbsp;&nbsp;<a href="#RFC2049"><b>12.2</b></a>, <a href="#rfc.xref.RFC2049.1">A.2</a><ul>
    4649                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.1">A.2</a></li>
     4635                  <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>
     4636                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.2">A.2</a></li>
    46504637                     </ul>
    46514638                  </li>
    … …  
    47314718            </li>
    47324719            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    4733                   <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>
     4720                  <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>
    47344721               </ul>
    47354722            </li>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2047 r2050  
    388388  <x:anchor-alias value="rule.charset"/>
    389389<t>
    390    HTTP uses charset names to indicate or negotiate the character encoding
    391    scheme of a textual representation <xref target="RFC6365"/>.
     390   HTTP uses <x:dfn>charset</x:dfn> names to indicate or negotiate the
     391   character encoding scheme of a textual representation
     392   <xref target="RFC6365"/>.
    392393   A charset is identified by a case-insensitive token.
    393394</t>
    … …  
    404405<section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
    405406<t>
    406    Internet media types are registered with a canonical form. A
    407    representation transferred via HTTP messages &MUST; be in the
    408    appropriate canonical form prior to its transmission except for
    409    "text" types, as defined in the next paragraph.
    410 </t>
    411 <t>
    412    When in canonical form, media subtypes of the "text" type use CRLF as
    413    the text line break. HTTP relaxes this requirement and allows the
    414    transport of text media with plain CR or LF alone representing a line
    415    break when it is done consistently for an entire representation. HTTP
    416    applications &MUST; accept CRLF, bare CR, and bare LF as indicating
    417    a line break in text media received via HTTP. In
    418    addition, if the text is in a charset that does not
    419    use octets 13 and 10 for CR and LF respectively, as is the case for
    420    some multi-byte charsets, HTTP allows the use of whatever octet
    421    sequences are defined by that charset to represent the
    422    equivalent of CR and LF for line breaks. This flexibility regarding
    423    line breaks applies only to text media in the payload body; a bare CR
    424    or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control
    425    structures (such as header fields and multipart boundaries).
     407   Internet media types are registered with a canonical form in order to be
     408   interoperable among systems with varying native encoding formats.
     409   Representations selected or transferred via HTTP ought to be in canonical
     410   form, for many of the same reasons described by MIME
     411   <xref target="RFC2049"/>.
     412   However, the performance characteristics of email deployments (i.e., store
     413   and forward messages to peers) are significantly different from those
     414   common to HTTP and the Web (server-based information services).
     415   Furthermore, MIME's constraints for the sake of compatibility with older
     416   mail transfer protocols do not apply to HTTP
     417   (see <xref target="differences.between.http.and.mime"/>).
     418</t>
     419<t>
     420   MIME's canonical form requires that media subtypes of the "text"
     421   type use CRLF as the text line break. HTTP allows the
     422   transfer of text media with plain CR or LF alone representing a line
     423   break, when such line breaks are consistent for an entire representation.
     424   HTTP senders &MAY; generate, and recipients &MUST; be able to parse,
     425   line breaks in text media that consist of CRLF, bare CR, or bare LF.
     426   In addition, text media in HTTP is not limited to charsets that
     427   use octets 13 and 10 for CR and LF, respectively.
     428   This flexibility regarding line breaks applies only to text within a
     429   representation that has been assigned a "text" media type; it does not
     430   apply to "multipart" types or HTTP elements outside the payload body
     431   (e.g., header fields).
    426432</t>
    427433<t>
    428434   If a representation is encoded with a content-coding, the underlying
    429    data &MUST; be in a form defined above prior to being encoded.
     435   data ought to be in a form defined above prior to being encoded.
    430436</t>
    431437</section>
    … …  
    441447</t>
    442448<t>
    443    In general, HTTP treats a multipart message body no differently than
    444    any other media type: strictly as payload.  HTTP does not use the
    445    multipart boundary as an indicator of message body length.
    446    <!-- jre: re-insert removed text pointing to caching? -->
    447    In all other respects, an HTTP user agent &SHOULD; follow the same or similar
    448    behavior as a MIME user agent would upon receipt of a multipart type.
    449    The MIME header fields within each body-part of a multipart message body
    450    do not have any significance to HTTP beyond that defined by
    451    their MIME semantics.
    452 </t>
    453 <t>
    454    A recipient &MUST; treat an unrecognized multipart subtype
    455    as being equivalent to "multipart/mixed".
    456 </t>
    457 <x:note>
    458   <t>
    459     &Note; The "multipart/form-data" type has been specifically defined
    460     for carrying form data suitable for processing via the POST
    461     request method, as described in <xref target="RFC2388"/>.
    462   </t>
    463 </x:note>
     449   HTTP message framing does not use the multipart boundary as an indicator
     450   of message body length, though it might be used by implementations that
     451   generate or process the payload. For example, the "multipart/form-data"
     452   type is often used for carrying form data in a request, as described in
     453   <xref target="RFC2388"/>, and the "multipart/byteranges" type is defined
     454   by this specification for use in some <x:ref>206 (Partial Content)</x:ref>
     455   responses <xref target="Part5"/>.
     456</t>
    464457</section>
    465458
    … …  
    469462<t>
    470463   The "Content-Type" header field indicates the media type of the
    471    representation, which defines both the data format and how that data
    472    &SHOULD; be processed by the recipient (within the scope of the request
    473    method semantics) after any <x:ref>Content-Encoding</x:ref> is decoded.
    474    For responses to the HEAD method, the media type is
    475    that which would have been sent had the request been a GET.
     464   associated representation: either the representation enclosed in
     465   the message payload or the selected representation, as determined by the
     466   message semantics.  The indicated media type defines both the data format
     467   and how that data is intended to be processed by a recipient, within the
     468   scope of the received message semantics, after any content codings
     469   indicated by <x:ref>Content-Encoding</x:ref> are decoded.
    476470</t>
    477471<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
    … …  
    479473</artwork></figure>
    480474<t>
    481    Media types are defined in <xref target="media.type"/>. An example of the field is
     475   Media types are defined in <xref target="media.type"/>. An example of the
     476   field is
    482477</t>
    483478<figure><artwork type="example">
    … …  
    584579<t>
    585580   If the media type includes an inherent encoding, such as a data format
    586    that is always compressed, then that encoding would not be restated as
    587    a Content-Encoding even if it happens to be the same algorithm as one
     581   that is always compressed, then that encoding would not be restated in
     582   Content-Encoding even if it happens to be the same algorithm as one
    588583   of the content codings.  Such a content coding would only be listed if,
    589584   for some bizarre reason, it is applied a second time to form the
    … …  
    596591</t>
    597592<t>
    598    If the content-coding of a representation in a request message is not
    599    acceptable to the origin server, the server &SHOULD; respond with a
    600    status code of 415 (Unsupported Media Type).
     593   An origin server &MAY; respond with a status code of
     594   <x:ref>415 (Unsupported Media Type)</x:ref> if a representation in the
     595   request message has a content coding that is not acceptable.
    601596</t>
    602597</section>
    … …  
    903898
    904899<section title="Content Negotiation" anchor="content.negotiation">
    905 <t>
    906    HTTP responses include a representation which contains information for
    907    interpretation, whether by a human user or for further processing.
    908    Often, the server has different ways of representing the
    909    same information; for example, in different formats, languages,
    910    or using different charsets.
    911 </t>
    912 <t>
    913    HTTP clients and their users might have different or variable
    914    capabilities, characteristics or preferences which would influence
    915    which representation, among those available from the server,
    916    would be best for the server to deliver. For this reason, HTTP
    917    provides mechanisms for "content negotiation" &mdash; a process of
    918    allowing selection of a representation of a given resource,
    919    when more than one is available.
    920 </t>
    921 <t>
    922    This specification defines two patterns of content negotiation;
     900  <x:anchor-alias value="content negotiation"/>
     901<t>
     902   When responses convey a representation, whether indicating a success or
     903   an error, the origin server often has different ways of representing that
     904   information; for example, in different formats, languages, or encodings.
     905   Likewise, different users or user agents might have differing capabilities,
     906   characteristics, or preferences that could influence which representation,
     907   among those available, would be best to deliver. For this reason, HTTP
     908   provides mechanisms for <x:ref>content negotiation</x:ref>.
     909</t>
     910<t>
     911   This specification defines two patterns of content negotiation that can
     912   be made visible within the protocol:
    923913   "proactive", where the server selects the representation based
    924    upon the client's stated preferences, and "reactive" negotiation,
    925    where the server provides a list of representations for the client to
    926    choose from, based upon their metadata. In addition,  there are
    927    other patterns: some applications use an "active content" pattern,
    928    where the server returns active content which runs on the client
    929    and, based on client available parameters, selects additional
    930    resources to invoke. "Transparent Content Negotiation" (<xref target="RFC2295"/>)
    931    has also been proposed.
    932 </t>
    933 <t>
    934    These patterns are all widely used, and have trade-offs in applicability
    935    and practicality. In particular, when the number of preferences or
    936    capabilities to be expressed by a client are large (such as when many
    937    different formats are supported by a user agent), proactive
    938    negotiation becomes unwieldy, and might not be appropriate. Conversely,
    939    when the number of representations to choose from is very large,
    940    reactive negotiation might not be appropriate.
    941 </t>
    942 <t>
    943    Note that, in all cases, the supplier of representations has the
    944    responsibility for determining which representations might be
    945    considered to be the "same information".
     914   upon the user agent's stated preferences, and "reactive" negotiation,
     915   where the server provides a list of representations for the user agent to
     916   choose from. Other patterns of content negotiation include
     917   "conditional content", where the representation consists of multiple
     918   parts that are selectively rendered based on user agent parameters,
     919   "active content", where the representation contains a script that
     920   makes additional (more specific) requests based on the user agent
     921   characteristics, and "Transparent Content Negotiation"
     922   (<xref target="RFC2295"/>), where content selection is performed by
     923   an intermediary. These patterns are not mutually exclusive, and each has
     924   trade-offs in applicability and practicality.
     925</t>
     926<t>
     927   Note that, in all cases, the supplier of representations to the origin
     928   server determines which representations might be considered to be the
     929   "same information".
    946930</t>
    947931
    948932<section title="Proactive Negotiation" anchor="proactive.negotiation">
    949 <t>
    950    If the selection of the best representation for a response is made by
    951    an algorithm located at the server, it is called proactive
    952    negotiation. Selection is based on the available representations of
    953    the response (the dimensions over which it can vary; e.g., language,
    954    content-coding, etc.) and the contents of particular header fields in
    955    the request message or on other information pertaining to the request
    956    (such as the network address of the client).
     933  <x:anchor-alias value="proactive negotiation"/>
     934  <x:anchor-alias value="server-driven negotiation"/>
     935<t>
     936   When content negotiation preferences are sent by the user agent in a
     937   request in order to encourage an algorithm located at the server to
     938   select the preferred representation, it is called
     939   <x:dfn>proactive negotiation</x:dfn>
     940   (a.k.a., <x:dfn>server-driven negotiation</x:dfn>). Selection is based on
     941   the available representations for a response (the dimensions over which it
     942   might vary; e.g., language, content-coding, etc.) compared to various
     943   information supplied in the request, including both the explicit
     944   negotiation fields of <xref target="request.conneg"/> and implicit
     945   characteristics, such as the client's network address or parts of the
     946   <x:ref>User-Agent</x:ref> field.
    957947</t>
    958948<t>
    959949   Proactive negotiation is advantageous when the algorithm for
    960950   selecting from among the available representations is difficult to
    961    describe to the user agent, or when the server desires to send its
    962    "best guess" to the client along with the first response (hoping to
     951   describe to a user agent, or when the server desires to send its
     952   "best guess" to the user agent along with the first response (hoping to
    963953   avoid the round-trip delay of a subsequent request if the "best
    964954   guess" is good enough for the user). In order to improve the server's
    965    guess, the user agent &MAY; include request header fields (<x:ref>Accept</x:ref>,
    966    <x:ref>Accept-Language</x:ref>, <x:ref>Accept-Encoding</x:ref>, etc.) which describe its
    967    preferences for such a response.
    968 </t>
    969 <t>
    970    Proactive negotiation has disadvantages:
    971   <list style="numbers">
     955   guess, a user agent &MAY; send request header fields that describe
     956   its preferences.
     957</t>
     958<t>
     959   Proactive negotiation has serious disadvantages:
     960  <list style="symbols">
    972961    <t>
    973962         It is impossible for the server to accurately determine what
    … …  
    975964         complete knowledge of both the capabilities of the user agent
    976965         and the intended use for the response (e.g., does the user want
    977          to view it on screen or print it on paper?).
     966         to view it on screen or print it on paper?);
    978967    </t>
    979968    <t>
    … …  
    981970         request can be both very inefficient (given that only a small
    982971         percentage of responses have multiple representations) and a
    983          potential violation of the user's privacy.
     972         potential risk to the user's privacy;
    984973    </t>
    985974    <t>
    986975         It complicates the implementation of an origin server and the
    987          algorithms for generating responses to a request.
     976         algorithms for generating responses to a request; and,
    988977    </t>
    989978    <t>
    990          It might limit a public cache's ability to use the same response
    991          for multiple user's requests.
     979         It limits the reusability of responses for shared caching.
    992980    </t>
    993981  </list>
    994982</t>
    995983<t>
    996    Proactive negotiation allows the user agent to specify its preferences,
    997    but it cannot expect responses to always honor them. For example, the origin
    998    server might not implement proactive negotiation, or it might decide that
    999    sending a response that doesn't conform to the user agent's preferences is
    1000    better than sending a <x:ref>406 (Not Acceptable)</x:ref> response.
    1001 </t>
    1002 <t>
    1003    HTTP/1.1 includes the following header fields for enabling
    1004    proactive negotiation through description of user agent
    1005    capabilities and user preferences: <x:ref>Accept</x:ref>
    1006    (<xref target="header.accept"/>), <x:ref>Accept-Charset</x:ref>
    1007    (<xref target="header.accept-charset"/>), <x:ref>Accept-Encoding</x:ref>
    1008    (<xref target="header.accept-encoding"/>), <x:ref>Accept-Language</x:ref>
    1009    (<xref target="header.accept-language"/>), and <x:ref>User-Agent</x:ref>
    1010    (&header-user-agent;).
    1011    However, an origin server is not limited to these dimensions and &MAY; vary
    1012    the response based on any aspect of the request, including aspects
    1013    of the connection (e.g., IP address) or information within extension
    1014    header fields not defined by this specification.
    1015 </t>
    1016 <x:note>
    1017   <t>
    1018     &Note; In practice, <x:ref>User-Agent</x:ref> based negotiation is fragile,
    1019     because new clients might not be recognized.
    1020   </t>
    1021 </x:note>
    1022 <t>
    1023    The <x:ref>Vary</x:ref> header field (<xref target="header.vary"/>) can be
    1024    used to express the parameters the server uses to select a representation
    1025    that is subject to proactive negotiation.
     984   A user agent cannot rely on proactive negotiation preferences being
     985   consistently honored, since the origin server might not implement proactive
     986   negotiation for the requested resource or might decide that sending a
     987   response that doesn't conform to the user agent's preferences is better
     988   than sending a <x:ref>406 (Not Acceptable)</x:ref> response.
     989</t>
     990<t>
     991   An origin server &MAY; generate a <x:ref>Vary</x:ref> header field
     992   (<xref target="header.vary"/>) in responses that are subject to proactive
     993   negotiation to indicate what parameters of request information might
     994   be used in its selection algorithm, thereby providing a means for
     995   recipients to determine the reusability of that same response for
     996   user agents with differing request information.
    1026997</t>
    1027998</section>
    1028999
    10291000<section title="Reactive Negotiation" anchor="reactive.negotiation">
    1030 <t>
    1031    With reactive negotiation, selection of the best representation
    1032    for a response is performed by the user agent after receiving an
    1033    initial response from the origin server. Selection is based on a list
    1034    of the available representations of the response included within the
    1035    header fields or body of the initial response, with each
    1036    representation identified by its own URI. Selection from among the
    1037    representations can be performed automatically (if the user agent is
    1038    capable of doing so) or manually by the user selecting from a
    1039    generated (possibly hypertext) menu.
     1001  <x:anchor-alias value="reactive negotiation"/>
     1002  <x:anchor-alias value="agent-driven negotiation"/>
     1003<t>
     1004   With <x:dfn>reactive negotiation</x:dfn>
     1005   (a.k.a., <x:dfn>agent-driven negotiation</x:dfn>), selection of the best
     1006   representation for a response is performed by the user agent after
     1007   receiving an initial response from the origin server with a list of
     1008   alternative resources. If the user agent is not satisfied by the initial
     1009   response, it can perform a GET request on one or more of the alternative
     1010   resources, selected based on metadata included in the list, to obtain a
     1011   different form of representation. Selection of alternatives might be
     1012   performed automatically by the user agent or manually by the user selecting
     1013   from a generated (possibly hypertext) menu.
     1014</t>
     1015<t>
     1016   The <x:ref>300 (Multiple Choices)</x:ref> and
     1017   <x:ref>406 (Not Acceptable)</x:ref> status codes indicate reactive
     1018   negotiation when the origin server is unwilling or unable to provide a
     1019   varying response using proactive negotiation.
    10401020</t>
    10411021<t>
    … …  
    10471027</t>
    10481028<t>
    1049    Reactive negotiation suffers from the disadvantage of needing a
    1050    second request to obtain the best alternate representation. This
    1051    second request is only efficient when caching is used. In addition,
    1052    this specification does not define any mechanism for supporting
    1053    automatic selection, though it also does not prevent any such
    1054    mechanism from being developed as an extension and used within
    1055    HTTP/1.1.
    1056 </t>
    1057 <t>
    1058    This specification defines the <x:ref>300 (Multiple Choices)</x:ref> and
    1059    <x:ref>406 (Not Acceptable)</x:ref> status codes for enabling reactive
    1060    negotiation when the server is unwilling or unable to provide a varying
    1061    response using proactive negotiation.
     1029   Reactive negotiation suffers from the disadvantages of transmitting
     1030   a list of alternatives to the user agent, which degrades user-perceived
     1031   latency if transmitted in the header section, and needing a second request
     1032   to obtain an alternate representation. Furthermore, this specification
     1033   does not define a mechanism for supporting automatic selection, though it
     1034   does not prevent such a mechanism from being developed as an extension.
    10621035</t>
    10631036</section>
    … …  
    33243297   The server is refusing to service the request because the request
    33253298   payload is in a format not supported by this request method on the
    3326    target resource.
     3299   target resource. The format problem might be due to the request's
     3300   indicated <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>,
     3301   or as a result of inspecting the data directly.
    33273302</t>
    33283303</section>
Note: See TracChangeset for help on using the changeset viewer.