Changeset 1043 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 22/10/10 02:18:34 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1042 r1043 905 905 and currently defined status codes are inadequate, a new status code can be registered. 906 906 </p> 907 <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). 908 </p> 909 <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). 910 </p> 911 <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 912 method(s)), they <em class="bcp14">SHOULD</em> be described in detail. 913 </p> 914 <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 915 are not specific to that application or extension. 907 <p id="rfc.section.4.1.1.p.2">HTTP status codes are generic; that is, they are potentially applicable to any resource, not just one particular media type, 908 "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't 909 specific to a single application, so that this is clear. 910 </p> 911 <p id="rfc.section.4.1.1.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status 912 code (e.g., combinations of request headers and/or method(s)), along with any interactions with response headers (e.g., those 913 that are required, those that modify the semantics of the response). 914 </p> 915 <p id="rfc.section.4.1.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section 8</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate 916 a zero-length response body. They can require the presence of one or more particular HTTP response header(s). 917 </p> 918 <p id="rfc.section.4.1.1.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.4"><cite title="HTTP/1.1, part 6: 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="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 6.1</a>; by default, it is anonymous). 916 919 </p> 917 920 <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>
Note: See TracChangeset
for help on using the changeset viewer.