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

Clean up of MIME and conneg; partly addresses #419

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.