Changeset 1785 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 15/07/12 08:24:07 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1780 r1785 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 5, 2013";451 content: "Expires January 16, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 4">493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-15"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 496 <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 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to historic status, along with its predecessor RFC 2068. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817 (on using CONNECT for TLS upgrades) and moves them to historic status.">497 <meta name="description" 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 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to historic status, along with its predecessor RFC 2068. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817 (on using CONNECT for TLS upgrades) and moves them to historic status.">496 <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 provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations."> 497 <meta name="description" 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 provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations."> 498 498 </head> 499 499 <body onload="init();"> … … 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: January 1 5, 2013</td>525 <td class="left">Expires: January 16, 2013</td> 526 526 <td class="right">greenbytes</td> 527 527 </tr> 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">July 1 4, 2012</td>530 <td class="right">July 15, 2012</td> 531 531 </tr> 532 532 </tbody> … … 535 535 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 536 536 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information 537 systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the 538 seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> and moves it to historic status, along with its predecessor <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.1">RFC 2068</cite>. 539 </p> 540 <p>Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier 541 (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general 542 security concerns for implementations. 543 </p> 544 <p>This part also obsoletes RFCs <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">2145</cite> (on HTTP version numbers) and <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">2817</cite> (on using CONNECT for TLS upgrades) and moves them to historic status. 537 systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview 538 of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, 539 defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations. 545 540 </p> 546 541 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> … … 560 555 in progress”. 561 556 </p> 562 <p>This Internet-Draft will expire on January 1 5, 2013.</p>557 <p>This Internet-Draft will expire on January 16, 2013.</p> 563 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 564 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 745 740 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 746 741 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and 747 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 748 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the differences between HTTP and MIME messages). 749 </p> 750 <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented 742 MIME-like message payloads for flexible interaction with network-based hypertext information systems. This document is the 743 first in a series of documents that collectively form the HTTP/1.1 specification: 744 </p> 745 <ul class="empty"> 746 <li>RFC xxx1: URIs, Connections, and Message Parsing</li> 747 <li><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation" id="rfc.xref.Part2.1">RFC xxx2</cite>: Core Semantics 748 </li> 749 <li><cite title="HTTP/1.1, part 4: Conditional Requests" id="rfc.xref.Part4.1">RFC xxx4</cite>: Conditional Requests 750 </li> 751 <li><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses" id="rfc.xref.Part5.1">RFC xxx5</cite>: Range Requests 752 </li> 753 <li><cite title="HTTP/1.1, part 6: Caching" id="rfc.xref.Part6.1">RFC xxx6</cite>: Caching 754 </li> 755 <li><cite title="HTTP/1.1, part 7: Authentication" id="rfc.xref.Part7.1">RFC xxx7</cite>: Authentication 756 </li> 757 </ul> 758 <p id="rfc.section.1.p.2">This HTTP/1,1 specification obsoletes and moves to historic status <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite>, its predecessor <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.1">RFC 2068</cite>, <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">RFC 2145</cite> (on HTTP versioning), and <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">2817</cite> (on using CONNECT for TLS upgrades). 759 </p> 760 <p id="rfc.section.1.p.3">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented 751 761 by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do 752 762 not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated … … 754 764 effectively in many different contexts and for which implementations can evolve independently over time. 755 765 </p> 756 <p id="rfc.section.1.p. 3">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information766 <p id="rfc.section.1.p.4">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information 757 767 systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols 758 768 into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services. 759 769 </p> 760 <p id="rfc.section.1.p. 4">One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead,770 <p id="rfc.section.1.p.5">One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, 761 771 we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of 762 772 recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding … … 764 774 at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response. 765 775 </p> 766 <p id="rfc.section.1.p. 5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1", obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Part 1 describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes,767 describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements.776 <p id="rfc.section.1.p.6">This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI 777 schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. 768 778 Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, 769 779 thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries. … … 816 826 "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message. 817 827 </p> 818 <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In 828 <p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the differences between HTTP and MIME messages). 829 </p> 830 <p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In 819 831 the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and 820 832 the origin server (O). … … 826 838 <div id="rfc.iref.r.2"></div> 827 839 <div id="rfc.iref.r.3"></div> 828 <p id="rfc.section.2.1.p.5">A client sends an HTTP request to a server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request Line">Section 3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and representation metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 829 </p> 830 <p id="rfc.section.2.1.p.6">A server responds to a client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason 831 phrase (<a href="#status.line" title="Status Line">Section 3.1.2</a>), possibly followed by MIME-like header fields containing server information, resource metadata, and representation metadata 832 (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 833 </p> 834 <p id="rfc.section.2.1.p.7">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 840 <p id="rfc.section.2.1.p.6">A client sends an HTTP request to a server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request Line">Section 3.1.1</a>), followed by header fields containing request modifiers, client information, and representation metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 841 </p> 842 <p id="rfc.section.2.1.p.7">A server responds to a client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason 843 phrase (<a href="#status.line" title="Status Line">Section 3.1.2</a>), possibly followed by header fields containing server information, resource metadata, and representation metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 844 </p> 845 <p id="rfc.section.2.1.p.8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 835 846 <div id="rfc.figure.u.2"></div> 836 847 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 … … 911 922 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 912 923 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 913 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2. 2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.924 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 914 925 </p> 915 926 <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying … … 955 966 </pre><p id="rfc.section.2.5.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response 956 967 is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response 957 can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6. 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.968 can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 958 969 </p> 959 970 <p id="rfc.section.2.5.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and … … 1032 1043 is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 1033 1044 to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented 1034 for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616. 3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol.1045 for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol. 1035 1046 </p> 1036 1047 <div id="rfc.iref.r.5"></div> … … 1081 1092 </p> 1082 1093 <p id="rfc.section.2.8.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 1083 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2. 3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.1094 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. 1084 1095 </p> 1085 1096 <p id="rfc.section.2.8.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name … … 1106 1117 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1107 1118 </pre><p id="rfc.section.2.8.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP 1108 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6. 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1119 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1109 1120 </p> 1110 1121 <p id="rfc.section.2.8.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers … … 1179 1190 </div> 1180 1191 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1181 </pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.1192 </pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1182 1193 </p> 1183 1194 <div id="rfc.iref.r.6"></div> … … 1192 1203 </p> 1193 1204 <p id="rfc.section.3.1.1.p.10">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1194 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).1205 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 1195 1206 </p> 1196 1207 <p id="rfc.section.3.1.1.p.11">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets. … … 1205 1216 <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy 1206 1217 the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined 1207 for that status code. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),1218 for that status code. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit), 1208 1219 the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. 1209 1220 </p> … … 1226 1237 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1227 1238 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1228 the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1239 the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1229 1240 </p> 1230 1241 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1234 1245 them. 1235 1246 </p> 1236 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1247 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1237 1248 </p> 1238 1249 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" … … 1417 1428 <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. 1418 1429 </p> 1419 <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1420 </p> 1421 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4. 1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer1430 <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1431 </p> 1432 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer 1422 1433 coding to the message body if the request had been an unconditional GET. This indication is not required, however, because 1423 1434 any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. … … 1439 1450 <div id="rfc.figure.u.36"></div><pre class="text"> Content-Length: 3495 1440 1451 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential 1441 transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4. 2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would1452 transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would 1442 1453 have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. 1443 1454 </p> … … 1534 1545 </p> 1535 1546 <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication needs to be given to the user that 1536 an error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6. 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1547 an error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1537 1548 </p> 1538 1549 <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data … … 1718 1729 </p> 1719 1730 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1720 <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.1 0"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1731 <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1721 1732 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1722 1733 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. … … 1760 1771 </p> 1761 1772 <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which 1762 are defined in <a href="#Part2" id="rfc.xref.Part2.1 1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.8</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order1773 are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.8</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order 1763 1774 to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment 1764 1775 identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). … … 1769 1780 semantics and, if so, where that request is to be directed. 1770 1781 </p> 1771 <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6. 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), then the request is usually directed to the cache first.1782 <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), then the request is usually directed to the cache first. 1772 1783 </p> 1773 1784 <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy … … 1819 1830 </p> 1820 1831 <div id="authority-form"> 1821 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,1832 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example, 1822 1833 </p> 1823 1834 </div> 1824 1835 <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1825 1836 </pre><div id="asterisk-form"> 1826 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1837 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, 1827 1838 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1828 1839 </p> … … 1934 1945 <li>Keep-Alive (<a href="http://tools.ietf.org/html/rfc2068#section-19.7.1.1">Section 19.7.1.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>) 1935 1946 </li> 1936 <li><a href="p7-auth.html#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> (<a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7. 1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>)1937 </li> 1938 <li><a href="p7-auth.html#header.proxy-authorization" class="smpl">Proxy-Authorization</a> (<a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7. 2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>)1947 <li><a href="p7-auth.html#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> (<a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) 1948 </li> 1949 <li><a href="p7-auth.html#header.proxy-authorization" class="smpl">Proxy-Authorization</a> (<a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) 1939 1950 </li> 1940 1951 <li><a href="#header.te" class="smpl">TE</a></li> … … 1953 1964 </p> 1954 1965 <ul> 1955 <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 9.5</a> of <a href="#Part2" id="rfc.xref.Part2.1 4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)1956 </li> 1957 <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 9.8</a> of <a href="#Part2" id="rfc.xref.Part2.1 5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)1958 </li> 1959 <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616. 4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)1960 </li> 1961 <li><a href="p4-conditional.html#header.etag" class="smpl">ETag</a> (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4. 3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>)1962 </li> 1963 <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4. 4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>)1964 </li> 1965 <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 9.17</a> of <a href="#Part2" id="rfc.xref.Part2.1 6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)1966 <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 9.5</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1967 </li> 1968 <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 9.8</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1969 </li> 1970 <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) 1971 </li> 1972 <li><a href="p4-conditional.html#header.etag" class="smpl">ETag</a> (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) 1973 </li> 1974 <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) 1975 </li> 1976 <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 9.17</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1966 1977 </li> 1967 1978 </ul> … … 1969 1980 </p> 1970 1981 <ul> 1971 <li><a href="p6-cache.html#header.expires" class="smpl">Expires</a> (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6. 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)1982 <li><a href="p6-cache.html#header.expires" class="smpl">Expires</a> (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) 1972 1983 </li> 1973 1984 </ul> … … 1977 1988 </p> 1978 1989 <ul> 1979 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.1 7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)1980 </li> 1981 <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5. 1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)1982 </li> 1983 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1 8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)1984 </li> 1985 </ul> 1986 <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6. 7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1990 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1991 </li> 1992 <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) 1993 </li> 1994 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1995 </li> 1996 </ul> 1997 <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1987 1998 </p> 1988 1999 <div class="note" id="rfc.section.5.6.2.p.7"> … … 1991 2002 </p> 1992 2003 </div> 1993 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2. 19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>).2004 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1994 2005 </p> 1995 2006 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 1996 2007 <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1997 2008 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1998 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.2 0"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.2009 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request. 1999 2010 </p> 2000 2011 <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. … … 2020 2031 </p> 2021 2032 <p id="rfc.section.6.1.p.6">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients 2022 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6. 8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).2033 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 2023 2034 </p> 2024 2035 <p id="rfc.section.6.1.p.7">The connection options do not have to correspond to a header field present in the message, since a connection-specific header … … 2141 2152 <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2142 2153 </p> 2143 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2154 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2144 2155 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2145 2156 </p> … … 2171 2182 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2172 2183 <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2173 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding2184 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2174 2185 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 2175 2186 </p> … … 2184 2195 </p> 2185 2196 <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2186 <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.2 3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2197 <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2187 2198 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2188 2199 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2191 2202 <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> 2192 2203 <ul> 2193 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.2 4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation.2204 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation. 2194 2205 </li> 2195 2206 <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body. … … 2229 2240 <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. 2230 2241 </li> 2231 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.2 5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).2242 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2232 2243 </li> 2233 2244 </ul> … … 2266 2277 </p> 2267 2278 <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2268 is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.2 6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).2279 is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2269 2280 </p> 2270 2281 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching … … 2530 2541 <li>Pointer to specification text</li> 2531 2542 </ul> 2532 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.2 7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2543 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2533 2544 </p> 2534 2545 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. … … 2689 2700 that most implementations will choose substantially higher limits. 2690 2701 </p> 2691 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.2 8"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).2702 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2692 2703 </p> 2693 2704 <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. 2694 2705 </p> 2695 2706 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2696 <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.6">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145. 3">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.5">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari2707 <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.6">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari 2697 2708 Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Mark Nottingham. 2698 See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616. 6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions.2709 See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions. 2699 2710 </p> 2700 2711 <p id="rfc.section.9.p.2">Since 1999, the following contributors have helped improve the HTTP specification by reporting bugs, asking smart questions, … … 3161 3172 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> Since RFC 2616 3162 3173 </h2> 3163 <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616. 7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.3174 <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 3164 3175 </p> 3165 3176 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> Since draft-ietf-httpbis-p1-messaging-00 … … 3759 3770 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3760 3771 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3761 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2. 4</a>, <a href="#rfc.xref.Part2.3">2.8.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.6.2</a>, <a href="#rfc.xref.Part2.19">5.6.2</a>, <a href="#rfc.xref.Part2.20">5.7</a>, <a href="#rfc.xref.Part2.21">6.3.2.2</a>, <a href="#rfc.xref.Part2.22">6.3.4</a>, <a href="#rfc.xref.Part2.23">6.4.3</a>, <a href="#rfc.xref.Part2.24">6.4.3</a>, <a href="#rfc.xref.Part2.25">6.4.3</a>, <a href="#rfc.xref.Part2.26">6.5</a>, <a href="#rfc.xref.Part2.27">7.4</a>, <a href="#rfc.xref.Part2.28">8.6</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3762 <li><em>Section 2</em> <a href="#rfc.xref.Part2. 4">3.1.1</a></li>3763 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.2 1">6.3.2.2</a>, <a href="#rfc.xref.Part2.22">6.3.4</a></li>3764 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.1 3">5.3</a></li>3765 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.1 2">5.3</a></li>3766 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2. 8">3.2</a></li>3767 <li><em>Section 4</em> <a href="#rfc.xref.Part2. 3">2.8.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li>3768 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.2 0">5.7</a>, <a href="#rfc.xref.Part2.25">6.4.3</a></li>3769 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.2 3">6.4.3</a></li>3770 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2. 2">2.4</a></li>3771 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.2 6">6.5</a></li>3772 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2. 29">8.6</a></li>3773 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2. 5">3.1.1</a>, <a href="#rfc.xref.Part2.28">8.6</a></li>3774 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2. 9">3.3.1</a>, <a href="#rfc.xref.Part2.27">7.4</a></li>3775 <li><em>Section 8</em> <a href="#rfc.xref.Part2.1 0">4.3.1</a></li>3776 <li><em>Section 9.5</em> <a href="#rfc.xref.Part2.1 4">5.6.2</a></li>3777 <li><em>Section 9.6</em> <a href="#rfc.xref.Part2.1 7">5.6.2</a></li>3778 <li><em>Section 9.8</em> <a href="#rfc.xref.Part2.1 5">5.6.2</a></li>3779 <li><em>Section 9.9</em> <a href="#rfc.xref.Part2.1 8">5.6.2</a></li>3780 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2. 7">3.2</a></li>3781 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.2 4">6.4.3</a></li>3782 <li><em>Section 9.17</em> <a href="#rfc.xref.Part2.1 6">5.6.2</a></li>3783 <li><em>Appendix A</em> <a href="#rfc.xref.Part2. 1">1</a></li>3772 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.4</a>, <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3.1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.6.2</a>, <a href="#rfc.xref.Part2.19">5.6.2</a>, <a href="#rfc.xref.Part2.20">5.6.2</a>, <a href="#rfc.xref.Part2.21">5.7</a>, <a href="#rfc.xref.Part2.22">6.3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</a>, <a href="#rfc.xref.Part2.24">6.4.3</a>, <a href="#rfc.xref.Part2.25">6.4.3</a>, <a href="#rfc.xref.Part2.26">6.4.3</a>, <a href="#rfc.xref.Part2.27">6.5</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3773 <li><em>Section 2</em> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3774 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.22">6.3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</a></li> 3775 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3776 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3777 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3778 <li><em>Section 4</em> <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li> 3779 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.21">5.7</a>, <a href="#rfc.xref.Part2.26">6.4.3</a></li> 3780 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.24">6.4.3</a></li> 3781 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.3">2.4</a></li> 3782 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.27">6.5</a></li> 3783 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.30">8.6</a></li> 3784 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.29">8.6</a></li> 3785 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.28">7.4</a></li> 3786 <li><em>Section 8</em> <a href="#rfc.xref.Part2.11">4.3.1</a></li> 3787 <li><em>Section 9.5</em> <a href="#rfc.xref.Part2.15">5.6.2</a></li> 3788 <li><em>Section 9.6</em> <a href="#rfc.xref.Part2.18">5.6.2</a></li> 3789 <li><em>Section 9.8</em> <a href="#rfc.xref.Part2.16">5.6.2</a></li> 3790 <li><em>Section 9.9</em> <a href="#rfc.xref.Part2.19">5.6.2</a></li> 3791 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3792 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.25">6.4.3</a></li> 3793 <li><em>Section 9.17</em> <a href="#rfc.xref.Part2.17">5.6.2</a></li> 3794 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3784 3795 </ul> 3785 3796 </li> 3786 <li><em>Part4</em> <a href="#rfc.xref.Part4.1"> 3.3.1</a>, <a href="#rfc.xref.Part4.2">3.3.2</a>, <a href="#rfc.xref.Part4.3">5.6.2</a>, <a href="#rfc.xref.Part4.4">5.6.2</a>, <a href="#Part4"><b>10.1</b></a><ul>3787 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4. 4">5.6.2</a></li>3788 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4. 3">5.6.2</a></li>3789 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4. 1">3.3.1</a>, <a href="#rfc.xref.Part4.2">3.3.2</a></li>3797 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.6.2</a>, <a href="#rfc.xref.Part4.5">5.6.2</a>, <a href="#Part4"><b>10.1</b></a><ul> 3798 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.5">5.6.2</a></li> 3799 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.4">5.6.2</a></li> 3800 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li> 3790 3801 </ul> 3791 3802 </li> 3792 <li><em>Part5</em> <a href="#rfc.xref.Part5.1"> 5.6.2</a>, <a href="#Part5"><b>10.1</b></a><ul>3793 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5. 1">5.6.2</a></li>3803 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.6.2</a>, <a href="#Part5"><b>10.1</b></a><ul> 3804 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.2">5.6.2</a></li> 3794 3805 </ul> 3795 3806 </li> 3796 <li><em>Part6</em> <a href="#rfc.xref.Part6.1"> 2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.8.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">5.6.2</a>, <a href="#rfc.xref.Part6.8">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>3797 <li><em>Section 2</em> <a href="#rfc.xref.Part6. 2">2.5</a></li>3798 <li><em>Section 3</em> <a href="#rfc.xref.Part6. 4">3.4</a></li>3799 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6. 3">2.8.2</a>, <a href="#rfc.xref.Part6.8">6.1</a></li>3800 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6. 6">5.6.2</a></li>3801 <li><em>Section 7.6</em> <a href="#rfc.xref.Part6. 1">2.4</a>, <a href="#rfc.xref.Part6.7">5.6.2</a></li>3807 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.5</a>, <a href="#rfc.xref.Part6.4">2.8.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.6.2</a>, <a href="#rfc.xref.Part6.8">5.6.2</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul> 3808 <li><em>Section 2</em> <a href="#rfc.xref.Part6.3">2.5</a></li> 3809 <li><em>Section 3</em> <a href="#rfc.xref.Part6.5">3.4</a></li> 3810 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.4">2.8.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li> 3811 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.7">5.6.2</a></li> 3812 <li><em>Section 7.6</em> <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.8">5.6.2</a></li> 3802 3813 </ul> 3803 3814 </li> 3804 <li><em>Part7</em> <a href="#rfc.xref.Part7.1"> 5.6.1</a>, <a href="#rfc.xref.Part7.2">5.6.1</a>, <a href="#Part7"><b>10.1</b></a><ul>3805 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7. 1">5.6.1</a></li>3806 <li><em>Section 4.3</em> <a href="#rfc.xref.Part7. 2">5.6.1</a></li>3815 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">1</a>, <a href="#rfc.xref.Part7.2">5.6.1</a>, <a href="#rfc.xref.Part7.3">5.6.1</a>, <a href="#Part7"><b>10.1</b></a><ul> 3816 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.2">5.6.1</a></li> 3817 <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.3">5.6.1</a></li> 3807 3818 </ul> 3808 3819 </li> … … 3822 3833 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.5</a>, <a href="#RFC1951"><b>10.1</b></a></li> 3823 3834 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">7.5</a>, <a href="#RFC1952"><b>10.1</b></a></li> 3824 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1"> 1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>10.2</b></a><ul>3835 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">2.1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>10.2</b></a><ul> 3825 3836 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">3.3.1</a></li> 3826 3837 </ul> 3827 3838 </li> 3828 3839 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3829 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1"> §</a>, <a href="#rfc.xref.RFC2068.2">2.7</a>, <a href="#rfc.xref.RFC2068.3">5.6.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">6.4.3</a>, <a href="#rfc.xref.RFC2068.6">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a><ul>3840 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.7</a>, <a href="#rfc.xref.RFC2068.3">5.6.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">6.4.3</a>, <a href="#rfc.xref.RFC2068.6">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a><ul> 3830 3841 <li><em>Section 19.7.1.1</em> <a href="#rfc.xref.RFC2068.3">5.6.1</a></li> 3831 3842 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a></li> … … 3833 3844 </li> 3834 3845 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 3835 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1"> §</a>, <a href="#rfc.xref.RFC2145.2">1</a>, <a href="#rfc.xref.RFC2145.3">9</a>, <a href="#RFC2145"><b>10.2</b></a></li>3836 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1"> §</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2.7</a>, <a href="#rfc.xref.RFC2616.4">5.6.2</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#rfc.xref.RFC2616.6">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.7">C.1</a><ul>3837 <li><em>Section 14.15</em> <a href="#rfc.xref.RFC2616. 4">5.6.2</a></li>3838 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616. 6">9</a></li>3846 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">1</a>, <a href="#rfc.xref.RFC2145.2">9</a>, <a href="#RFC2145"><b>10.2</b></a></li> 3847 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.7</a>, <a href="#rfc.xref.RFC2616.3">5.6.2</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">C.1</a><ul> 3848 <li><em>Section 14.15</em> <a href="#rfc.xref.RFC2616.3">5.6.2</a></li> 3849 <li><em>Section 16</em> <a href="#rfc.xref.RFC2616.5">9</a></li> 3839 3850 </ul> 3840 3851 </li> 3841 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1"> §</a>, <a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a>, <a href="#rfc.xref.RFC2817.4">A.2</a><ul>3852 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">1</a>, <a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a>, <a href="#rfc.xref.RFC2817.4">A.2</a><ul> 3842 3853 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#rfc.xref.RFC2817.4">A.2</a></li> 3843 3854 </ul> … … 3847 3858 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>10.2</b></a></li> 3848 3859 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">7.1</a>, <a href="#RFC3864"><b>10.2</b></a></li> 3849 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1"> 1</a>, <a href="#rfc.xref.RFC3986.2">2.8</a>, <a href="#rfc.xref.RFC3986.3">2.8</a>, <a href="#rfc.xref.RFC3986.4">2.8</a>, <a href="#rfc.xref.RFC3986.5">2.8</a>, <a href="#rfc.xref.RFC3986.6">2.8</a>, <a href="#rfc.xref.RFC3986.7">2.8</a>, <a href="#rfc.xref.RFC3986.8">2.8</a>, <a href="#rfc.xref.RFC3986.9">2.8</a>, <a href="#rfc.xref.RFC3986.10">2.8</a>, <a href="#rfc.xref.RFC3986.11">2.8</a>, <a href="#rfc.xref.RFC3986.12">2.8</a>, <a href="#rfc.xref.RFC3986.13">2.8</a>, <a href="#rfc.xref.RFC3986.14">2.8.1</a>, <a href="#rfc.xref.RFC3986.15">2.8.1</a>, <a href="#rfc.xref.RFC3986.16">2.8.3</a>, <a href="#rfc.xref.RFC3986.17">2.8.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul>3860 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">2.1</a>, <a href="#rfc.xref.RFC3986.2">2.8</a>, <a href="#rfc.xref.RFC3986.3">2.8</a>, <a href="#rfc.xref.RFC3986.4">2.8</a>, <a href="#rfc.xref.RFC3986.5">2.8</a>, <a href="#rfc.xref.RFC3986.6">2.8</a>, <a href="#rfc.xref.RFC3986.7">2.8</a>, <a href="#rfc.xref.RFC3986.8">2.8</a>, <a href="#rfc.xref.RFC3986.9">2.8</a>, <a href="#rfc.xref.RFC3986.10">2.8</a>, <a href="#rfc.xref.RFC3986.11">2.8</a>, <a href="#rfc.xref.RFC3986.12">2.8</a>, <a href="#rfc.xref.RFC3986.13">2.8</a>, <a href="#rfc.xref.RFC3986.14">2.8.1</a>, <a href="#rfc.xref.RFC3986.15">2.8.1</a>, <a href="#rfc.xref.RFC3986.16">2.8.3</a>, <a href="#rfc.xref.RFC3986.17">2.8.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul> 3850 3861 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.17">2.8.3</a></li> 3851 3862 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.8</a></li> … … 3874 3885 </ul> 3875 3886 </li> 3876 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1"> 1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">6.2</a>, <a href="#RFC5322"><b>10.2</b></a><ul>3887 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">6.2</a>, <a href="#RFC5322"><b>10.2</b></a><ul> 3877 3888 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">6.2</a></li> 3878 3889 </ul>
Note: See TracChangeset
for help on using the changeset viewer.