Changeset 2050 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 14/12/12 00:39:56 (8 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2049 r2050 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 4, 2013";451 content: "Expires June 16, 2013"; 452 452 } 453 453 @bottom-right { … … 496 496 <meta name="dct.creator" content="Reschke, J. F."> 497 497 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 498 <meta name="dct.issued" scheme="ISO8601" content="2012-12-1 1">498 <meta name="dct.issued" scheme="ISO8601" content="2012-12-13"> 499 499 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 500 500 <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."> … … 524 524 <tr> 525 525 <td class="left">Intended status: Standards Track</td> 526 <td class="right">December 1 1, 2012</td>526 <td class="right">December 13, 2012</td> 527 527 </tr> 528 528 <tr> 529 <td class="left">Expires: June 1 4, 2013</td>529 <td class="left">Expires: June 16, 2013</td> 530 530 <td class="right"></td> 531 531 </tr> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on June 1 4, 2013.</p>557 <p>This Internet-Draft will expire on June 16, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 919 919 </p> 920 920 <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a> <a id="charset" href="#charset">Charset</a></h4> 921 <p id="rfc.section.3.1.1.2.p.1">HTTP uses charsetnames 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. 922 922 </p> 923 923 <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> … … 925 925 </p> 926 926 <h4 id="rfc.section.3.1.1.3"><a href="#rfc.section.3.1.1.3">3.1.1.3</a> <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 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. 937 942 </p> 938 943 <h4 id="rfc.section.3.1.1.4"><a href="#rfc.section.3.1.1.4">3.1.1.4</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h4> … … 940 945 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. 941 946 </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> 953 951 <div id="rfc.iref.c.2"></div> 954 952 <h4 id="rfc.section.3.1.1.5"><a href="#rfc.section.3.1.1.5">3.1.1.5</a> <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. 957 957 </p> 958 958 <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> … … 1013 1013 </p> 1014 1014 <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 aContent-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content1015 not be restated in Content-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content 1016 1016 coding would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, 1017 1017 an origin server might choose to publish the same payload data as multiple representations that differ only in whether the … … 1019 1019 as ..." dialog instead of automatic decompression and rendering of content). 1020 1020 </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. 1022 1022 </p> 1023 1023 <h3 id="rfc.section.3.1.3"><a href="#rfc.section.3.1.3">3.1.3</a> <a id="audience.language" href="#audience.language">Audience Language</a></h3> … … 1180 1180 <tr> 1181 1181 <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> 1183 1183 </tr> 1184 1184 <tr> … … 1190 1190 </div> 1191 1191 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <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". 1214 1207 </p> 1215 1208 <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a> <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 proactive1217 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 information1219 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 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. 1220 1213 </p> 1221 1214 <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 response1215 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 1223 1216 (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> 1228 1221 <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require 1229 1222 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?); 1231 1224 </li> 1232 1225 <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 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 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 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 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 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 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 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. 1251 1238 </p> 1252 1239 <h3 id="rfc.section.3.4.2"><a href="#rfc.section.3.4.2">3.4.2</a> <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 1260 1250 encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally 1261 1251 when public caches are used to distribute server load and reduce network usage. 1262 1252 </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. 1270 1257 </p> 1271 1258 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h1> … … 1424 1411 to be refreshed without requiring multiple requests or transferring data already held by the client. 1425 1412 </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 representations1413 <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 1427 1414 to be completed without transferring data already held by the client. 1428 1415 </p> … … 1523 1510 the related resources. 1524 1511 </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 full1512 <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 1526 1513 representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps 1527 1514 a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for … … 1650 1637 <tr> 1651 1638 <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> 1653 1640 </tr> 1654 1641 </tbody> … … 1772 1759 <tr> 1773 1760 <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> 1775 1762 </tr> 1776 1763 </tbody> … … 1789 1776 <tr> 1790 1777 <td class="left">Accept</td> 1791 <td class="left"><a href="#header.accept" id="rfc.xref.header.accept. 3" title="Accept">Section 6.3.2</a></td>1778 <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.3.2</a></td> 1792 1779 </tr> 1793 1780 <tr> 1794 1781 <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 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 6.3.3</a></td> 1796 1783 </tr> 1797 1784 <tr> 1798 1785 <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 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 6.3.4</a></td> 1800 1787 </tr> 1801 1788 <tr> 1802 1789 <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 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 6.3.5</a></td> 1804 1791 </tr> 1805 1792 </tbody> … … 2057 2044 <tr> 2058 2045 <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 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 6.5.3</a></td> 2060 2047 </tr> 2061 2048 </tbody> … … 2147 2134 </p> 2148 2135 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <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 the2136 <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 2150 2137 protocol. 2151 2138 </p> … … 2203 2190 <td class="left">206</td> 2204 2191 <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> 2206 2193 </tr> 2207 2194 <tr> … … 2323 2310 <td class="left">416</td> 2324 2311 <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> 2326 2313 </tr> 2327 2314 <tr> … … 2699 2686 <h3 id="rfc.section.7.5.13"><a href="#rfc.section.7.5.13">7.5.13</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> 2700 2687 <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. 2702 2689 </p> 2703 2690 <div id="rfc.iref.74"></div> … … 3055 3042 <tr> 3056 3043 <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.1 0"><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> 3058 3045 </tr> 3059 3046 <tr> … … 3543 3530 <td class="left">http</td> 3544 3531 <td class="left">standard</td> 3545 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept. 4" title="Accept">Section 6.3.2</a>3532 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 6.3.2</a> 3546 3533 </td> 3547 3534 </tr> … … 3550 3537 <td class="left">http</td> 3551 3538 <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 6.3.3</a>3539 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 6.3.3</a> 3553 3540 </td> 3554 3541 </tr> … … 3557 3544 <td class="left">http</td> 3558 3545 <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 6.3.4</a>3546 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 6.3.4</a> 3560 3547 </td> 3561 3548 </tr> … … 3564 3551 <td class="left">http</td> 3565 3552 <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 6.3.5</a>3553 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section 6.3.5</a> 3567 3554 </td> 3568 3555 </tr> … … 3669 3656 <td class="left">http</td> 3670 3657 <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 6.5.3</a>3658 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 6.5.3</a> 3672 3659 </td> 3673 3660 </tr> … … 3734 3721 <td class="left">reserved (synonym for "no encoding" in <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> header field) 3735 3722 </td> 3736 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding. 5" title="Accept-Encoding">Section 6.3.4</a>3723 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Section 6.3.4</a> 3737 3724 </td> 3738 3725 </tr> … … 3766 3753 of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information. 3767 3754 </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 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 8.4.2</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might3755 <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 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 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 3769 3756 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 3770 3757 no better mechanism. … … 4046 4033 </p> 4047 4034 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <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 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 line4035 <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 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 4049 4036 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted 4050 4037 over HTTP. … … 4121 4108 semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 6.1.2</a>) 4122 4109 </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 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 6.3.3</a>) 4124 4111 </p> 4125 4112 <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 8.1.1.2</a>) … … 4411 4398 </li> 4412 4399 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 4413 <li>Accept header field <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 <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 <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 <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 <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 <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 <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 <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> 4417 4404 <li>Allow header field <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> 4418 4405 </ul> … … 4588 4575 </ul> 4589 4576 </li> 4590 <li><em>Part5</em> <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> <a href="#rfc.xref.Part5. 7">7.1</a></li>4592 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5. 8">7.1</a></li>4593 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5. 9">7.1</a></li>4594 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.1 0">8.4</a></li>4595 <li><em>Section 5.2</em> <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> <a href="#rfc.xref.Part5. 6">6.2</a></li>4597 <li><em>Section 5.4</em> <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> <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> <a href="#rfc.xref.Part5.8">7.1</a></li> 4579 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.9">7.1</a></li> 4580 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.10">7.1</a></li> 4581 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.11">8.4</a></li> 4582 <li><em>Section 5.2</em> <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> <a href="#rfc.xref.Part5.7">6.2</a></li> 4584 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.4">5.3.1</a>, <a href="#rfc.xref.Part5.6">6.1</a></li> 4598 4585 </ul> 4599 4586 </li> … … 4646 4633 </ul> 4647 4634 </li> 4648 <li><em>RFC2049</em> <a href="# RFC2049"><b>12.2</b></a>, <a href="#rfc.xref.RFC2049.1">A.2</a><ul>4649 <li><em>Section 4</em> <a href="#rfc.xref.RFC2049. 1">A.2</a></li>4635 <li><em>RFC2049</em> <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> <a href="#rfc.xref.RFC2049.2">A.2</a></li> 4650 4637 </ul> 4651 4638 </li> … … 4731 4718 </li> 4732 4719 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 4733 <li>User-Agent header field <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 <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> 4734 4721 </ul> 4735 4722 </li>
Note: See TracChangeset
for help on using the changeset viewer.