Changeset 1494 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 16/12/11 21:11:53 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1493 r1494 359 359 } 360 360 @bottom-center { 361 content: "Expires June 1 7, 2012";361 content: "Expires June 18, 2012"; 362 362 } 363 363 @bottom-right { … … 411 411 <meta name="dct.creator" content="Reschke, J. F."> 412 412 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 413 <meta name="dct.issued" scheme="ISO8601" content="2011-12-1 5">413 <meta name="dct.issued" scheme="ISO8601" content="2011-12-16"> 414 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 415 415 <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."> … … 442 442 </tr> 443 443 <tr> 444 <td class="left">Expires: June 1 7, 2012</td>444 <td class="left">Expires: June 18, 2012</td> 445 445 <td class="right">HP</td> 446 446 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">December 1 5, 2011</td>497 <td class="right">December 16, 2011</td> 498 498 </tr> 499 499 </tbody> … … 525 525 in progress”. 526 526 </p> 527 <p>This Internet-Draft will expire on June 1 7, 2012.</p>527 <p>This Internet-Draft will expire on June 18, 2012.</p> 528 528 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 529 529 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 757 757 <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>: 758 758 </p> 759 <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>> 760 <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>> 761 <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>> 762 <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>> 763 <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>> 759 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, 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>> 760 <a href="#core.rules" class="smpl">OWS</a> = <OWS, 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>> 761 <a href="#core.rules" class="smpl">RWS</a> = <RWS, 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>> 762 <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, 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#basic.rules" title="Basic Rules">Section 1.2.2</a>> 763 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, 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>> 764 <a href="#core.rules" class="smpl">token</a> = <token, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 764 765 </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> 765 766 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 766 <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.1 0"><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>>767 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, 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#header.fields" title="Header Fields">Section 3.2</a>>768 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>>769 <a href="#abnf.dependencies" class="smpl">product</a> = <product, 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#product.tokens" title="Product Tokens">Section 5.2</a>>770 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.1 4"><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>>767 <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.11"><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>> 768 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, 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#header.fields" title="Header Fields">Section 3.2</a>> 769 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 770 <a href="#abnf.dependencies" class="smpl">product</a> = <product, 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#product.tokens" title="Product Tokens">Section 5.2</a>> 771 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.15"><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>> 771 772 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 772 <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 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.773 <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.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 773 774 </p> 774 775 <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> … … 849 850 to a single application, so that this is clear. 850 851 </p> 851 <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 6"><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 message852 <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.17"><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 852 853 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 853 854 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 858 859 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 859 860 <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, 860 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 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.861 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.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 861 862 </p> 862 863 <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> … … 866 867 with "X-" if they are to be registered (either immediately or in the future). 867 868 </p> 868 <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 8"><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 characters869 <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.19"><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 869 870 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>. 870 871 </p> 871 872 <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 872 873 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 873 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>).874 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.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 874 875 </p> 875 876 <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 … … 889 890 <ul> 890 891 <li> 891 <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.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).892 <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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 892 893 </p> 893 894 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 905 906 </li> 906 907 <li> 907 <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 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).908 <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.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 908 909 </p> 909 910 </li> … … 916 917 </li> 917 918 <li> 918 <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 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).919 <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.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 919 920 </p> 920 921 </li> … … 967 968 <tr> 968 969 <td class="left">Host</td> 969 <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 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>970 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</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> 970 971 </tr> 971 972 <tr> … … 1007 1008 <tr> 1008 1009 <td class="left">TE</td> 1009 <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 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1010 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</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></td> 1010 1011 </tr> 1011 1012 <tr> … … 1018 1019 <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> 1019 1020 <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 1020 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 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1021 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.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1021 1022 </p> 1022 1023 <div id="rfc.table.u.3"> … … 1340 1341 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>. 1341 1342 </p> 1342 <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 6"><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 applied1343 <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.27"><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 1343 1344 to ensure safe and proper transfer of the message. 1344 1345 </p> … … 1346 1347 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 1347 1348 <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> 1348 <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 7"><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 following1349 <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.28"><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 1349 1350 rules are used (with the first applicable one being selected): 1350 1351 </p> … … 1569 1570 </p> 1570 1571 <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 1571 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 8"><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 the1572 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.29"><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 1572 1573 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1573 1574 infinite loop. 1574 1575 </p> 1575 <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.1576 <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.30"><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. 1576 1577 </p> 1577 1578 <div id="rfc.iref.c.1"></div> … … 1581 1582 forwarding of packets until the connection is closed. 1582 1583 </p> 1583 <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.3 0"><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.1584 <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.31"><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. 1584 1585 For example, 1585 1586 </p> … … 1645 1646 <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 1646 1647 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 1647 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 1"><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.1648 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.32"><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. 1648 1649 </p> 1649 1650 <div id="rfc.iref.23"></div> 1650 1651 <div id="rfc.iref.s.3"></div> 1651 1652 <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> 1652 <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 2"><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 defined1653 <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.33"><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 1653 1654 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1654 1655 </p> … … 1702 1703 <div id="rfc.iref.s.7"></div> 1703 1704 <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> 1704 <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 3"><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>).1705 <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.34"><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>). 1705 1706 </p> 1706 1707 <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 … … 1737 1738 another input action. 1738 1739 </p> 1739 <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 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1740 <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.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1740 1741 </p> 1741 1742 <div id="rfc.iref.30"></div> … … 2038 2039 <div id="rfc.iref.s.37"></div> 2039 2040 <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> 2040 <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 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.2041 <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.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2041 2042 </p> 2042 2043 <div id="rfc.figure.u.8"></div> … … 2096 2097 <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 2097 2098 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2098 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</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>, 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.2099 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</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>, 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. 2099 2100 </p> 2100 2101 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h1> … … 2233 2234 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 2234 2235 <p id="rfc.section.9.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 2235 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a>2236 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 2236 2237 2237 <a href="#header.expect" class="smpl">expectation</a> = "100-continue" / <a href="#header.expect" class="smpl">expectation-extension</a> 2238 <a href="#header.expect" class="smpl">expectation-extension</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) 2239 *(";" <a href="#header.expect" class="smpl">expect-param</a>) ] 2240 <a href="#header.expect" class="smpl">expect-param</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ] 2241 </pre><p id="rfc.section.9.3.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status code. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code if any of the expectations cannot be met or, if there are other problems 2242 with the request, some other 4xx status code. 2243 </p> 2244 <p id="rfc.section.9.3.p.4">This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing 2245 an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. 2246 </p> 2247 <p id="rfc.section.9.3.p.5">Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive 2248 for quoted-string expectation-extensions. 2249 </p> 2250 <p id="rfc.section.9.3.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the 2251 Expect header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 2252 </p> 2253 <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> 2254 <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. 2255 </p> 2238 <a href="#header.expect" class="smpl">expectation</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] 2239 *( <a href="#core.rules" class="smpl">OWS</a> ";" [ <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">expect-param</a> ] ) 2240 <a href="#header.expect" class="smpl">expect-param</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] 2241 2242 <a href="#header.expect" class="smpl">expect-name</a> = <a href="#core.rules" class="smpl">token</a> 2243 <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> 2244 </pre><p id="rfc.section.9.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 2245 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417. 2246 </p> 2247 <p id="rfc.section.9.3.p.4">The only expectation defined by this specification is:</p> 2248 <p id="rfc.section.9.3.p.5"><span id="rfc.iref.93"></span><span id="rfc.iref.e.2"></span> 100-continue 2249 </p> 2250 <ul class="empty"> 2251 <li>The "100-continue" expectation is defined <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.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2252 </li> 2253 </ul> 2254 <p id="rfc.section.9.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 2255 <p id="rfc.section.9.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header 2256 field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 2257 </p> 2258 <p id="rfc.section.9.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2256 2259 <div id="rfc.iref.f.1"></div> 2257 2260 <div id="rfc.iref.h.5"></div> … … 2259 2262 <p id="rfc.section.9.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2260 2263 </p> 2261 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.2 8"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a>2264 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a> 2262 2265 2263 2266 <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>> … … 2286 2289 <p id="rfc.section.9.5.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). 2287 2290 </p> 2288 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g. 29"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>2291 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 2289 2292 </pre><div id="rfc.figure.u.24"></div> 2290 2293 <p>Examples are:</p> <pre class="text"> Location: http://www.example.org/pub/WWW/People.html#tim … … 2310 2313 to trace a request which appears to be failing or looping in mid-chain. 2311 2314 </p> 2312 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.3 0"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2315 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2313 2316 </pre><p id="rfc.section.9.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 2314 2317 <p id="rfc.section.9.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). … … 2330 2333 non-HTTP URIs (e.g., FTP). 2331 2334 </p> 2332 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.3 1"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>2335 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 2333 2336 </pre><p id="rfc.section.9.7.p.5">Example:</p> 2334 2337 <div id="rfc.figure.u.28"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html … … 2343 2346 </p> 2344 2347 <p id="rfc.section.9.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p> 2345 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.3 2"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>2348 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 2346 2349 </pre><div id="rule.delta-seconds"> 2347 2350 <p id="rfc.section.9.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 2348 2351 </div> 2349 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.3 3"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2352 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2350 2353 </pre><p id="rfc.section.9.8.p.6">Two examples of its use are</p> 2351 2354 <div id="rfc.figure.u.31"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT … … 2356 2359 <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> 2357 2360 <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> 2358 <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 8"><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 for2361 <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.39"><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.40"><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 2359 2362 identifying the application. 2360 2363 </p> 2361 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.3 4"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2364 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2362 2365 </pre><p id="rfc.section.9.9.p.4">Example:</p> 2363 2366 <div id="rfc.figure.u.33"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2364 </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.4 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2367 </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.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2365 2368 </p> 2366 2369 <div class="note" id="rfc.section.9.9.p.7"> … … 2378 2381 user agent limitations. 2379 2382 </p> 2380 <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 1"><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 significance2383 <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.42"><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.43"><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 2381 2384 for identifying the application. 2382 2385 </p> … … 2389 2392 doing so makes the field value more difficult to parse. 2390 2393 </p> 2391 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.3 5"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2394 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2392 2395 </pre><p id="rfc.section.9.10.p.7">Example:</p> 2393 2396 <div id="rfc.figure.u.35"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 … … 2850 2853 </p> 2851 2854 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2852 <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 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2855 <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.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2853 2856 </p> 2854 2857 <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References … … 3010 3013 </p> 3011 3014 <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 3012 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 4"><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>)3015 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.45"><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>) 3013 3016 </p> 3014 3017 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3015 3018 <div id="rfc.figure.u.36"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 3019 3020 <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in [Part1], Section 1.2.2> 3016 3021 3017 3022 <a href="#header.date" class="smpl">Date</a> = HTTP-date … … 3068 3073 <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*DIGIT 3069 3074 3070 <a href="#header.expect" class="smpl">expect-param</a> = token [ "=" ( token / quoted-string ) ] 3071 <a href="#header.expect" class="smpl">expectation</a> = "100-continue" / expectation-extension 3072 <a href="#header.expect" class="smpl">expectation-extension</a> = token [ "=" ( token / quoted-string ) *( ";" 3073 expect-param ) ] 3075 <a href="#header.expect" class="smpl">expect-name</a> = token 3076 <a href="#header.expect" class="smpl">expect-param</a> = expect-name [ BWS "=" BWS expect-value ] 3077 <a href="#header.expect" class="smpl">expect-value</a> = token / quoted-string 3078 <a href="#header.expect" class="smpl">expectation</a> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ 3079 OWS expect-param ] ) 3074 3080 3075 3081 <a href="#preferred.date.format" class="smpl">hour</a> = 2DIGIT … … 3406 3412 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/312">http://tools.ietf.org/wg/httpbis/trac/ticket/312</a>>: "should there be a permanent variant of 307" 3407 3413 </li> 3414 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/327">http://tools.ietf.org/wg/httpbis/trac/ticket/327</a>>: "'expect' grammar missing OWS" 3415 </li> 3408 3416 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/329">http://tools.ietf.org/wg/httpbis/trac/ticket/329</a>>: "header field considerations: quoted-string vs use of double quotes" 3409 3417 </li> … … 3416 3424 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 3417 3425 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">10.2</a></li> 3426 <li>100-continue (expect value) <a href="#rfc.iref.93"><b>9.3</b></a></li> 3418 3427 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">10.2</a></li> 3419 3428 </ul> … … 3486 3495 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3487 3496 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.e.1"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a></li> 3497 <li>Expect Values 3498 <ul> 3499 <li>100-continue <a href="#rfc.iref.e.2"><b>9.3</b></a></li> 3500 </ul> 3501 </li> 3488 3502 </ul> 3489 3503 </li> … … 3503 3517 <li><tt>day-name</tt> <a href="#rfc.iref.g.13"><b>8</b></a></li> 3504 3518 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.14"><b>8</b></a></li> 3505 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.3 3"><b>9.8</b></a></li>3519 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.34"><b>9.8</b></a></li> 3506 3520 <li><tt>Expect</tt> <a href="#rfc.iref.g.24"><b>9.3</b></a></li> 3507 <li><tt>expect-param</tt> <a href="#rfc.iref.g.27"><b>9.3</b></a></li> 3521 <li><tt>expect-name</tt> <a href="#rfc.iref.g.28"><b>9.3</b></a></li> 3522 <li><tt>expect-param</tt> <a href="#rfc.iref.g.26"><b>9.3</b></a></li> 3523 <li><tt>expect-value</tt> <a href="#rfc.iref.g.27"><b>9.3</b></a></li> 3508 3524 <li><tt>expectation</tt> <a href="#rfc.iref.g.25"><b>9.3</b></a></li> 3509 <li><tt>expectation-extension</tt> <a href="#rfc.iref.g.26"><b>9.3</b></a></li>3510 3525 <li><tt>extension-code</tt> <a href="#rfc.iref.g.3"><b>4</b></a></li> 3511 <li><tt>From</tt> <a href="#rfc.iref.g.2 8"><b>9.4</b></a></li>3526 <li><tt>From</tt> <a href="#rfc.iref.g.29"><b>9.4</b></a></li> 3512 3527 <li><tt>GMT</tt> <a href="#rfc.iref.g.18"><b>8</b></a></li> 3513 3528 <li><tt>hour</tt> <a href="#rfc.iref.g.10"><b>8</b></a></li> 3514 3529 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.6"><b>8</b></a></li> 3515 <li><tt>Location</tt> <a href="#rfc.iref.g. 29"><b>9.5</b></a></li>3516 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.3 0"><b>9.6</b></a></li>3530 <li><tt>Location</tt> <a href="#rfc.iref.g.30"><b>9.5</b></a></li> 3531 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.31"><b>9.6</b></a></li> 3517 3532 <li><tt>Method</tt> <a href="#rfc.iref.g.1"><b>2</b></a></li> 3518 3533 <li><tt>minute</tt> <a href="#rfc.iref.g.11"><b>8</b></a></li> … … 3520 3535 <li><tt>obs-date</tt> <a href="#rfc.iref.g.19"><b>8</b></a></li> 3521 3536 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.4"><b>4</b></a></li> 3522 <li><tt>Referer</tt> <a href="#rfc.iref.g.3 1"><b>9.7</b></a></li>3523 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.3 2"><b>9.8</b></a></li>3537 <li><tt>Referer</tt> <a href="#rfc.iref.g.32"><b>9.7</b></a></li> 3538 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.33"><b>9.8</b></a></li> 3524 3539 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.7"><b>8</b></a></li> 3525 3540 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.20"><b>8</b></a></li> 3526 3541 <li><tt>second</tt> <a href="#rfc.iref.g.12"><b>8</b></a></li> 3527 <li><tt>Server</tt> <a href="#rfc.iref.g.3 4"><b>9.9</b></a></li>3542 <li><tt>Server</tt> <a href="#rfc.iref.g.35"><b>9.9</b></a></li> 3528 3543 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.2"><b>4</b></a></li> 3529 3544 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.9"><b>8</b></a></li> 3530 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.3 5"><b>9.10</b></a></li>3545 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.36"><b>9.10</b></a></li> 3531 3546 <li><tt>year</tt> <a href="#rfc.iref.g.17"><b>8</b></a></li> 3532 3547 </ul> … … 3581 3596 </li> 3582 3597 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3583 <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>3598 <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.1</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">1.2.2</a>, <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.18">3</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.1</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.28">5.1</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.8</a>, <a href="#rfc.xref.Part1.31">6.9</a>, <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.2.4</a>, <a href="#rfc.xref.Part1.35">7.2.6</a>, <a href="#rfc.xref.Part1.36">7.4.19</a>, <a href="#rfc.xref.Part1.37">7.5.6</a>, <a href="#rfc.xref.Part1.38">9.3</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.9</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">9.10</a>, <a href="#rfc.xref.Part1.44">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.45">A</a><ul> 3584 3599 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 3585 <li><em>Section 1.2.1</em> <a href="#rfc.xref.Part1.1 8">3.1</a></li>3586 <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>3600 <li><em>Section 1.2.1</em> <a href="#rfc.xref.Part1.19">3.1</a></li> 3601 <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>, <a href="#rfc.xref.Part1.8">1.2.1</a></li> 3587 3602 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 3588 <li><em>Section 2.4</em> <a href="#rfc.xref.Part1.3 3">7.2.4</a></li>3589 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.3 6">7.5.6</a></li>3590 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.1 0">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>3591 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.3 0">6.9</a></li>3592 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.1 1">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>3593 <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>3594 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.1 6">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li>3595 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.1 5">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li>3596 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part1.2 2">3.1</a></li>3597 <li><em>Section 5.2</em> <a href="#rfc.xref.Part1.1 3">1.2.2</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a></li>3598 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.3 1">7.1.1</a>, <a href="#rfc.xref.Part1.37">9.3</a></li>3599 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.2 1">3.1</a></li>3600 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.2 3">3.2</a></li>3601 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.2 4">3.2</a></li>3602 <li><em>Section 8.7</em> <a href="#rfc.xref.Part1.3 2">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.19</a></li>3603 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.2 8">6.8</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.44">A</a></li>3604 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1. 29">6.8</a></li>3605 <li><em>Section 11</em> <a href="#rfc.xref.Part1.4 3">12</a></li>3603 <li><em>Section 2.4</em> <a href="#rfc.xref.Part1.34">7.2.4</a></li> 3604 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.37">7.5.6</a></li> 3605 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.15">1.2.2</a></li> 3606 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.31">6.9</a></li> 3607 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.43">9.10</a></li> 3608 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.20">3.1</a></li> 3609 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.35">7.2.6</a></li> 3610 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.28">5.1</a></li> 3611 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part1.23">3.1</a></li> 3612 <li><em>Section 5.2</em> <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a></li> 3613 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.38">9.3</a></li> 3614 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3615 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3616 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.25">3.2</a></li> 3617 <li><em>Section 8.7</em> <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.19</a></li> 3618 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.41">9.9</a>, <a href="#rfc.xref.Part1.45">A</a></li> 3619 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.30">6.8</a></li> 3620 <li><em>Section 11</em> <a href="#rfc.xref.Part1.44">12</a></li> 3606 3621 </ul> 3607 3622 </li>
Note: See TracChangeset
for help on using the changeset viewer.