Changeset 1907
- Timestamp:
- 18/09/12 23:52:32 (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1905 r1907 585 585 <li><a href="#rfc.section.2">2.</a> <a href="#resource">Resource</a></li> 586 586 <li><a href="#rfc.section.3">3.</a> <a href="#representation">Representation</a><ul> 587 <li><a href="#rfc.section.3.1">3.1</a> <a href="#payload">Message Payload</a></li> 588 <li><a href="#rfc.section.3.2">3.2</a> <a href="#associating.representation.with.resource">Associating a Representation with its Resource</a></li> 589 <li><a href="#rfc.section.3.3">3.3</a> <a href="#representation.header.fields">Representation Header Fields</a><ul> 590 <li><a href="#rfc.section.3.3.1">3.3.1</a> <a href="#header.content-type">Content-Type</a></li> 591 <li><a href="#rfc.section.3.3.2">3.3.2</a> <a href="#header.content-encoding">Content-Encoding</a></li> 592 <li><a href="#rfc.section.3.3.3">3.3.3</a> <a href="#header.content-language">Content-Language</a></li> 593 <li><a href="#rfc.section.3.3.4">3.3.4</a> <a href="#header.content-location">Content-Location</a></li> 587 <li><a href="#rfc.section.3.1">3.1</a> <a href="#payload">Message Payload</a><ul> 588 <li><a href="#rfc.section.3.1.1">3.1.1</a> <a href="#payload.header.fields">Payload Header Fields</a></li> 589 <li><a href="#rfc.section.3.1.2">3.1.2</a> <a href="#identifying.payload">Identifying the Payload</a></li> 594 590 </ul> 595 591 </li> 596 <li><a href="#rfc.section.3.4">3.4</a> <a href="#selected.representation">Selected Representation Header Fields</a></li> 597 <li><a href="#rfc.section.3.5">3.5</a> <a href="#representation.data">Representation Data</a></li> 598 <li><a href="#rfc.section.3.6">3.6</a> <a href="#content.negotiation">Content Negotiation</a><ul> 599 <li><a href="#rfc.section.3.6.1">3.6.1</a> <a href="#proactive.negotiation">Proactive Negotiation</a></li> 600 <li><a href="#rfc.section.3.6.2">3.6.2</a> <a href="#reactive.negotiation">Reactive Negotiation</a></li> 592 <li><a href="#rfc.section.3.2">3.2</a> <a href="#representation.header.fields">Representation Header Fields</a><ul> 593 <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#header.content-type">Content-Type</a></li> 594 <li><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#header.content-encoding">Content-Encoding</a></li> 595 <li><a href="#rfc.section.3.2.3">3.2.3</a> <a href="#header.content-language">Content-Language</a></li> 596 <li><a href="#rfc.section.3.2.4">3.2.4</a> <a href="#header.content-location">Content-Location</a></li> 597 </ul> 598 </li> 599 <li><a href="#rfc.section.3.3">3.3</a> <a href="#selected.representation">Selected Representation Header Fields</a></li> 600 <li><a href="#rfc.section.3.4">3.4</a> <a href="#representation.data">Representation Data</a></li> 601 <li><a href="#rfc.section.3.5">3.5</a> <a href="#content.negotiation">Content Negotiation</a><ul> 602 <li><a href="#rfc.section.3.5.1">3.5.1</a> <a href="#proactive.negotiation">Proactive Negotiation</a></li> 603 <li><a href="#rfc.section.3.5.2">3.5.2</a> <a href="#reactive.negotiation">Reactive Negotiation</a></li> 601 604 </ul> 602 605 </li> … … 897 900 the error and what next steps are suggested for resolving it. 898 901 </p> 899 <p id="rfc.section.3.1.p.5">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload 902 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3> 903 <p id="rfc.section.3.1.1.p.1">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload 900 904 header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing. 901 905 </p> … … 924 928 </table> 925 929 </div> 926 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="associating.representation.with.resource" href="#associating.representation.with.resource">Associating a Representation with its Resource</a></h2> 927 <p id="rfc.section.3.2.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 928 <p id="rfc.section.3.2.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 929 <p id="rfc.section.3.2.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 930 rules are used (with the first applicable one being selected): 930 <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="identifying.payload" href="#identifying.payload">Identifying the Payload</a></h3> 931 <p id="rfc.section.3.1.2.p.1">When a complete or partial representation is transferred in a message payload, it is often desirable for the sender to supply, 932 or the recipient to determine, an identifier for the resource corresponding to that representation. 933 </p> 934 <p id="rfc.section.3.1.2.p.2">The following rules are used to determine such a URI for the payload of a request message: </p> 935 <ul> 936 <li>If the request has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location 937 field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP). 938 The information might still be useful for revision history links. 939 </li> 940 <li>Otherwise, the payload is unidentified.</li> 941 </ul> 942 <p id="rfc.section.3.1.2.p.3">The following rules, to be applied in order until a match is found, are used to determine such a URI for the payload of a 943 response message: 931 944 </p> 932 945 <ol> 933 <li>If the re sponse status code is <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.203" class="smpl">203934 (Non-Authoritative Information)</a> and the request method was GET, the response payload is a representation of the target resource.935 < /li>936 <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.937 </li> 938 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field , and that URI is the same as the effective request URI, the response payload is a representation of the target939 resource.940 </li> 941 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field , and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation942 of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified943 by other means (not defined by HTTP).944 </li> 945 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>946 <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload's identifier is the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 947 </li> 948 <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified representation of the target resource; as such, the effective request URI might only 949 act as an identifier for the payload's representation when a request is made via the same chain of intermediaries. 950 </li> 951 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload's identifier is 952 the effective request URI. 953 </li> 954 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts 955 that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion 956 cannot be trusted unless it can be verified by other means (not defined by HTTP). 957 </li> 958 <li>Otherwise, the payload is unidentified.</li> 946 959 </ol> 947 <p id="rfc.section.3.2.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like 948 cache invalidation.]</span> 949 </p> 950 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2> 951 <p id="rfc.section.3.3.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message 960 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2> 961 <p id="rfc.section.3.2.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message 952 962 body is present, about the representation that would have been transferred in a <a href="#status.200" class="smpl">200 (OK)</a> response to a simultaneous GET request with the same effective request URI. 953 963 </p> 954 <p id="rfc.section.3. 3.p.2">The following header fields are defined as representation metadata:</p>964 <p id="rfc.section.3.2.p.2">The following header fields are defined as representation metadata:</p> 955 965 <div id="rfc.table.u.2"> 956 966 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 964 974 <tr> 965 975 <td class="left">Content-Type</td> 966 <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 3. 3.1</a></td>976 <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 3.2.1</a></td> 967 977 </tr> 968 978 <tr> 969 979 <td class="left">Content-Encoding</td> 970 <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 3. 3.2</a></td>980 <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 3.2.2</a></td> 971 981 </tr> 972 982 <tr> 973 983 <td class="left">Content-Language</td> 974 <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 3. 3.3</a></td>984 <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 3.2.3</a></td> 975 985 </tr> 976 986 <tr> 977 987 <td class="left">Content-Location</td> 978 <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 3. 3.4</a></td>988 <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 3.2.4</a></td> 979 989 </tr> 980 990 <tr> … … 986 996 </div> 987 997 <div id="rfc.iref.c.2"></div> 988 <h3 id="rfc.section.3. 3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h3>989 <p id="rfc.section.3. 3.1.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,998 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h3> 999 <p id="rfc.section.3.2.1.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method, 990 1000 the media type is that which would have been sent had the request been a GET. 991 1001 </p> 992 1002 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a> 993 </pre><p id="rfc.section.3. 3.1.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 8.5</a>. An example of the field is1003 </pre><p id="rfc.section.3.2.1.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 8.5</a>. An example of the field is 994 1004 </p> 995 1005 <div id="rfc.figure.u.2"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 996 </pre><p id="rfc.section.3. 3.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section 3.5</a>.1006 </pre><p id="rfc.section.3.2.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section 3.4</a>. 997 1007 </p> 998 1008 <div id="rfc.iref.c.3"></div> 999 <h3 id="rfc.section.3. 3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3>1000 <p id="rfc.section.3. 3.2.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent1009 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3> 1010 <p id="rfc.section.3.2.2.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent 1001 1011 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of 1002 1012 its underlying media type. 1003 1013 </p> 1004 1014 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.2"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 1005 </pre><p id="rfc.section.3. 3.2.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 8.4</a>. An example of its use is1015 </pre><p id="rfc.section.3.2.2.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 8.4</a>. An example of its use is 1006 1016 </p> 1007 1017 <div id="rfc.figure.u.4"></div><pre class="text"> Content-Encoding: gzip 1008 </pre><p id="rfc.section.3. 3.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding1018 </pre><p id="rfc.section.3.2.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding 1009 1019 and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control 1010 1020 directive is present in the message. 1011 1021 </p> 1012 <p id="rfc.section.3. 3.2.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would1022 <p id="rfc.section.3.2.2.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would 1013 1023 not be restated as a Content-Encoding even if it happens to be the same algorithm as one of the content-codings. Such a content-coding 1014 1024 would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin … … 1017 1027 as ..." dialog instead of automatic decompression and rendering of content). 1018 1028 </p> 1019 <p id="rfc.section.3. 3.2.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field that lists the content-coding(s) applied.1020 </p> 1021 <p id="rfc.section.3. 3.2.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1022 </p> 1023 <p id="rfc.section.3. 3.2.p.9">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).1029 <p id="rfc.section.3.2.2.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field that lists the content-coding(s) applied. 1030 </p> 1031 <p id="rfc.section.3.2.2.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1032 </p> 1033 <p id="rfc.section.3.2.2.p.9">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). 1024 1034 </p> 1025 1035 <div id="rfc.iref.c.4"></div> 1026 <h3 id="rfc.section.3. 3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h3>1027 <p id="rfc.section.3. 3.3.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note1036 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h3> 1037 <p id="rfc.section.3.2.3.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note 1028 1038 that this might not be equivalent to all the languages used within the representation. 1029 1039 </p> 1030 1040 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.3"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 1031 </pre><p id="rfc.section.3. 3.3.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 8.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the1041 </pre><p id="rfc.section.3.2.3.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 8.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the 1032 1042 user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate 1033 1043 field is 1034 1044 </p> 1035 1045 <div id="rfc.figure.u.6"></div><pre class="text"> Content-Language: da 1036 </pre><p id="rfc.section.3. 3.3.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean1046 </pre><p id="rfc.section.3.2.3.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 1037 1047 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language 1038 1048 it is intended. 1039 1049 </p> 1040 <p id="rfc.section.3. 3.3.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented1050 <p id="rfc.section.3.2.3.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented 1041 1051 simultaneously in the original Maori and English versions, would call for 1042 1052 </p> 1043 1053 <div id="rfc.figure.u.7"></div><pre class="text"> Content-Language: mi, en 1044 </pre><p id="rfc.section.3. 3.3.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple1054 </pre><p id="rfc.section.3.2.3.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 1045 1055 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly 1046 1056 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 1047 1057 </p> 1048 <p id="rfc.section.3. 3.3.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.1058 <p id="rfc.section.3.2.3.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents. 1049 1059 </p> 1050 1060 <div id="rfc.iref.c.5"></div> 1051 <h3 id="rfc.section.3. 3.4"><a href="#rfc.section.3.3.4">3.3.4</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h3>1052 <p id="rfc.section.3. 3.4.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this1061 <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h3> 1062 <p id="rfc.section.3.2.4.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this 1053 1063 message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message. 1054 1064 </p> 1055 1065 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.4"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a> 1056 </pre><p id="rfc.section.3. 3.4.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME1066 </pre><p id="rfc.section.3.2.4.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 1057 1067 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 1058 1068 </p> 1059 <p id="rfc.section.3. 3.4.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response1069 <p id="rfc.section.3.2.4.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response 1060 1070 payload <em class="bcp14">SHOULD</em> be considered a current representation of that resource. For a GET or HEAD request, this is the same as the default semantics 1061 1071 when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's … … 1064 1074 need for a subsequent GET request. 1065 1075 </p> 1066 <p id="rfc.section.3. 3.4.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin1076 <p id="rfc.section.3.2.4.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin 1067 1077 server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD 1068 1078 request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation … … 1072 1082 the payload of the <a href="#status.200" class="smpl">200 (OK)</a> response; the Content-Location value provides an identifier for retrieving a copy of that same receipt in the future. 1073 1083 </p> 1074 <p id="rfc.section.3. 3.4.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed1084 <p id="rfc.section.3.2.4.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed 1075 1085 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is 1076 1086 providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated … … 1080 1090 latter semantics, it would have applied the PUT directly to the Content-Location URI. 1081 1091 </p> 1082 <p id="rfc.section.3. 3.4.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use1092 <p id="rfc.section.3.2.4.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use 1083 1093 in other contexts, such as within source links or other metadata. 1084 1094 </p> 1085 <p id="rfc.section.3. 3.4.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used1095 <p id="rfc.section.3.2.4.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used 1086 1096 to respond to later requests on that Content-Location URI. 1087 1097 </p> 1088 <p id="rfc.section.3. 3.4.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>1089 <h2 id="rfc.section.3. 4"><a href="#rfc.section.3.4">3.4</a> <a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>1090 <p id="rfc.section.3. 4.p.1"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of a target resource that would have been selected in a successful response if1098 <p id="rfc.section.3.2.4.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p> 1099 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2> 1100 <p id="rfc.section.3.3.p.1"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of a target resource that would have been selected in a successful response if 1091 1101 the same request had used the method GET and excluded any conditional request header fields. 1092 1102 </p> 1093 <p id="rfc.section.3. 4.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included1103 <p id="rfc.section.3.3.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included 1094 1104 in the message for responses to some state-changing methods. The following header fields are defined as selected representation 1095 1105 metadata: … … 1115 1125 </table> 1116 1126 </div> 1117 <h2 id="rfc.section.3. 5"><a href="#rfc.section.3.5">3.5</a> <a id="representation.data" href="#representation.data">Representation Data</a></h2>1118 <p id="rfc.section.3. 5.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred1127 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="representation.data" href="#representation.data">Representation Data</a></h2> 1128 <p id="rfc.section.3.4.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred 1119 1129 to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by 1120 1130 the representation metadata header fields. 1121 1131 </p> 1122 <p id="rfc.section.3. 5.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model:1132 <p id="rfc.section.3.4.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model: 1123 1133 </p> 1124 1134 <div id="rfc.figure.u.9"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) ) 1125 </pre><p id="rfc.section.3. 5.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload1135 </pre><p id="rfc.section.3.4.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload 1126 1136 body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown 1127 1137 to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type 1128 1138 of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type. 1129 1139 </p> 1130 <p id="rfc.section.3. 5.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for1140 <p id="rfc.section.3.4.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for 1131 1141 a given representation, with the result that some clients will examine a response body's content and override the specified 1132 1142 type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege … … 1135 1145 such "content sniffing" when it is used. 1136 1146 </p> 1137 <p id="rfc.section.3. 5.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that1147 <p id="rfc.section.3.4.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that 1138 1148 are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that 1139 1149 defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. 1140 1150 </p> 1141 <h2 id="rfc.section.3. 6"><a href="#rfc.section.3.6">3.6</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>1142 <p id="rfc.section.3. 6.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further1151 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2> 1152 <p id="rfc.section.3.5.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further 1143 1153 processing. Often, the server has different ways of representing the same information; for example, in different formats, 1144 1154 languages, or using different character encodings. 1145 1155 </p> 1146 <p id="rfc.section.3. 6.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence1156 <p id="rfc.section.3.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence 1147 1157 which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP 1148 1158 provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when 1149 1159 more than one is available. 1150 1160 </p> 1151 <p id="rfc.section.3. 6.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based1161 <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based 1152 1162 upon the client's stated preferences, and "reactive" negotiation, where the server provides a list of representations for 1153 1163 the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an "active … … 1155 1165 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. 1156 1166 </p> 1157 <p id="rfc.section.3. 6.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number1167 <p id="rfc.section.3.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number 1158 1168 of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by 1159 1169 a user-agent), proactive negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations 1160 1170 to choose from is very large, reactive negotiation might not be appropriate. 1161 1171 </p> 1162 <p id="rfc.section.3. 6.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might1172 <p id="rfc.section.3.5.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might 1163 1173 be considered to be the "same information". 1164 1174 </p> 1165 <h3 id="rfc.section.3. 6.1"><a href="#rfc.section.3.6.1">3.6.1</a> <a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>1166 <p id="rfc.section.3. 6.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 proactive1175 <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a> <a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3> 1176 <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive 1167 1177 negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g., 1168 1178 language, content-coding, etc.) and the contents of particular header fields in the request message or on other information 1169 1179 pertaining to the request (such as the network address of the client). 1170 1180 </p> 1171 <p id="rfc.section.3. 6.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult1181 <p id="rfc.section.3.5.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult 1172 1182 to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response 1173 1183 (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to 1174 1184 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. 1175 1185 </p> 1176 <p id="rfc.section.3. 6.1.p.3">Proactive negotiation has disadvantages: </p>1186 <p id="rfc.section.3.5.1.p.3">Proactive negotiation has disadvantages: </p> 1177 1187 <ol> 1178 1188 <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require … … 1186 1196 <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li> 1187 1197 </ol> 1188 <p id="rfc.section.3. 6.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.1198 <p id="rfc.section.3.5.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them. 1189 1199 For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that 1190 1200 doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406 1191 1201 (Not Acceptable)</a> response. 1192 1202 </p> 1193 <p id="rfc.section.3. 6.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities1203 <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities 1194 1204 and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 5.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 5.3.3</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section 5.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 5.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 5.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 1195 1205 within extension header fields not defined by this specification. 1196 1206 </p> 1197 <div class="note" id="rfc.section.3. 6.1.p.6">1207 <div class="note" id="rfc.section.3.5.1.p.6"> 1198 1208 <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. 1199 1209 </p> 1200 1210 </div> 1201 <p id="rfc.section.3. 6.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 7.2.2</a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation.1202 </p> 1203 <h3 id="rfc.section.3. 6.2"><a href="#rfc.section.3.6.2">3.6.2</a> <a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>1204 <p id="rfc.section.3. 6.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving1211 <p id="rfc.section.3.5.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 7.2.2</a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation. 1212 </p> 1213 <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a> <a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3> 1214 <p id="rfc.section.3.5.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving 1205 1215 an initial response from the origin server. Selection is based on a list of the available representations of the response 1206 1216 included within the header fields or body of the initial response, with each representation identified by its own URI. Selection … … 1208 1218 user selecting from a generated (possibly hypertext) menu. 1209 1219 </p> 1210 <p id="rfc.section.3. 6.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or1220 <p id="rfc.section.3.5.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or 1211 1221 encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally 1212 1222 when public caches are used to distribute server load and reduce network usage. 1213 1223 </p> 1214 <p id="rfc.section.3. 6.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.1224 <p id="rfc.section.3.5.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation. 1215 1225 This second request is only efficient when caching is used. In addition, this specification does not define any mechanism 1216 1226 for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension 1217 1227 and used within HTTP/1.1. 1218 1228 </p> 1219 <p id="rfc.section.3. 6.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 using1229 <p id="rfc.section.3.5.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 1220 1230 proactive negotiation. 1221 1231 </p> … … 1403 1413 <p id="rfc.section.4.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.1.1</a>). 1404 1414 </p> 1405 <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 3. 3.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1415 <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 3.2.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1406 1416 </p> 1407 1417 <p id="rfc.section.4.3.3.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource. … … 2080 2090 </li> 2081 2091 </ul> 2082 <p id="rfc.section.6.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 3. 3.1</a>).2092 <p id="rfc.section.6.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 3.2.1</a>). 2083 2093 </p> 2084 2094 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> … … 2434 2444 </li> 2435 2445 <li> 2436 <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section 3. 6.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.2446 <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section 3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>. 2437 2447 </p> 2438 2448 </li> … … 2463 2473 <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> 2464 2474 <p id="rfc.section.6.4.1.p.1">The target resource has more than one representation, each with its own specific location, and reactive negotiation information 2465 (<a href="#content.negotiation" title="Content Negotiation">Section 3. 6</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that2475 (<a href="#content.negotiation" title="Content Negotiation">Section 3.5</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that 2466 2476 location. 2467 2477 </p> … … 2761 2771 </p> 2762 2772 <div class="note" id="rfc.section.7.1.1.p.9"> 2763 <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 3. 3.4</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.2773 <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 3.2.4</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 2764 2774 It is therefore possible for a response to contain header fields for both Location and Content-Location. 2765 2775 </p> … … 3057 3067 </p> 3058 3068 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#imported.abnf" class="smpl">token</a> 3059 </pre><p id="rfc.section.8.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 5.3.4</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 3. 3.2</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding3069 </pre><p id="rfc.section.8.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 5.3.4</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 3.2.2</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 3060 3070 mechanism will be required to remove the encoding. 3061 3071 </p> … … 3079 3089 </ul> 3080 3090 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="media.types" href="#media.types">Media Types</a></h2> 3081 <p id="rfc.section.8.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 3. 3.1</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation.3091 <p id="rfc.section.8.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 3.2.1</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation. 3082 3092 </p> 3083 3093 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span> <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) … … 3257 3267 </p> 3258 3268 <h3 id="rfc.section.9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a> <a id="considerations.for.new.status.codes" href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></h3> 3259 <p id="rfc.section.9.2.2.p.1">When it is necessary to express new semantics for a HTTP response that aren't specific to a single application or media type, 3260 and currently defined status codes are inadequate, a new status code can be registered. 3261 </p> 3262 <p id="rfc.section.9.2.2.p.2">HTTP status codes are generic; that is, they are potentially applicable to any resource, not just one particular media type, 3263 "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't 3264 specific to a single application, so that this is clear. 3265 </p> 3266 <p id="rfc.section.9.2.2.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status 3267 code (e.g., combinations of request header fields and/or method(s)), along with any interactions with response header fields 3268 (e.g., those that are required, those that modify the semantics of the response). 3269 </p> 3270 <p id="rfc.section.9.2.2.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section 6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate 3271 a zero-length response body. They can require the presence of one or more particular HTTP response header field(s). 3272 </p> 3273 <p id="rfc.section.9.2.2.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#associating.representation.with.resource" title="Associating a Representation with its Resource">Section 3.2</a>; by default, it is anonymous). 3269 <p id="rfc.section.9.2.2.p.1">When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can 3270 be registered. HTTP status codes are generic; they are potentially applicable to any resource, not just one particular media 3271 type, "type" of resource, or application. As such, it is preferred that new status codes be registered in a document that 3272 isn't specific to a single application. 3273 </p> 3274 <p id="rfc.section.9.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section 6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate 3275 a zero-length response body. 3276 </p> 3277 <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that produce a response containing that status 3278 code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields 3279 (e.g., what fields are required and what fields can modify the semantics). A response that can transfer a payload ought to 3280 specify expected cache behavior (e.g., cacheability and freshness criteria, as described in <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying the Payload">Section 3.1.2</a>). 3274 3281 </p> 3275 3282 <h3 id="rfc.section.9.2.3"><a href="#rfc.section.9.2.3">9.2.3</a> <a id="status.code.registration" href="#status.code.registration">Registrations</a></h3> … … 3531 3538 double-quotes will likely cause unnecessary confusion. 3532 3539 </p> 3533 <p id="rfc.section.9.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section 3. 3.1</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing3540 <p id="rfc.section.9.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section 3.2.1</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 3534 3541 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 3535 3542 it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section 8.5</a>). … … 3625 3632 <td class="left">http</td> 3626 3633 <td class="left">standard</td> 3627 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 3. 3.2</a>3634 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 3.2.2</a> 3628 3635 </td> 3629 3636 </tr> … … 3632 3639 <td class="left">http</td> 3633 3640 <td class="left">standard</td> 3634 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section 3. 3.3</a>3641 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section 3.2.3</a> 3635 3642 </td> 3636 3643 </tr> … … 3639 3646 <td class="left">http</td> 3640 3647 <td class="left">standard</td> 3641 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section 3. 3.4</a>3648 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section 3.2.4</a> 3642 3649 </td> 3643 3650 </tr> … … 3646 3653 <td class="left">http</td> 3647 3654 <td class="left">standard</td> 3648 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section 3. 3.1</a>3655 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section 3.2.1</a> 3649 3656 </td> 3650 3657 </tr> … … 4139 4146 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 4140 4147 <p id="rfc.section.C.p.1">Remove base URI setting semantics for "<a href="#header.content-location" class="smpl">Content-Location</a>" due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields, 4141 and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3. 3.4</a>)4148 and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3.2.4</a>) 4142 4149 </p> 4143 4150 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 4.3.3</a>) … … 5000 5007 </li> 5001 5008 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 5002 <li>Accept header field <a href="#rfc.xref.header.accept.1">3. 6.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.5</a>, <a href="#rfc.xref.header.accept.4">9.3.2</a></li>5003 <li>Accept-Charset header field <a href="#rfc.xref.header.accept-charset.1">3. 6.1</a>, <a href="#rfc.xref.header.accept-charset.2">5.3</a>, <a href="#rfc.iref.a.2"><b>5.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>5004 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">3. 6.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.4</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>5005 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">3. 6.1</a>, <a href="#rfc.xref.header.accept-language.2">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li>5009 <li>Accept header field <a href="#rfc.xref.header.accept.1">3.5.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.5</a>, <a href="#rfc.xref.header.accept.4">9.3.2</a></li> 5010 <li>Accept-Charset header field <a href="#rfc.xref.header.accept-charset.1">3.5.1</a>, <a href="#rfc.xref.header.accept-charset.2">5.3</a>, <a href="#rfc.iref.a.2"><b>5.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> 5011 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">3.5.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.4</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> 5012 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">3.5.1</a>, <a href="#rfc.xref.header.accept-language.2">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li> 5006 5013 <li>Allow header field <a href="#rfc.xref.header.allow.1">4.1</a>, <a href="#rfc.xref.header.allow.2">7.4</a>, <a href="#rfc.iref.a.5"><b>7.4.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3.2</a>, <a href="#rfc.xref.header.allow.4">C</a></li> 5007 5014 </ul> … … 5012 5019 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.7"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">9.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a></li> 5013 5020 <li>content negotiation <a href="#rfc.iref.c.1">1</a></li> 5014 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">3. 3</a>, <a href="#rfc.iref.c.3"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-encoding.2">8.4</a>, <a href="#rfc.xref.header.content-encoding.3">9.3.2</a></li>5015 <li>Content-Language header field <a href="#rfc.xref.header.content-language.1">3. 3</a>, <a href="#rfc.iref.c.4"><b>3.3.3</b></a>, <a href="#rfc.xref.header.content-language.2">9.3.2</a></li>5016 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">3. 3</a>, <a href="#rfc.iref.c.5"><b>3.3.4</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.1</a>, <a href="#rfc.xref.header.content-location.4">9.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>5021 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">3.2</a>, <a href="#rfc.iref.c.3"><b>3.2.2</b></a>, <a href="#rfc.xref.header.content-encoding.2">8.4</a>, <a href="#rfc.xref.header.content-encoding.3">9.3.2</a></li> 5022 <li>Content-Language header field <a href="#rfc.xref.header.content-language.1">3.2</a>, <a href="#rfc.iref.c.4"><b>3.2.3</b></a>, <a href="#rfc.xref.header.content-language.2">9.3.2</a></li> 5023 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">3.2</a>, <a href="#rfc.iref.c.5"><b>3.2.4</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.1</a>, <a href="#rfc.xref.header.content-location.4">9.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li> 5017 5024 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.9">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 5018 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3. 3</a>, <a href="#rfc.iref.c.2"><b>3.3.1</b></a>, <a href="#rfc.xref.header.content-type.2">6</a>, <a href="#rfc.xref.header.content-type.3">8.5</a>, <a href="#rfc.xref.header.content-type.4">9.3.1</a>, <a href="#rfc.xref.header.content-type.5">9.3.2</a></li>5025 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3.2</a>, <a href="#rfc.iref.c.2"><b>3.2.1</b></a>, <a href="#rfc.xref.header.content-type.2">6</a>, <a href="#rfc.xref.header.content-type.3">8.5</a>, <a href="#rfc.xref.header.content-type.4">9.3.1</a>, <a href="#rfc.xref.header.content-type.5">9.3.2</a></li> 5019 5026 </ul> 5020 5027 </li> … … 5054 5061 <li><tt>codings</tt> <a href="#rfc.iref.g.21"><b>5.3.4</b></a></li> 5055 5062 <li><tt>content-coding</tt> <a href="#rfc.iref.g.53"><b>8.4</b></a></li> 5056 <li><tt>Content-Encoding</tt> <a href="#rfc.iref.g.2"><b>3. 3.2</b></a></li>5057 <li><tt>Content-Language</tt> <a href="#rfc.iref.g.3"><b>3. 3.3</b></a></li>5058 <li><tt>Content-Location</tt> <a href="#rfc.iref.g.4"><b>3. 3.4</b></a></li>5059 <li><tt>Content-Type</tt> <a href="#rfc.iref.g.1"><b>3. 3.1</b></a></li>5063 <li><tt>Content-Encoding</tt> <a href="#rfc.iref.g.2"><b>3.2.2</b></a></li> 5064 <li><tt>Content-Language</tt> <a href="#rfc.iref.g.3"><b>3.2.3</b></a></li> 5065 <li><tt>Content-Location</tt> <a href="#rfc.iref.g.4"><b>3.2.4</b></a></li> 5066 <li><tt>Content-Type</tt> <a href="#rfc.iref.g.1"><b>3.2.1</b></a></li> 5060 5067 <li><tt>Date</tt> <a href="#rfc.iref.g.30"><b>7.2.1</b></a></li> 5061 5068 <li><tt>date1</tt> <a href="#rfc.iref.g.36"><b>8.1</b></a></li> … … 5129 5136 </li> 5130 5137 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 5131 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1 </a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2</a>, <a href="#rfc.xref.Part1.10">3.3.4</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a>, <a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.14">4.3.8</a>, <a href="#rfc.xref.Part1.15">5.1</a>, <a href="#rfc.xref.Part1.16">5.5</a>, <a href="#rfc.xref.Part1.17">5.5.3</a>, <a href="#rfc.xref.Part1.18">6.2.2</a>, <a href="#rfc.xref.Part1.19">6.3.4</a>, <a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.21">6.5.15</a>, <a href="#rfc.xref.Part1.22">6.6.6</a>, <a href="#rfc.xref.Part1.23">7</a>, <a href="#rfc.xref.Part1.24">7.4.2</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.26">8.4</a>, <a href="#rfc.xref.Part1.27">8.4</a>, <a href="#rfc.xref.Part1.28">8.4</a>, <a href="#rfc.xref.Part1.29">9.1.2</a>, <a href="#rfc.xref.Part1.30">9.3.1</a>, <a href="#rfc.xref.Part1.31">9.3.1</a>, <a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.34">9.3.1</a>, <a href="#rfc.xref.Part1.35">9.3.1</a>, <a href="#rfc.xref.Part1.36">9.4</a>, <a href="#rfc.xref.Part1.37">9.4.1</a>, <a href="#rfc.xref.Part1.38">9.4.1</a>, <a href="#rfc.xref.Part1.39">9.4.2</a>, <a href="#rfc.xref.Part1.40">9.4.2</a>, <a href="#rfc.xref.Part1.41">9.4.2</a>, <a href="#rfc.xref.Part1.42">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.43">C</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a><ul>5138 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.1</a>, <a href="#rfc.xref.Part1.8">3.1.1</a>, <a href="#rfc.xref.Part1.9">3.1.2</a>, <a href="#rfc.xref.Part1.10">3.2.4</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a>, <a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.14">4.3.8</a>, <a href="#rfc.xref.Part1.15">5.1</a>, <a href="#rfc.xref.Part1.16">5.5</a>, <a href="#rfc.xref.Part1.17">5.5.3</a>, <a href="#rfc.xref.Part1.18">6.2.2</a>, <a href="#rfc.xref.Part1.19">6.3.4</a>, <a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.21">6.5.15</a>, <a href="#rfc.xref.Part1.22">6.6.6</a>, <a href="#rfc.xref.Part1.23">7</a>, <a href="#rfc.xref.Part1.24">7.4.2</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.26">8.4</a>, <a href="#rfc.xref.Part1.27">8.4</a>, <a href="#rfc.xref.Part1.28">8.4</a>, <a href="#rfc.xref.Part1.29">9.1.2</a>, <a href="#rfc.xref.Part1.30">9.3.1</a>, <a href="#rfc.xref.Part1.31">9.3.1</a>, <a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.34">9.3.1</a>, <a href="#rfc.xref.Part1.35">9.3.1</a>, <a href="#rfc.xref.Part1.36">9.4</a>, <a href="#rfc.xref.Part1.37">9.4.1</a>, <a href="#rfc.xref.Part1.38">9.4.1</a>, <a href="#rfc.xref.Part1.39">9.4.2</a>, <a href="#rfc.xref.Part1.40">9.4.2</a>, <a href="#rfc.xref.Part1.41">9.4.2</a>, <a href="#rfc.xref.Part1.42">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.43">C</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a><ul> 5132 5139 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 5133 5140 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.19">6.3.4</a></li> … … 5138 5145 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a></li> 5139 5146 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a></li> 5140 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.8">3.1 </a></li>5147 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.8">3.1.1</a></li> 5141 5148 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.29">9.1.2</a></li> 5142 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.7">3.1 </a></li>5149 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.7">3.1.1</a></li> 5143 5150 <li><em>Section 4</em> <a href="#rfc.xref.Part1.37">9.4.1</a></li> 5144 5151 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.35">9.3.1</a></li> … … 5150 5157 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a></li> 5151 5158 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.15">5.1</a></li> 5152 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.9">3. 2</a>, <a href="#rfc.xref.Part1.10">3.3.4</a>, <a href="#rfc.xref.Part1.23">7</a></li>5159 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.9">3.1.2</a>, <a href="#rfc.xref.Part1.10">3.2.4</a>, <a href="#rfc.xref.Part1.23">7</a></li> 5153 5160 <li><em>Section 5.7</em> <a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.43">C</a></li> 5154 5161 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.34">9.3.1</a></li> … … 5159 5166 </ul> 5160 5167 </li> 5161 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3. 4</a>, <a href="#rfc.xref.Part4.2">3.4</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">5.2</a>, <a href="#rfc.xref.Part4.8">5.2</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">6.1</a>, <a href="#rfc.xref.Part4.12">6.3.2</a>, <a href="#rfc.xref.Part4.13">6.4</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>5162 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.2">3. 4</a></li>5163 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.1">3. 4</a>, <a href="#rfc.xref.Part4.12">6.3.2</a></li>5168 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">5.2</a>, <a href="#rfc.xref.Part4.8">5.2</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">6.1</a>, <a href="#rfc.xref.Part4.12">6.3.2</a>, <a href="#rfc.xref.Part4.13">6.4</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul> 5169 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.2">3.3</a></li> 5170 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.12">6.3.2</a></li> 5164 5171 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.5">5.2</a></li> 5165 5172 <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.6">5.2</a></li> … … 5171 5178 </ul> 5172 5179 </li> 5173 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.1 </a>, <a href="#rfc.xref.Part5.2">4.3.1</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a>, <a href="#rfc.xref.Part5.5">5.1</a>, <a href="#rfc.xref.Part5.6">5.2</a>, <a href="#rfc.xref.Part5.7">6.1</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">7.4</a>, <a href="#Part5"><b>12.1</b></a><ul>5180 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.1.1</a>, <a href="#rfc.xref.Part5.2">4.3.1</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a>, <a href="#rfc.xref.Part5.5">5.1</a>, <a href="#rfc.xref.Part5.6">5.2</a>, <a href="#rfc.xref.Part5.7">6.1</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">7.4</a>, <a href="#Part5"><b>12.1</b></a><ul> 5174 5181 <li><em>Section 3</em> <a href="#rfc.xref.Part5.7">6.1</a></li> 5175 5182 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.8">6.1</a></li> 5176 5183 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.9">6.1</a></li> 5177 5184 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.10">7.4</a></li> 5178 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.1">3.1 </a>, <a href="#rfc.xref.Part5.4">4.3.4</a></li>5185 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.1">3.1.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a></li> 5179 5186 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.6">5.2</a></li> 5180 5187 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.5">5.1</a></li> 5181 5188 </ul> 5182 5189 </li> 5183 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">3. 3</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3.1</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.9">6.3.4</a>, <a href="#rfc.xref.Part6.10">6.3.4</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a>, <a href="#rfc.xref.Part6.15">7.2</a>, <a href="#rfc.xref.Part6.16">7.2.2</a>, <a href="#rfc.xref.Part6.17">9.2.2</a>, <a href="#rfc.xref.Part6.18">9.3.1</a>, <a href="#Part6"><b>12.1</b></a><ul>5190 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">3.2</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3.1</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.9">6.3.4</a>, <a href="#rfc.xref.Part6.10">6.3.4</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a>, <a href="#rfc.xref.Part6.15">7.2</a>, <a href="#rfc.xref.Part6.16">7.2.2</a>, <a href="#rfc.xref.Part6.17">9.2.2</a>, <a href="#rfc.xref.Part6.18">9.3.1</a>, <a href="#Part6"><b>12.1</b></a><ul> 5184 5191 <li><em>Section 4.1.1</em> <a href="#rfc.xref.Part6.5">4.3.3</a></li> 5185 5192 <li><em>Section 4.1.2</em> <a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a></li> … … 5189 5196 <li><em>Section 7.1</em> <a href="#rfc.xref.Part6.15">7.2</a></li> 5190 5197 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.9">6.3.4</a></li> 5191 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.1">3. 3</a></li>5198 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.1">3.2</a></li> 5192 5199 <li><em>Section 7.5</em> <a href="#rfc.xref.Part6.10">6.3.4</a></li> 5193 5200 </ul> … … 5225 5232 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">9.4.2</a>, <a href="#RFC1952"><b>12.1</b></a></li> 5226 5233 <li><em>RFC2045</em> <a href="#RFC2045"><b>12.1</b></a>, <a href="#rfc.xref.RFC2045.1">A</a>, <a href="#rfc.xref.RFC2045.2">A.1</a></li> 5227 <li><em>RFC2046</em> <a href="#rfc.xref.RFC2046.1">3. 5</a>, <a href="#rfc.xref.RFC2046.2">8.5</a>, <a href="#rfc.xref.RFC2046.3">8.5.2</a>, <a href="#RFC2046"><b>12.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul>5228 <li><em>Section 4.5.1</em> <a href="#rfc.xref.RFC2046.1">3. 5</a></li>5234 <li><em>RFC2046</em> <a href="#rfc.xref.RFC2046.1">3.4</a>, <a href="#rfc.xref.RFC2046.2">8.5</a>, <a href="#rfc.xref.RFC2046.3">8.5.2</a>, <a href="#RFC2046"><b>12.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul> 5235 <li><em>Section 4.5.1</em> <a href="#rfc.xref.RFC2046.1">3.4</a></li> 5229 5236 <li><em>Section 5.1.1</em> <a href="#rfc.xref.RFC2046.3">8.5.2</a></li> 5230 5237 </ul> … … 5242 5249 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li> 5243 5250 <li><em>RFC2277</em> <a href="#rfc.xref.RFC2277.1">8.3</a>, <a href="#RFC2277"><b>12.2</b></a></li> 5244 <li><em>RFC2295</em> <a href="#rfc.xref.RFC2295.1">3. 6</a>, <a href="#RFC2295"><b>12.2</b></a></li>5251 <li><em>RFC2295</em> <a href="#rfc.xref.RFC2295.1">3.5</a>, <a href="#RFC2295"><b>12.2</b></a></li> 5245 5252 <li><em>RFC2388</em> <a href="#rfc.xref.RFC2388.1">8.5.2</a>, <a href="#RFC2388"><b>12.2</b></a></li> 5246 <li><em>RFC2557</em> <a href="#rfc.xref.RFC2557.1">3. 3.4</a>, <a href="#RFC2557"><b>12.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul>5247 <li><em>Section 4</em> <a href="#rfc.xref.RFC2557.1">3. 3.4</a></li>5253 <li><em>RFC2557</em> <a href="#rfc.xref.RFC2557.1">3.2.4</a>, <a href="#RFC2557"><b>12.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul> 5254 <li><em>Section 4</em> <a href="#rfc.xref.RFC2557.1">3.2.4</a></li> 5248 5255 </ul> 5249 5256 </li> … … 5301 5308 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 5302 5309 <li>safe <a href="#rfc.iref.s.2"><b>4.2.1</b></a></li> 5303 <li>selected representation <a href="#rfc.iref.s.1"><b>3. 4</b></a></li>5310 <li>selected representation <a href="#rfc.iref.s.1"><b>3.3</b></a></li> 5304 5311 <li>Server header field <a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">9.3.2</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">C</a></li> 5305 5312 <li>Status Codes Classes … … 5320 5327 </li> 5321 5328 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 5322 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3. 6.1</a>, <a href="#rfc.xref.header.user-agent.2">5.5</a>, <a href="#rfc.iref.u.1"><b>5.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>5329 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.5.1</a>, <a href="#rfc.xref.header.user-agent.2">5.5</a>, <a href="#rfc.iref.u.1"><b>5.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> 5323 5330 </ul> 5324 5331 </li> 5325 5332 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 5326 <li>Vary header field <a href="#rfc.xref.header.vary.1">3. 6.1</a>, <a href="#rfc.xref.header.vary.2">7.2</a>, <a href="#rfc.iref.v.1"><b>7.2.2</b></a>, <a href="#rfc.xref.header.vary.3">9.3.2</a></li>5333 <li>Vary header field <a href="#rfc.xref.header.vary.1">3.5.1</a>, <a href="#rfc.xref.header.vary.2">7.2</a>, <a href="#rfc.iref.v.1"><b>7.2.2</b></a>, <a href="#rfc.xref.header.vary.3">9.3.2</a></li> 5327 5334 </ul> 5328 5335 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1905 r1907 339 339 for resolving it. 340 340 </t> 341 342 <section title="Payload Header Fields" anchor="payload.header.fields"> 341 343 <t> 342 344 Header fields that specifically describe the payload, rather than the … … 355 357 </section> 356 358 357 <section title="Associating a Representation with its Resource" anchor="associating.representation.with.resource"> 358 <t> 359 It is sometimes necessary to determine an identifier for the resource 360 associated with a representation. 361 </t> 362 <t> 363 An HTTP request representation, when present, is always associated with an 364 anonymous (i.e., unidentified) resource. 365 </t> 366 <t> 367 In the common case, an HTTP response is a representation of the target 368 resource (see &effective-request-uri;). However, this is not always the 369 case. To determine the URI of the resource a response is associated with, 370 the following rules are used (with the first applicable one being selected): 371 </t> 372 <t><list style="numbers"> 373 <t>If the response status code is <x:ref>200 (OK)</x:ref> or <x:ref>203 374 (Non-Authoritative Information)</x:ref> and the request method was GET, 375 the response payload is a representation of the target resource.</t> 376 <t>If the response status code is <x:ref>204 (No Content)</x:ref>, 377 <x:ref>206 (Partial Content)</x:ref>, or <x:ref>304 (Not Modified)</x:ref> 378 and the request method was GET or HEAD, the response payload is a partial 379 representation of the target resource.</t> 380 <t>If the response has a <x:ref>Content-Location</x:ref> header field, and 381 that URI is the same as the effective request URI, the response payload is a 382 representation of the target resource.</t> 383 <t>If the response has a <x:ref>Content-Location</x:ref> header field, and 384 that URI is not the same as the effective request URI, then the response 385 asserts that its payload is a representation of the resource identified by 386 the Content-Location URI. However, such an assertion cannot be trusted unless 387 it can be verified by other means (not defined by HTTP).</t> 388 <t>Otherwise, the response is a representation of an anonymous (i.e., 389 unidentified) resource.</t> 390 </list></t> 391 <t> 392 <cref anchor="TODO-req-uri"> 393 The comparison function is going to have to be defined somewhere, 394 because we already need to compare URIs for things like cache invalidation.</cref> 395 </t> 359 <section title="Identifying the Payload" anchor="identifying.payload"> 360 <t> 361 When a complete or partial representation is transferred in a message 362 payload, it is often desirable for the sender to supply, or the recipient 363 to determine, an identifier for the resource corresponding to that 364 representation. 365 </t> 366 <t> 367 The following rules are used to determine such a URI for the payload of a 368 request message: 369 <list style="symbols"> 370 <t>If the request has a <x:ref>Content-Location</x:ref> header field, 371 then the sender asserts that the payload is a representation of the 372 resource identified by the Content-Location field-value. However, 373 such an assertion cannot be trusted unless it can be verified by 374 other means (not defined by HTTP). The information might still be 375 useful for revision history links.</t> 376 <t>Otherwise, the payload is unidentified.</t> 377 </list> 378 </t> 379 <t> 380 The following rules, to be applied in order until a match is found, are 381 used to determine such a URI for the payload of a response message: 382 <list style="numbers"> 383 <t>If the request is GET or HEAD and the response status code is 384 <x:ref>200 (OK)</x:ref>, 385 <x:ref>204 (No Content)</x:ref>, 386 <x:ref>206 (Partial Content)</x:ref>, or 387 <x:ref>304 (Not Modified)</x:ref>, 388 the payload's identifier is the effective request URI 389 (&effective-request-uri;).</t> 390 <t>If the request is GET or HEAD and the response status code is 391 <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is a 392 potentially modified representation of the target resource; as such, 393 the effective request URI might only act as an identifier for the 394 payload's representation when a request is made via the same chain 395 of intermediaries.</t> 396 <t>If the response has a <x:ref>Content-Location</x:ref> header field 397 and its field-value is a reference to the same URI as the effective 398 request URI, the payload's identifier is the effective request URI.</t> 399 <t>If the response has a <x:ref>Content-Location</x:ref> header field 400 and its field-value is a reference to a URI different from the 401 effective request URI, then the sender asserts that the payload is a 402 representation of the resource identified by the Content-Location 403 field-value. However, such an assertion cannot be trusted unless 404 it can be verified by other means (not defined by HTTP).</t> 405 <t>Otherwise, the payload is unidentified.</t> 406 </list> 407 </t> 408 </section> 396 409 </section> 397 410 … … 4125 4138 <section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes"> 4126 4139 <t> 4127 When it is necessary to express new semantics for a HTTP response that 4128 aren't specific to a single application or media type, and currently defined 4129 status codes are inadequate, a new status code can be registered. 4130 </t> 4131 <t> 4132 HTTP status codes are generic; that is, they are potentially applicable to 4140 When it is necessary to express semantics for a response that are not 4141 defined by current status codes, a new status code can be registered. 4142 HTTP status codes are generic; they are potentially applicable to 4133 4143 any resource, not just one particular media type, "type" of resource, or 4134 application. As such, it is preferred that new HTTP status codes be 4135 registered in a document that isn't specific to a single application, so 4136 that this is clear. 4137 </t> 4138 <t> 4139 Definitions of new HTTP status codes typically explain the request 4140 conditions that produce a response containing the status code (e.g., 4141 combinations of request header fields and/or method(s)), along with any 4142 interactions with response header fields (e.g., those that are required, 4143 those that modify the semantics of the response). 4144 </t> 4145 <t> 4146 New HTTP status codes are required to fall under one of the categories 4144 application. As such, it is preferred that new status codes be 4145 registered in a document that isn't specific to a single application. 4146 </t> 4147 <t> 4148 New status codes are required to fall under one of the categories 4147 4149 defined in <xref target="status.codes"/>. To allow existing parsers to 4148 4150 properly handle them, new status codes cannot disallow a response body, 4149 although they can mandate a zero-length response body. They can require the 4150 presence of one or more particular HTTP response header field(s). 4151 </t> 4152 <t> 4153 Likewise, their definitions can specify that caches are allowed to use 4154 heuristics to determine their freshness (see &caching;; by default, it is 4155 not allowed), and can define how to determine the resource which they 4156 carry a representation for (see <xref 4157 target="associating.representation.with.resource"/>; by default, 4158 it is anonymous). 4151 although they can mandate a zero-length response body. 4152 </t> 4153 <t> 4154 A definition for a new status code ought to explain the request 4155 conditions that produce a response containing that status code (e.g., 4156 combinations of request header fields and/or method(s)) along with any 4157 dependencies on response header fields (e.g., what fields are required 4158 and what fields can modify the semantics). A response that can transfer a 4159 payload ought to specify expected cache behavior (e.g., cacheability and 4160 freshness criteria, as described in &caching;) and whether the payload has 4161 any implied association with an identified resource 4162 (<xref target="identifying.payload"/>). 4159 4163 </t> 4160 4164 </section>
Note: See TracChangeset
for help on using the changeset viewer.