Changeset 2047 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 09/12/12 16:54:07 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2046 r2047 916 916 Text/HTML;Charset="utf-8" 917 917 text/html; charset="utf-8" 918 </pre><p id="rfc.section.3.1.1.1.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is 919 outlined in <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>. Use of non-registered media types is discouraged. 918 </pre><p id="rfc.section.3.1.1.1.p.8">Internet media types ought to be registered with IANA according to the procedures defined in <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>. 920 919 </p> 921 920 <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a> <a id="charset" href="#charset">Charset</a></h4> … … 923 922 </p> 924 923 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#charset" class="smpl">charset</a> = <a href="#imported.abnf" class="smpl">token</a> 925 </pre><p id="rfc.section.3.1.1.2.p.3"> The IANA Character Set registry (<<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>>) maintains the set of tokens registered for use on the Internet as charset names<a href="#RFC2978" id="rfc.xref.RFC2978.1"><cite title="IANA Charset Registration Procedures">[RFC2978]</cite></a>.924 </pre><p id="rfc.section.3.1.1.2.p.3">Charset names ought to be registered in IANA Character Set registry (<<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>>) according to the procedures defined in <a href="#RFC2978" id="rfc.xref.RFC2978.1"><cite title="IANA Charset Registration Procedures">[RFC2978]</cite></a>. 926 925 </p> 927 926 <h4 id="rfc.section.3.1.1.3"><a href="#rfc.section.3.1.1.3">3.1.1.3</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h4> … … 985 984 </p> 986 985 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#imported.abnf" class="smpl">token</a> 987 </pre><p id="rfc.section.3.1.2.1.p.3">All content-coding values are case-insensitive and <em class="bcp14">SHOULD</em> be registered within the HTTP Content Coding registry, as defined in <a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>. They are used in the <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 6.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.1.2.2</a>) header fields. 986 </pre><p id="rfc.section.3.1.2.1.p.3">All content-coding values are case-insensitive and ought to be registered within the HTTP Content Coding registry, as defined 987 in <a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>. They are used in the <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 6.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.1.2.2</a>) header fields. 988 988 </p> 989 989 <p id="rfc.section.3.1.2.1.p.4">The following content-coding values are defined by this specification: </p> … … 1355 1355 <p id="rfc.section.5.1.p.6">The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>. When implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section 5.3</a>. 1356 1356 </p> 1357 <p id="rfc.section.5.1.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and registered within the HTTP1358 Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section 9.1</a>.1357 <p id="rfc.section.5.1.p.7">Additional methods <em class="bcp14">MAY</em> be used in HTTP; many have already been standardized outside the scope of this specification and ought to be registered within 1358 the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section 9.1</a>. 1359 1359 </p> 1360 1360 <p id="rfc.section.5.1.p.8">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 8.4.1</a>). However, the set of allowed methods can change dynamically. When a request message is received that is unrecognized or … … 3463 3463 or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages. 3464 3464 </p> 3465 <p id="rfc.section.9.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them 3466 with "X-" if they are to be registered (either immediately or in the future). 3465 <p id="rfc.section.9.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical and to not prefix the name 3466 with "X-" unless the header field will never be used on the Internet. (The "x-" prefix idiom has been extensively misused 3467 in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet 3468 processing, since the prefix would ensure that private names never collide with a newly registered Internet name.) 3467 3469 </p> 3468 3470 <p id="rfc.section.9.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
Note: See TracChangeset
for help on using the changeset viewer.