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