![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1035 for draft-ietf-httpbis
- Timestamp:
- Oct 18, 2010, 11:12:43 PM (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p2-semantics.html (modified) (16 diffs)
-
p2-semantics.xml (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1034 r1035 550 550 <li class="tocline0">3. <a href="#request.header.fields">Request Header Fields</a></li> 551 551 <li class="tocline0">4. <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a><ul class="toc"> 552 <li class="tocline1">4.1 <a href="#status.code.registry">Status Code Registry</a></li> 552 <li class="tocline1">4.1 <a href="#status.code.registry">Status Code Registry</a><ul class="toc"> 553 <li class="tocline1">4.1.1 <a href="#rfc.section.4.1.1">Considerations for New Status Codes</a></li> 554 </ul> 555 </li> 553 556 </ul> 554 557 </li> … … 804 807 <p id="rfc.section.2.1.1.p.5">New methods <em class="bcp14">SHOULD</em> explain how conditional request headers (<a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) affect the response (if there is any effect). 805 808 </p> 806 <p id="rfc.section.2.1.1.p.6">HTTP methods <em class="bcp14">SHOULD</em> be registered in a document that isn't specific to a n application or other use of HTTP, so that it's clear that they are not807 specific to that application or extension.809 <p id="rfc.section.2.1.1.p.6">HTTP methods <em class="bcp14">SHOULD</em> be registered in a document that isn't specific to a single application or other use of HTTP, so that it's clear that they 810 are not specific to that application or extension. 808 811 </p> 809 812 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1> … … 901 904 <p id="rfc.section.4.1.p.3">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>>. 902 905 </p> 906 <h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> Considerations for New Status Codes 907 </h3> 908 <p id="rfc.section.4.1.1.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, 909 and currently defined status codes are inadequate, a new status code can be registered. 910 </p> 911 <p id="rfc.section.4.1.1.p.2">New HTTP status codes <em class="bcp14">MUST</em> be defined in one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section 8</a>. They <em class="bcp14">MUST NOT</em> disallow a response body, although they <em class="bcp14">MAY</em> mandate a zero-length response body. They <em class="bcp14">MAY</em> require the presence of one or more particular HTTP response header(s). 912 </p> 913 <p id="rfc.section.4.1.1.p.3">Likewise, their definitions <em class="bcp14">MAY</em> specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and <em class="bcp14">MAY</em> define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 6.1</a>; by default, it is anonymous). 914 </p> 915 <p id="rfc.section.4.1.1.p.4">If there are particular request conditions that produce a response containing the status code (e.g., request headers and/or 916 method(s)), they <em class="bcp14">SHOULD</em> be described in detail. 917 </p> 918 <p id="rfc.section.4.1.1.p.5">New HTTP status codes <em class="bcp14">SHOULD</em> be registered in a document that isn't specific to a single application or other use of HTTP, so that it's clear that they 919 are not specific to that application or extension. 920 </p> 903 921 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 904 922 <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the … … 906 924 </p> 907 925 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> 908 / <a href="#abnf.dependencies" class="smpl">Age</a> ; <a href="#Part6" id="rfc.xref.Part6. 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 3.1</a>926 / <a href="#abnf.dependencies" class="smpl">Age</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 3.1</a> 909 927 / <a href="#header.allow" class="smpl">Allow</a> ; <a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 9.1</a> 910 928 / <a href="#abnf.dependencies" class="smpl">ETag</a> ; <a href="#Part4" id="rfc.xref.Part4.14"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> … … 913 931 / <a href="#header.retry-after" class="smpl">Retry-After</a> ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 9.7</a> 914 932 / <a href="#header.server" class="smpl">Server</a> ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 9.8</a> 915 / <a href="#abnf.dependencies" class="smpl">Vary</a> ; <a href="#Part6" id="rfc.xref.Part6. 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a>933 / <a href="#abnf.dependencies" class="smpl">Vary</a> ; <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> 916 934 / <a href="#abnf.dependencies" class="smpl">WWW-Authenticate</a> ; <a href="#Part7" id="rfc.xref.Part7.11"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> 917 935 </pre><p id="rfc.section.5.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new … … 938 956 </li> 939 957 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial 940 representation of the target (see <a href="p6-cache.html#combining.responses" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6. 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).958 representation of the target (see <a href="p6-cache.html#combining.responses" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 941 959 </li> 942 960 <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload … … 1019 1037 be completed without transferring data already held by the client. 1020 1038 </p> 1021 <p id="rfc.section.7.3.p.5">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6. 7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1039 <p id="rfc.section.7.3.p.5">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1022 1040 </p> 1023 1041 <p id="rfc.section.7.3.p.6">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations when used for forms. … … 1030 1048 hypertext links for validity, accessibility, and recent modification. 1031 1049 </p> 1032 <p id="rfc.section.7.4.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request; see <a href="#Part6" id="rfc.xref.Part6. 8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. It also <em class="bcp14">MAY</em> be used to update a previously cached representation from that resource; if the new field values indicate that the cached1050 <p id="rfc.section.7.4.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request; see <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. It also <em class="bcp14">MAY</em> be used to update a previously cached representation from that resource; if the new field values indicate that the cached 1033 1051 representation differs from the current representation (as would be indicated by a change in Content-Length, Content-MD5, 1034 1052 ETag or Last-Modified), then the cache <em class="bcp14">MUST</em> treat the cache entry as stale. … … 1056 1074 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>). 1057 1075 </p> 1058 <p id="rfc.section.7.5.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 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6. 9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1076 <p id="rfc.section.7.5.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 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1059 1077 </p> 1060 1078 <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1172 1190 <dd>a representation containing the request message as received by the end server.</dd> 1173 1191 </dl> 1174 <p id="rfc.section.8.2.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 0"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses.1192 <p id="rfc.section.8.2.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses. 1175 1193 </p> 1176 1194 <div id="rfc.iref.28"></div> … … 1206 1224 when the response would otherwise be 200 (OK). 1207 1225 </p> 1208 <p id="rfc.section.8.2.4.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.1226 <p id="rfc.section.8.2.4.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. 1209 1227 </p> 1210 1228 <div id="rfc.iref.31"></div> … … 1235 1253 defined in <a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1236 1254 </p> 1237 <p id="rfc.section.8.2.7.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses.1255 <p id="rfc.section.8.2.7.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses. 1238 1256 </p> 1239 1257 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 1259 1277 <p id="rfc.section.8.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. 1260 1278 </p> 1261 <p id="rfc.section.8.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.1279 <p id="rfc.section.8.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. 1262 1280 </p> 1263 1281 <div id="rfc.iref.35"></div> … … 1267 1285 request URI to one or more of the new references returned by the server, where possible. 1268 1286 </p> 1269 <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.1287 <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 1270 1288 </p> 1271 1289 <p id="rfc.section.8.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1439 1457 -- that is left to the discretion of the server owner. 1440 1458 </p> 1441 <p id="rfc.section.8.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.1459 <p id="rfc.section.8.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. 1442 1460 </p> 1443 1461 <div id="rfc.iref.53"></div> … … 2813 2831 </ul> 2814 2832 </li> 2815 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part6.3">2.1.1</a>, <a class="iref" href="#rfc.xref.Part6.4"> 5</a>, <a class="iref" href="#rfc.xref.Part6.5">5</a>, <a class="iref" href="#rfc.xref.Part6.6">6.1</a>, <a class="iref" href="#rfc.xref.Part6.7">7.3</a>, <a class="iref" href="#rfc.xref.Part6.8">7.4</a>, <a class="iref" href="#rfc.xref.Part6.9">7.5</a>, <a class="iref" href="#rfc.xref.Part6.10">8.2.1</a>, <a class="iref" href="#rfc.xref.Part6.11">8.2.4</a>, <a class="iref" href="#rfc.xref.Part6.12">8.2.7</a>, <a class="iref" href="#rfc.xref.Part6.13">8.3.1</a>, <a class="iref" href="#rfc.xref.Part6.14">8.3.2</a>, <a class="iref" href="#rfc.xref.Part6.15">8.4.11</a>, <a class="iref" href="#Part6"><b>13.1</b></a><ul class="ind">2816 <li class="indline1"><em>Section 2.3.1</em> <a class="iref" href="#rfc.xref.Part6. 9">7.5</a></li>2817 <li class="indline1"><em>Section 2.3.1.1</em> <a class="iref" href="#rfc.xref.Part6.1 0">8.2.1</a>, <a class="iref" href="#rfc.xref.Part6.11">8.2.4</a>, <a class="iref" href="#rfc.xref.Part6.12">8.2.7</a>, <a class="iref" href="#rfc.xref.Part6.13">8.3.1</a>, <a class="iref" href="#rfc.xref.Part6.14">8.3.2</a>, <a class="iref" href="#rfc.xref.Part6.15">8.4.11</a></li>2818 <li class="indline1"><em>Section 2.8</em> <a class="iref" href="#rfc.xref.Part6. 6">6.1</a></li>2819 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part6. 4">5</a></li>2820 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part6. 5">5</a></li>2833 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part6.3">2.1.1</a>, <a class="iref" href="#rfc.xref.Part6.4">4.1.1</a>, <a class="iref" href="#rfc.xref.Part6.5">5</a>, <a class="iref" href="#rfc.xref.Part6.6">5</a>, <a class="iref" href="#rfc.xref.Part6.7">6.1</a>, <a class="iref" href="#rfc.xref.Part6.8">7.3</a>, <a class="iref" href="#rfc.xref.Part6.9">7.4</a>, <a class="iref" href="#rfc.xref.Part6.10">7.5</a>, <a class="iref" href="#rfc.xref.Part6.11">8.2.1</a>, <a class="iref" href="#rfc.xref.Part6.12">8.2.4</a>, <a class="iref" href="#rfc.xref.Part6.13">8.2.7</a>, <a class="iref" href="#rfc.xref.Part6.14">8.3.1</a>, <a class="iref" href="#rfc.xref.Part6.15">8.3.2</a>, <a class="iref" href="#rfc.xref.Part6.16">8.4.11</a>, <a class="iref" href="#Part6"><b>13.1</b></a><ul class="ind"> 2834 <li class="indline1"><em>Section 2.3.1</em> <a class="iref" href="#rfc.xref.Part6.10">7.5</a></li> 2835 <li class="indline1"><em>Section 2.3.1.1</em> <a class="iref" href="#rfc.xref.Part6.11">8.2.1</a>, <a class="iref" href="#rfc.xref.Part6.12">8.2.4</a>, <a class="iref" href="#rfc.xref.Part6.13">8.2.7</a>, <a class="iref" href="#rfc.xref.Part6.14">8.3.1</a>, <a class="iref" href="#rfc.xref.Part6.15">8.3.2</a>, <a class="iref" href="#rfc.xref.Part6.16">8.4.11</a></li> 2836 <li class="indline1"><em>Section 2.8</em> <a class="iref" href="#rfc.xref.Part6.7">6.1</a></li> 2837 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part6.5">5</a></li> 2838 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part6.6">5</a></li> 2821 2839 </ul> 2822 2840 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1034 r1035 507 507 508 508 <t>HTTP methods &SHOULD; be registered in a document that isn't specific to 509 a n application or other use of HTTP, so that it's clear that they are not510 specific to that application or extension.</t>509 a single application or other use of HTTP, so that it's clear that they are 510 not specific to that application or extension.</t> 511 511 512 512 </section> … … 652 652 The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>. 653 653 </t> 654 655 <section title="Considerations for New Status Codes"> 656 657 <t>When it is necessary to express new semantics for a HTTP response that 658 aren't specific to a single application or media type, and currently defined 659 status codes are inadequate, a new status code can be registered.</t> 660 661 <t>New HTTP status codes &MUST; be defined in one of the categories defined 662 in <xref target="status.codes"/>. They &MUST-NOT; disallow a response body, 663 although they &MAY; mandate a zero-length response body. They &MAY; require 664 the presence of one or more particular HTTP response header(s).</t> 665 666 <t>Likewise, their definitions &MAY; specify that caches are allowed to use 667 heuristics to determine their freshness (see &caching;; by default, it is 668 not allowed), and &MAY; define how to determine the resource which they 669 carry a representation for (see <xref 670 target="identifying.response.associated.with.representation"/>; by default, 671 it is anonymous).</t> 672 673 <t>If there are particular request conditions that produce a response 674 containing the status code (e.g., request headers and/or method(s)), they 675 &SHOULD; be described in detail.</t> 676 677 <t>New HTTP status codes &SHOULD; be registered in a document that isn't 678 specific to a single application or other use of HTTP, so that it's clear that 679 they are not specific to that application or extension.</t> 680 681 </section> 682 654 683 </section> 655 684
Note: See TracChangeset
for help on using the changeset viewer.
