Changeset 1452 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 23/10/11 20:20:31 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1451 r1452 359 359 } 360 360 @bottom-center { 361 content: "Expires April 2 2, 2012";361 content: "Expires April 25, 2012"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-2 0">411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: April 2 2, 2012</td>442 <td class="left">Expires: April 25, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">October 2 0, 2011</td>495 <td class="right">October 23, 2011</td> 496 496 </tr> 497 497 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on April 2 2, 2012.</p>525 <p>This Internet-Draft will expire on April 25, 2012.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 542 542 <ul class="toc"> 543 543 <li>1. <a href="#introduction">Introduction</a><ul> 544 <li>1.1 <a href="#intro. requirements">Requirements</a></li>544 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 545 545 <li>1.2 <a href="#notation">Syntax Notation</a><ul> 546 546 <li>1.2.1 <a href="#core.rules">Core Rules</a></li> … … 726 726 reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 727 727 </p> 728 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>728 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 729 729 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 730 730 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 731 731 </p> 732 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 733 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 734 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 735 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 732 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 733 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 734 </p> 735 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 736 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 737 </p> 738 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 739 </p> 740 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 741 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 742 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 743 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 744 error recovery could lead to dangerous consequences. 736 745 </p> 737 746 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 738 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded.747 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded. 739 748 </p> 740 749 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 743 752 </p> 744 753 <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 745 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1. 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:746 </p> 747 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>748 <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1. 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>749 <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1. 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>750 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1. 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>751 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1. 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>754 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 755 </p> 756 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 757 <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 758 <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 759 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 760 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 752 761 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 753 762 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 754 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>755 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.1 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>>756 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>757 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>>758 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.1 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>763 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 764 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 765 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 766 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>> 767 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 759 768 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 760 <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.769 <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 761 770 </p> 762 771 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method" class="smpl">Method</a> = <a href="#core.rules" class="smpl">token</a> … … 837 846 to a single application, so that this is clear. 838 847 </p> 839 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message848 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message 840 849 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 841 850 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 846 855 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 847 856 <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, 848 or about the connection itself (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.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.857 or about the connection itself (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.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 849 858 </p> 850 859 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2> … … 854 863 with "X-" if they are to be registered (either immediately or in the future). 855 864 </p> 856 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters865 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 857 866 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 858 867 </p> 859 868 <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 860 869 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 861 quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).870 quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 862 871 </p> 863 872 <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 874 883 <ul> 875 884 <li> 876 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).885 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 877 886 </p> 878 887 <p>If it does not use the list syntax, how to treat messages where the header field occurs multiple times (a sensible default … … 886 895 </li> 887 896 <li> 888 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).897 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 889 898 </p> 890 899 </li> … … 897 906 </li> 898 907 <li> 899 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).908 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 900 909 </p> 901 910 </li> … … 948 957 <tr> 949 958 <td class="left">Host</td> 950 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>959 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 951 960 </tr> 952 961 <tr> … … 988 997 <tr> 989 998 <td class="left">TE</td> 990 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>999 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 991 1000 </tr> 992 1001 <tr> … … 999 1008 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 1000 1009 <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 1001 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1010 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1002 1011 </p> 1003 1012 <div id="rfc.table.u.3"> … … 1321 1330 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 1322 1331 </p> 1323 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied1332 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied 1324 1333 to ensure safe and proper transfer of the message. 1325 1334 </p> … … 1327 1336 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 1328 1337 <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 1329 <p id="rfc.section.5.1.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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following1338 <p id="rfc.section.5.1.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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 1330 1339 rules are used (with the first applicable one being selected): 1331 1340 </p> … … 1550 1559 </p> 1551 1560 <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1552 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1561 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1553 1562 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1554 1563 infinite loop. 1555 1564 </p> 1556 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1565 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1557 1566 </p> 1558 1567 <div id="rfc.iref.c.1"></div> … … 1562 1571 forwarding of packets until the connection is closed. 1563 1572 </p> 1564 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1573 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1565 1574 For example, 1566 1575 </p> … … 1626 1635 <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1627 1636 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1628 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1637 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1629 1638 </p> 1630 1639 <div id="rfc.iref.23"></div> 1631 1640 <div id="rfc.iref.s.3"></div> 1632 1641 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1633 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1642 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1634 1643 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1635 1644 </p> … … 1683 1692 <div id="rfc.iref.s.7"></div> 1684 1693 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1685 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.4</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1694 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1686 1695 </p> 1687 1696 <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code … … 1718 1727 another input action. 1719 1728 </p> 1720 <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1729 <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1721 1730 </p> 1722 1731 <div id="rfc.iref.30"></div> … … 2014 2023 <div id="rfc.iref.s.37"></div> 2015 2024 <h3 id="rfc.section.7.4.19"><a href="#rfc.section.7.4.19">7.4.19</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2016 <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.2025 <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2017 2026 </p> 2018 2027 <div id="rfc.figure.u.8"></div> … … 2074 2083 <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 2075 2084 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2076 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.2085 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 2077 2086 </p> 2078 2087 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h1> … … 2230 2239 </p> 2231 2240 <p id="rfc.section.9.3.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2232 <p id="rfc.section.9.3.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.2241 <p id="rfc.section.9.3.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 2233 2242 </p> 2234 2243 <div id="rfc.iref.f.1"></div> … … 2334 2343 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.server" href="#header.server">Server</a></h2> 2335 2344 <p id="rfc.section.9.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2336 <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2345 <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2337 2346 identifying the application. 2338 2347 </p> … … 2340 2349 </pre><p id="rfc.section.9.9.p.4">Example:</p> 2341 2350 <div id="rfc.figure.u.33"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2342 </pre><p id="rfc.section.9.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1. 39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2351 </pre><p id="rfc.section.9.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2343 2352 </p> 2344 2353 <div class="note" id="rfc.section.9.9.p.7"> … … 2356 2365 user agent limitations. 2357 2366 </p> 2358 <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2367 <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2359 2368 for identifying the application. 2360 2369 </p> … … 2828 2837 </p> 2829 2838 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2830 <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.4 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2839 <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2831 2840 </p> 2832 2841 <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References … … 2988 2997 </p> 2989 2998 <p id="rfc.section.A.p.14">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 2990 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.4 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.9</a>)2999 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.9</a>) 2991 3000 </p> 2992 3001 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3369 3378 <ul> 3370 3379 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/160">http://tools.ietf.org/wg/httpbis/trac/ticket/160</a>>: "Redirects and non-GET methods" 3380 </li> 3381 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 3371 3382 </li> 3372 3383 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/310">http://tools.ietf.org/wg/httpbis/trac/ticket/310</a>>: "clarify 303 redirect on HEAD" … … 3550 3561 </li> 3551 3562 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3552 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.15">2.2.1</a>, <a href="#rfc.xref.Part1.16">3</a>, <a href="#rfc.xref.Part1.17">3.1</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.2</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.3</a>, <a href="#rfc.xref.Part1.25">5</a>, <a href="#rfc.xref.Part1.26">5.1</a>, <a href="#rfc.xref.Part1.27">6.8</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.9</a>, <a href="#rfc.xref.Part1.30">7.1.1</a>, <a href="#rfc.xref.Part1.31">7.1.2</a>, <a href="#rfc.xref.Part1.32">7.2.4</a>, <a href="#rfc.xref.Part1.33">7.2.6</a>, <a href="#rfc.xref.Part1.34">7.4.19</a>, <a href="#rfc.xref.Part1.35">7.5.6</a>, <a href="#rfc.xref.Part1.36">9.3</a>, <a href="#rfc.xref.Part1.37">9.9</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.10</a>, <a href="#rfc.xref.Part1.41">9.10</a>, <a href="#rfc.xref.Part1.42">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul> 3553 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 3554 <li><em>Section 1.2.1</em> <a href="#rfc.xref.Part1.17">3.1</a></li> 3555 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li> 3556 <li><em>Section 2.4</em> <a href="#rfc.xref.Part1.32">7.2.4</a></li> 3557 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.35">7.5.6</a></li> 3558 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a></li> 3559 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.29">6.9</a></li> 3560 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.16">3</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a></li> 3561 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.18">3.1</a></li> 3562 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.15">2.2.1</a>, <a href="#rfc.xref.Part1.25">5</a>, <a href="#rfc.xref.Part1.33">7.2.6</a></li> 3563 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.24">3.3</a>, <a href="#rfc.xref.Part1.26">5.1</a></li> 3564 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3565 <li><em>Section 5.2</em> <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.37">9.9</a>, <a href="#rfc.xref.Part1.40">9.10</a></li> 3566 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.30">7.1.1</a>, <a href="#rfc.xref.Part1.36">9.3</a></li> 3567 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.20">3.1</a></li> 3568 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.22">3.2</a></li> 3569 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3570 <li><em>Section 8.7</em> <a href="#rfc.xref.Part1.31">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.4.19</a></li> 3571 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.27">6.8</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.43">A</a></li> 3572 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.28">6.8</a></li> 3573 <li><em>Section 11</em> <a href="#rfc.xref.Part1.42">12</a></li> 3563 <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">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.19</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">9.3</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.44">A</a><ul> 3564 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 3565 <li><em>Section 1.2.1</em> <a href="#rfc.xref.Part1.18">3.1</a></li> 3566 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 3567 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 3568 <li><em>Section 2.4</em> <a href="#rfc.xref.Part1.33">7.2.4</a></li> 3569 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.36">7.5.6</a></li> 3570 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> 3571 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.30">6.9</a></li> 3572 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a></li> 3573 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.19">3.1</a></li> 3574 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li> 3575 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li> 3576 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3577 <li><em>Section 5.2</em> <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a></li> 3578 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">9.3</a></li> 3579 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3580 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3581 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3582 <li><em>Section 8.7</em> <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.19</a></li> 3583 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.44">A</a></li> 3584 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.29">6.8</a></li> 3585 <li><em>Section 11</em> <a href="#rfc.xref.Part1.43">12</a></li> 3574 3586 </ul> 3575 3587 </li>
Note: See TracChangeset
for help on using the changeset viewer.