Changeset 374 for draft-ietf-httpbis
- Timestamp:
- 13/11/08 22:27:55 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r372 r374 516 516 <ul class="toc"> 517 517 <li class="tocline0">1. <a href="#introduction">Introduction</a><ul class="toc"> 518 <li class="tocline1">1.1 <a href="#intro.purpose">Purpose</a></li> 519 <li class="tocline1">1.2 <a href="#intro.requirements">Requirements</a></li> 520 <li class="tocline1">1.3 <a href="#intro.overall.operation">Overall Operation</a></li> 518 <li class="tocline1">1.1 <a href="#intro.requirements">Requirements</a></li> 519 <li class="tocline1">1.2 <a href="#intro.overall.operation">Overall Operation</a></li> 521 520 </ul> 522 521 </li> … … 530 529 <li class="tocline1">3.1 <a href="#http.version">HTTP Version</a></li> 531 530 <li class="tocline1">3.2 <a href="#uri">Uniform Resource Identifiers</a><ul class="toc"> 532 <li class="tocline1">3.2.1 <a href="#general.syntax">General Syntax</a></li> 533 <li class="tocline1">3.2.2 <a href="#http.url">http URL</a></li> 534 <li class="tocline1">3.2.3 <a href="#uri.comparison">URI Comparison</a></li> 531 <li class="tocline1">3.2.1 <a href="#http.uri">http URI scheme</a></li> 532 <li class="tocline1">3.2.2 <a href="#uri.comparison">URI Comparison</a></li> 535 533 </ul> 536 534 </li> … … 658 656 </ul> 659 657 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 660 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information 661 systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, commonly 662 referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet with only a single method and no 663 metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metadata about the data 664 transferred and modifiers on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration 665 the effects of hierarchical proxies, caching, the need for persistent connections, or name-based virtual hosts. In addition, 666 the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" necessitated a protocol version change 667 in order for two communicating applications to determine each other's true capabilities. 668 </p> 669 <p id="rfc.section.1.p.2">This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1", obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations 670 and adding only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating 671 with a party advertising compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1 related to overall network operation, 672 message framing, interaction with transport protocols, and URI schemes. 673 </p> 674 <p id="rfc.section.1.p.3">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller 675 errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections will 676 be organized according to the typical process of deciding when to use HTTP (URI schemes), overall network operation, connection 677 management, message framing, and generic message parsing. The current mess reflects how widely dispersed these topics and 678 associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 679 </p> 680 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.purpose" href="#intro.purpose">Purpose</a></h2> 681 <p id="rfc.section.1.1.p.1">Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. 682 HTTP allows an open-ended set of methods and headers that indicate the purpose of a request <a href="#RFC2324" id="rfc.xref.RFC2324.1"><cite title="Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)">[RFC2324]</cite></a>. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) <a href="#RFC1630" id="rfc.xref.RFC1630.1"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</cite></a>, as a location (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.1"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> or name (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.1"><cite title="Functional Requirements for Uniform Resource Names">[RFC1737]</cite></a>, for indicating the resource to which a method is to be applied. Messages are passed in a format similar to that used by 683 Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> as defined by 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>. 684 </p> 685 <p id="rfc.section.1.1.p.2">HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, 686 including those supported by the SMTP <a href="#RFC2821" id="rfc.xref.RFC2821.1"><cite title="Simple Mail Transfer Protocol">[RFC2821]</cite></a>, NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications. 687 </p> 688 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> 689 <p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 658 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and 659 MIME-like message payloads for flexible interaction with network-based hypermedia information systems. HTTP relies upon the 660 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 resource targets for interaction and to identify other resources. Messages are passed in a format similar to that 661 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="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). 662 </p> 663 <p id="rfc.section.1.p.2">HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems, 664 such as USENET news services via NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, file services via FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a>. HTTP proxies and gateways provide access to alternative information services by translating their diverse protocols into 665 a hypermedia format that can be viewed and manipulated by clients in the same way as HTTP services. 666 </p> 667 <p id="rfc.section.1.p.3">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 defines how clients determine when to use HTTP, the URI schemes specific to HTTP-based resources, overall network 668 operation with transport protocol connection management, and HTTP message framing. Our goal is to define all of the mechanisms 669 necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements 670 for an HTTP message relay or generic message parser. 671 </p> 672 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> 673 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 690 674 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 691 675 </p> 692 <p id="rfc.section.1. 2.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant."693 </p> 694 <h2 id="rfc.section.1. 3"><a href="#rfc.section.1.3">1.3</a> <a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2>695 <p id="rfc.section.1. 3.p.1">HTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol676 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant." 677 </p> 678 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2> 679 <p id="rfc.section.1.2.p.1">HTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol 696 680 version, followed by a MIME-like message containing request modifiers, client information, and possible body content over 697 681 a connection with a server. The server responds with a status line, including the message's protocol version and a success 698 682 or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body 699 content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3. 1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.700 </p> 701 <p id="rfc.section.1. 3.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin683 content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 684 </p> 685 <p id="rfc.section.1.2.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin 702 686 server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin 703 687 server (O). … … 706 690 UA -------------------v------------------- O 707 691 <----------------------- response chain 708 </pre><p id="rfc.section.1. 3.p.4">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three692 </pre><p id="rfc.section.1.2.p.4">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three 709 693 common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its 710 694 absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by … … 717 701 UA -----v----- A -----v----- B -----v----- C -----v----- O 718 702 <------------------------------------- response chain 719 </pre><p id="rfc.section.1. 3.p.6">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response703 </pre><p id="rfc.section.1.2.p.6">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response 720 704 message that travels the whole chain will pass through four separate connections. This distinction is important because some 721 705 HTTP communication options may apply only to the connection with the nearest, non-tunnel neighbor, only to the end-points … … 724 708 to servers other than C, at the same time that it is handling A's request. 725 709 </p> 726 <p id="rfc.section.1. 3.p.7">Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect710 <p id="rfc.section.1.2.p.7">Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect 727 711 of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response 728 712 applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from … … 732 716 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 733 717 <--------- response chain 734 </pre><p id="rfc.section.1. 3.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache718 </pre><p id="rfc.section.1.2.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache 735 719 behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching" title="Introduction">Section 1</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 736 720 </p> 737 <p id="rfc.section.1. 3.p.10">In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with721 <p id="rfc.section.1.2.p.10">In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with 738 722 or deployed across the World Wide Web. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, 739 723 systems that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so … … 743 727 failing that, at least reliable indications of failure. 744 728 </p> 745 <p id="rfc.section.1. 3.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (<<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>>), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,729 <p id="rfc.section.1.2.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (<<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>>), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, 746 730 or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the 747 731 mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside 748 732 the scope of this specification. 749 733 </p> 750 <p id="rfc.section.1. 3.p.12">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may734 <p id="rfc.section.1.2.p.12">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may 751 735 be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>). 752 736 </p> … … 773 757 <div id="rule.CRLF"> 774 758 <p id="rfc.section.2.2.p.2"> HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described 775 in <a href="p3-payload.html#media.types" title="Media Types">Section 3.3</a> of <a href="#Part3" id="rfc.xref.Part3. 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.759 in <a href="p3-payload.html#media.types" title="Media Types">Section 3.3</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 776 760 </p> 777 761 </div> … … 845 829 <div id="rfc.figure.u.12"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">request-header</a> = <request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>> 846 830 <a href="#abnf.dependencies" class="smpl">response-header</a> = <response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a>> 847 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">accept-params</a> = <accept-params, defined in <a href="#Part3" id="rfc.xref.Part3. 3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>>848 <a href="#abnf.dependencies" class="smpl">entity-body</a> = <entity-body, defined in <a href="#Part3" id="rfc.xref.Part3. 4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.body" title="Entity Body">Section 4.2</a>>849 <a href="#abnf.dependencies" class="smpl">entity-header</a> = <entity-header, defined in <a href="#Part3" id="rfc.xref.Part3. 5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>>831 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">accept-params</a> = <accept-params, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> 832 <a href="#abnf.dependencies" class="smpl">entity-body</a> = <entity-body, defined in <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.body" title="Entity Body">Section 4.2</a>> 833 <a href="#abnf.dependencies" class="smpl">entity-header</a> = <entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>> 850 834 </pre><div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>> 851 835 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>> … … 884 868 </dl> 885 869 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 886 <p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[RFC1737]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, 887 or any other characteristic--a resource. 888 </p> 889 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="general.syntax" href="#general.syntax">General Syntax</a></h3> 890 <p id="rfc.section.3.2.1.p.1">URIs in HTTP can be represented in absolute form or relative to some known base URI <a href="#RFC1808" id="rfc.xref.RFC1808.1"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>, depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with 891 a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers 892 (URI): Generic Syntax and Semantics," <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port", "host", 893 "abs_path", "query", and "authority" from that specification: 894 </p> 895 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span> <a href="#general.syntax" class="smpl">absoluteURI</a> = <absoluteURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3">Section 3</a>> 896 <a href="#general.syntax" class="smpl">authority</a> = <authority, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.3"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2">Section 3.2</a>> 897 <a href="#general.syntax" class="smpl">fragment</a> = <fragment, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.4"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-4.1">Section 4.1</a>> 898 <a href="#general.syntax" class="smpl">path-absolute</a> = <abs_path, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.5"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3">Section 3</a>> 899 <a href="#general.syntax" class="smpl">port</a> = <port, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.6"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2.2">Section 3.2.2</a>> 900 <a href="#general.syntax" class="smpl">query</a> = <query, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.7"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.4">Section 3.4</a>> 901 <a href="#general.syntax" class="smpl">relativeURI</a> = <relativeURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.8"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-5">Section 5</a>> 902 <a href="#general.syntax" class="smpl">uri-host</a> = <host, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.9"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2.2">Section 3.2.2</a>> 903 </pre><p id="rfc.section.3.2.1.p.3">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 904 </p> 905 <p id="rfc.section.3.2.1.p.4"> </p> 870 <p id="rfc.section.3.2.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used in HTTP to indicate the target of a request and to identify additional resources related to that resource, the request, 871 or the response. Each protocol element in HTTP that allows a URI reference will indicate in its ABNF whether the element allows 872 only a URI in absolute form, any relative reference, or some limited subset of the URI-reference grammar. Unless otherwise 873 indicated, relative URI references are to be parsed relative to the URI corresponding to the request target (the base URI). 874 </p> 875 <p id="rfc.section.3.2.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port", "host", "path-abempty", 876 "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>: 877 </p> 878 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>> 879 <a href="#uri" class="smpl">authority</a> = <authority, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2">Section 3.2</a>> 880 <a href="#uri" class="smpl">fragment</a> = <fragment, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><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>> 881 <a href="#uri" class="smpl">path-abempty</a> = <path-abempty, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> 882 <a href="#uri" class="smpl">path-absolute</a> = <path-absolute, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.8"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> 883 <a href="#uri" class="smpl">port</a> = <port, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.3">Section 3.2.3</a>> 884 <a href="#uri" class="smpl">query</a> = <query, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.4">Section 3.4</a>> 885 <a href="#uri" class="smpl">uri-host</a> = <host, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.11"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>> 886 887 <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.12"><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>> 888 <a href="#uri" class="smpl">relativeURI</a> = <a href="#uri" class="smpl">relative-part</a> [ "?" <a href="#uri" class="smpl">query</a> ] 889 </pre><p id="rfc.section.3.2.p.4">HTTP does not place an a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 890 </p> 891 <p id="rfc.section.3.2.p.5"> </p> 906 892 <dl class="empty"> 907 893 <dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations … … 909 895 </dd> 910 896 </dl> 911 <h3 id="rfc.section.3.2. 2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="http.url" href="#http.url">http URL</a></h3>897 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="http.uri" href="#http.uri">http URI scheme</a></h3> 912 898 <div id="rfc.iref.h.1"></div> 913 899 <div id="rfc.iref.u.1"></div> 914 <p id="rfc.section.3.2.2.p.1">The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax 915 and semantics for http URLs. 916 </p> 917 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#http.url" class="smpl">http-URL</a> = "http:" "//" <a href="#general.syntax" class="smpl">uri-host</a> [ ":" <a href="#general.syntax" class="smpl">port</a> ] 918 [ <a href="#general.syntax" class="smpl">path-absolute</a> [ "?" <a href="#general.syntax" class="smpl">query</a> ]] 919 </pre><p id="rfc.section.3.2.2.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server 900 <p id="rfc.section.3.2.1.p.1">The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the syntax and semantics 901 for identifiers using the http or https URI schemes. 902 </p> 903 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 904 </pre><p id="rfc.section.3.2.1.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server 920 905 listening for TCP connections on that port of that host, and the Request-URI for the resource is path-absolute (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 921 906 </p> … … 924 909 </dd> 925 910 </dl> 926 <h3 id="rfc.section.3.2. 3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>927 <p id="rfc.section.3.2. 3.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:911 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3> 912 <p id="rfc.section.3.2.2.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: 928 913 </p> 929 914 <ul> … … 935 920 <li>An empty path-absolute is equivalent to an path-absolute of "/".</li> 936 921 </ul> 937 <p id="rfc.section.3.2. 3.p.2">Characters other than those in the "reserved" set (see <a href="#RFC2396" id="rfc.xref.RFC2396.10"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-2.2">Section 2.2</a>) are equivalent to their ""%" <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding.938 </p> 939 <p id="rfc.section.3.2. 3.p.3">For example, the following three URIs are equivalent:</p>922 <p id="rfc.section.3.2.2.p.2">Characters other than those in the "reserved" set (see <a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.2">Section 2.2</a>) are equivalent to their ""%" <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding. 923 </p> 924 <p id="rfc.section.3.2.2.p.3">For example, the following three URIs are equivalent:</p> 940 925 <div id="rfc.figure.u.18"></div><pre class="text"> http://example.com:80/~smith/home.html 941 926 http://EXAMPLE.com/%7Esmith/home.html … … 959 944 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional LWS beyond that specifically included as SP in the grammar. 960 945 </p> 961 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.2 3"></span><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><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span> <a href="#full.date" class="smpl">HTTP-date</a> = <a href="#full.date" class="smpl">rfc1123-date</a> / <a href="#full.date" class="smpl">obsolete-date</a>946 <div id="rfc.figure.u.20"></div><pre class="inline"><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><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <a href="#full.date" class="smpl">HTTP-date</a> = <a href="#full.date" class="smpl">rfc1123-date</a> / <a href="#full.date" class="smpl">obsolete-date</a> 962 947 <a href="#full.date" class="smpl">obsolete-date</a> = <a href="#full.date" class="smpl">rfc850-date</a> / <a href="#full.date" class="smpl">asctime-date</a> 963 948 <a href="#full.date" class="smpl">rfc1123-date</a> = <a href="#full.date" class="smpl">wkday</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> time <a href="#core.rules" class="smpl">SP</a> GMT … … 1018 1003 is a property of the message, not of the original entity. 1019 1004 </p> 1020 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.3 5"></span><span id="rfc.iref.g.36"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a>1005 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a> 1021 1006 <a href="#transfer.codings" class="smpl">transfer-extension</a> = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#transfer.codings" class="smpl">parameter</a> ) 1022 1007 </pre><div id="rule.parameter"> 1023 1008 <p id="rfc.section.3.4.p.3"> Parameters are in the form of attribute/value pairs.</p> 1024 1009 </div> 1025 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.3 7"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#transfer.codings" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1010 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span> <a href="#transfer.codings" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1026 1011 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1027 1012 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> … … 1037 1022 </p> 1038 1023 <p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry 1039 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3. 6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1040 </p> 1041 <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3. 7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1024 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1025 </p> 1026 <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1042 1027 </p> 1043 1028 <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. … … 1048 1033 necessary for the recipient to verify that it has received the full message. 1049 1034 </p> 1050 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.4 0"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span> <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a>1035 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span> <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a> 1051 1036 <a href="#chunked.transfer.encoding" class="smpl">last-chunk</a> 1052 1037 <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a> … … 1107 1092 space. By convention, the products are listed in order of their significance for identifying the application. 1108 1093 </p> 1109 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g. 49"></span><span id="rfc.iref.g.50"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]1094 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1110 1095 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1111 1096 </pre><p id="rfc.section.3.5.p.3">Examples:</p> … … 1117 1102 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="message.types" href="#message.types">Message Types</a></h2> 1118 1103 <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1119 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.5 1"></span> <a href="#message.types" class="smpl">HTTP-message</a> = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a> ; HTTP/1.1 messages1104 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#message.types" class="smpl">HTTP-message</a> = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a> ; HTTP/1.1 messages 1120 1105 </pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section 5</a>) and Response (<a href="#response" title="Response">Section 6</a>) messages use the generic message format of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header 1121 1106 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1122 1107 fields, and possibly a message-body. 1123 1108 </p> 1124 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.5 2"></span><span id="rfc.iref.g.53"></span> <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a>1109 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span> <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a> 1125 1110 *(<a href="#message.headers" class="smpl">message-header</a> <a href="#core.rules" class="smpl">CRLF</a>) 1126 1111 <a href="#core.rules" class="smpl">CRLF</a> … … 1134 1119 </p> 1135 1120 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2> 1136 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3. 8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The1121 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The 1137 1122 field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding 1138 1123 each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated, … … 1140 1125 forms. 1141 1126 </p> 1142 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.5 4"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span> <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" [ <a href="#message.headers" class="smpl">field-value</a> ]1127 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span> <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" [ <a href="#message.headers" class="smpl">field-value</a> ] 1143 1128 <a href="#message.headers" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1144 1129 <a href="#message.headers" class="smpl">field-value</a> = *( <a href="#message.headers" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> ) … … 1170 1155 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.7</a>). 1171 1156 </p> 1172 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g. 58"></span> <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>1157 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.60"></span> <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a> 1173 1158 / <entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>> 1174 1159 </pre><p id="rfc.section.4.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding … … 1238 1223 to the entity being transferred. These header fields apply only to the message being transmitted. 1239 1224 </p> 1240 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g. 59"></span> <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a>1225 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.61"></span> <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a> 1241 1226 / <a href="#header.connection" class="smpl">Connection</a> ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a> 1242 1227 / <a href="#header.date" class="smpl">Date</a> ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> … … 1255 1240 resource, the identifier of the resource, and the protocol version in use. 1256 1241 </p> 1257 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.6 0"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 5.1</a>1242 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.62"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 5.1</a> 1258 1243 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1259 1244 / <a href="#abnf.dependencies" class="smpl">request-header</a> ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> 1260 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3. 9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>1245 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> 1261 1246 <a href="#core.rules" class="smpl">CRLF</a> 1262 1247 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 4.3</a> … … 1265 1250 elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. 1266 1251 </p> 1267 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.6 1"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-uri" class="smpl">Request-URI</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>1252 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.63"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-uri" class="smpl">Request-URI</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a> 1268 1253 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="method" href="#method">Method</a></h3> 1269 1254 <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p> 1270 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.6 2"></span><span id="rfc.iref.g.63"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a>1255 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1271 1256 </pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="request-uri" href="#request-uri">Request-URI</a></h3> 1272 1257 <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>) and identifies the resource upon which to apply the request. 1273 1258 </p> 1274 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.6 4"></span> <a href="#request-uri" class="smpl">Request-URI</a> = "*"1275 / <a href="# general.syntax" class="smpl">absoluteURI</a>1276 / ( <a href="# general.syntax" class="smpl">path-absolute</a> [ "?" <a href="#general.syntax" class="smpl">query</a> ] )1277 / <a href="# general.syntax" class="smpl">authority</a>1259 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.66"></span> <a href="#request-uri" class="smpl">Request-URI</a> = "*" 1260 / <a href="#uri" class="smpl">absolute-URI</a> 1261 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) 1262 / <a href="#uri" class="smpl">authority</a> 1278 1263 </pre><p id="rfc.section.5.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does 1279 1264 not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily … … 1281 1266 </p> 1282 1267 <div id="rfc.figure.u.36"></div><pre class="text"> OPTIONS * HTTP/1.1 1283 </pre><p id="rfc.section.5.1.2.p.5">The absolute URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,1284 and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute URI. In order to avoid request1268 </pre><p id="rfc.section.5.1.2.p.5">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, 1269 and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request 1285 1270 loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example 1286 1271 Request-Line would be: 1287 1272 </p> 1288 1273 <div id="rfc.figure.u.37"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1289 </pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absolute URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.1274 </pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1290 1275 </p> 1291 1276 <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1292 1277 </p> 1293 1278 <p id="rfc.section.5.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute 1294 path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="# general.syntax" title="General Syntax">Section 3.2.1</a>, path-absolute) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin1279 path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section 3.2.1</a>, path-absolute) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin 1295 1280 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1296 1281 </p> … … 1300 1285 URI, it <em class="bcp14">MUST</em> be given as "/" (the server root). 1301 1286 </p> 1302 <p id="rfc.section.5.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="# general.syntax" title="General Syntax">Section 3.2.1</a>. If the Request-URI is encoded using the "% <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding (<a href="#RFC2396" id="rfc.xref.RFC2396.11"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-2.4.1">Section 2.4.1</a>), the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.1287 <p id="rfc.section.5.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 3.2.1</a>. If the Request-URI is encoded using the "% <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.4">Section 2.4</a>), the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code. 1303 1288 </p> 1304 1289 <p id="rfc.section.5.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received Request-URI when forwarding it to the next inbound server, except as noted … … 1320 1305 </p> 1321 1306 <ol> 1322 <li>If Request-URI is an absolute URI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.1323 </li> 1324 <li>If the Request-URI is not an absolute URI, and the request includes a Host header field, the host is determined by the Host1307 <li>If Request-URI is an absolute-URI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored. 1308 </li> 1309 <li>If the Request-URI is not an absolute-URI, and the request includes a Host header field, the host is determined by the Host 1325 1310 header field value. 1326 1311 </li> … … 1333 1318 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response" href="#response">Response</a></h1> 1334 1319 <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1335 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.6 5"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 6.1</a>1320 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.67"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 6.1</a> 1336 1321 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1337 1322 / <a href="#abnf.dependencies" class="smpl">response-header</a> ; <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> 1338 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3.1 0"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>1323 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> 1339 1324 <a href="#core.rules" class="smpl">CRLF</a> 1340 1325 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 4.3</a> … … 1344 1329 CRLF sequence. 1345 1330 </p> 1346 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.6 6"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1331 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.68"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1347 1332 </pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1348 1333 <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes … … 1361 1346 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1362 1347 </ul> 1363 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.6 7"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1348 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1364 1349 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *<<a href="#rule.TEXT" class="smpl">TEXT</a>, excluding <a href="#core.rules" class="smpl">CR</a>, <a href="#core.rules" class="smpl">LF</a>> 1365 1350 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="connections" href="#connections">Connections</a></h1> … … 1553 1538 </p> 1554 1539 <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p> 1555 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.7 0"></span><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>1540 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 1556 1541 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1557 1542 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1582 1567 or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. 1583 1568 </p> 1584 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.7 3"></span><span id="rfc.iref.g.74"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>1569 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 1585 1570 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1586 1571 </pre><p id="rfc.section.8.2.p.3">An example is</p> … … 1600 1585 as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section 3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1601 1586 </p> 1602 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.7 5"></span><span id="rfc.iref.g.76"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>1587 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 1603 1588 <a href="#header.date" class="smpl">Date-v</a> = <a href="#full.date" class="smpl">HTTP-date</a> 1604 1589 </pre><p id="rfc.section.8.3.p.3">An example is</p> … … 1635 1620 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.host" href="#header.host">Host</a></h2> 1636 1621 <p id="rfc.section.8.4.p.1">The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from 1637 the original URI given by the user or referring resource (generally an HTTP URL, as described in <a href="#http.ur l" title="http URL">Section 3.2.2</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or1622 the original URI given by the user or referring resource (generally an HTTP URL, as described in <a href="#http.uri" title="http URI scheme">Section 3.2.1</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or 1638 1623 gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on 1639 1624 a single IP address. 1640 1625 </p> 1641 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.7 7"></span><span id="rfc.iref.g.78"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>1642 <a href="#header.host" class="smpl">Host-v</a> = <a href="# general.syntax" class="smpl">uri-host</a> [ ":" <a href="#general.syntax" class="smpl">port</a> ] ; <a href="#http.url" title="http URL">Section 3.2.2</a>1626 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 1627 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 3.2.1</a> 1643 1628 </pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 1644 1629 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: … … 1659 1644 and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>). 1660 1645 </p> 1661 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g. 79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>1646 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 1662 1647 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 1663 1648 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#abnf.dependencies" class="smpl">accept-params</a> ] ) … … 1685 1670 <li> 1686 1671 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 1687 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.1 1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")1672 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.") 1688 1673 </p> 1689 1674 </li> … … 1703 1688 chunked transfer-coding. 1704 1689 </p> 1705 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.8 2"></span><span id="rfc.iref.g.83"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>1690 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 1706 1691 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a> 1707 1692 </pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient … … 1724 1709 transfer-coding is a property of the message, not of the entity. 1725 1710 </p> 1726 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.8 4"></span><span id="rfc.iref.g.85"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a>1711 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 1727 1712 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1728 1713 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>. An example is: … … 1738 1723 to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched. 1739 1724 </p> 1740 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.8 6"></span><span id="rfc.iref.g.87"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>1725 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 1741 1726 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 1742 1727 </pre><p id="rfc.section.8.8.p.3">For example,</p> … … 1770 1755 of all senders along the request/response chain. 1771 1756 </p> 1772 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g. 88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>1757 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 1773 1758 <a href="#header.via" class="smpl">Via-v</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 1774 1759 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a> 1775 1760 <a href="#header.via" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1776 1761 <a href="#header.via" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1777 <a href="#header.via" class="smpl">received-by</a> = ( <a href="# general.syntax" class="smpl">uri-host</a> [ ":" <a href="#general.syntax" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>1762 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 1778 1763 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> 1779 1764 </pre><p id="rfc.section.8.9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of … … 1890 1875 <p id="rfc.section.9.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1891 1876 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2> 1892 <p id="rfc.section.9.2.p.1">The entry for the "http" URI Scheme in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> should be updated to point to <a href="#http.ur l" title="http URL">Section 3.2.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).1877 <p id="rfc.section.9.2.p.1">The entry for the "http" URI Scheme in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> should be updated to point to <a href="#http.uri" title="http URI scheme">Section 3.2.1</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>). 1893 1878 </p> 1894 1879 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2> … … 2074 2059 <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p> 2075 2060 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 2076 <p id="rfc.section.11.p.1">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC5234" id="rfc.xref.RFC5234.4"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and 2077 Internet mail message formats. 2078 </p> 2079 <p id="rfc.section.11.p.2">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people 2061 <p id="rfc.section.11.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people 2080 2062 who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success 2081 2063 of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, … … 2083 2065 and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol. 2084 2066 </p> 2085 <p id="rfc.section.11.p. 3">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already2067 <p id="rfc.section.11.p.2">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already 2086 2068 mentioned, the following individuals have contributed to this specification: 2087 2069 </p> 2088 <p id="rfc.section.11.p. 4">Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman2070 <p id="rfc.section.11.p.3">Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman 2089 2071 Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, 2090 2072 Bob Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben … … 2094 2076 Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. 2095 2077 </p> 2096 <p id="rfc.section.11.p. 5">Thanks to the "cave men" of Palo Alto. You know who you are.</p>2097 <p id="rfc.section.11.p. 6">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott2078 <p id="rfc.section.11.p.4">Thanks to the "cave men" of Palo Alto. You know who you are.</p> 2079 <p id="rfc.section.11.p.5">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott 2098 2080 Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the 2099 2081 "MUST/MAY/SHOULD" audit. 2100 2082 </p> 2101 <p id="rfc.section.11.p. 7">The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank2083 <p id="rfc.section.11.p.6">The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank 2102 2084 them for the discovery of many of the problems that this document attempts to rectify. 2085 </p> 2086 <p id="rfc.section.11.p.7">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC5234" id="rfc.xref.RFC5234.4"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and 2087 Internet mail message formats. 2103 2088 </p> 2104 2089 <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References … … 2150 2135 </tr> 2151 2136 <tr> 2152 <td class="reference"><b id="RFC 2396">[RFC2396]</b></td>2153 <td class="top"><a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="D epartment of Information and Computer Science">Fielding, R.T.</a>, and <a title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC 2396, August 1998.2137 <td class="reference"><b id="RFC3986">[RFC3986]</b></td> 2138 <td class="top"><a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="Day Software">Fielding, R.</a>, and <a title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, RFC 3986, STD 66, January 2005. 2154 2139 </td> 2155 2140 </tr> … … 2166 2151 <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References 2167 2152 </h2> 2168 <table summary="Informative References"> 2153 <table summary="Informative References"> 2169 2154 <tr> 2170 2155 <td class="reference"><b id="Kri2001">[Kri2001]</b></td> … … 2199 2184 </tr> 2200 2185 <tr> 2201 <td class="reference"><b id="RFC1630">[RFC1630]</b></td>2202 <td class="top"><a title="CERN, World-Wide Web project">Berners-Lee, T.</a>, “<a href="http://tools.ietf.org/html/rfc1630">Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network2203 as used in the World-Wide Web</a>”, RFC 1630, June 1994.2204 </td>2205 </tr>2206 <tr>2207 <td class="reference"><b id="RFC1737">[RFC1737]</b></td>2208 <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a title="MIT Laboratory for Computer Science">K. Sollins</a>, “<a href="http://tools.ietf.org/html/rfc1737">Functional Requirements for Uniform Resource Names</a>”, RFC 1737, December 1994.2209 </td>2210 </tr>2211 <tr>2212 <td class="reference"><b id="RFC1738">[RFC1738]</b></td>2213 <td class="top"><a title="CERN, World-Wide Web project">Berners-Lee, T.</a>, <a title="Xerox PARC">Masinter, L.</a>, and <a title="University of Minnesota, Computer and Information Services">M. McCahill</a>, “<a href="http://tools.ietf.org/html/rfc1738">Uniform Resource Locators (URL)</a>”, RFC 1738, December 1994.2214 </td>2215 </tr>2216 <tr>2217 <td class="reference"><b id="RFC1808">[RFC1808]</b></td>2218 <td class="top"><a title="University of California Irvine, Department of Information and Computer Science">Fielding, R.</a>, “<a href="http://tools.ietf.org/html/rfc1808">Relative Uniform Resource Locators</a>”, RFC 1808, June 1995.2219 </td>2220 </tr>2221 <tr>2222 2186 <td class="reference"><b id="RFC1900">[RFC1900]</b></td> 2223 2187 <td class="top"><a title="CERN, Computing and Networks Division">Carpenter, B.</a> and <a title="cisco Systems">Y. Rekhter</a>, “<a href="http://tools.ietf.org/html/rfc1900">Renumbering Needs Work</a>”, RFC 1900, February 1996. … … 2245 2209 </tr> 2246 2210 <tr> 2247 <td class="reference"><b id="RFC2324">[RFC2324]</b></td>2248 <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="http://tools.ietf.org/html/rfc2324">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</a>”, RFC 2324, April 1998.2249 </td>2250 </tr>2251 <tr>2252 2211 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 2253 2212 <td class="top"><a title="University of California, Irvine">Fielding, R.</a>, <a title="W3C">Gettys, J.</a>, <a title="Compaq Computer Corporation">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a title="Xerox Corporation">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. … … 2257 2216 <td class="reference"><b id="RFC2818">[RFC2818]</b></td> 2258 2217 <td class="top"><a title="RTFM, Inc.">Rescorla, E.</a>, “<a href="http://tools.ietf.org/html/rfc2818">HTTP Over TLS</a>”, RFC 2818, May 2000. 2259 </td>2260 </tr>2261 <tr>2262 <td class="reference"><b id="RFC2821">[RFC2821]</b></td>2263 <td class="top"><a title="AT&T Laboratories">Klensin, J.</a>, “<a href="http://tools.ietf.org/html/rfc2821">Simple Mail Transfer Protocol</a>”, RFC 2821, April 2001.2264 2218 </td> 2265 2219 </tr> … … 2346 2300 </p> 2347 2301 <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling 2348 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.1 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2302 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2349 2303 </p> 2350 2304 <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 2365 2319 </p> 2366 2320 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 2367 <p id="rfc.section.C.p.1">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately 2321 <p id="rfc.section.C.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred 2322 to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single method and no metadata. 2323 HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers 2324 on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical 2325 proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely-implemented 2326 applications calling themselves "HTTP/1.0" further necessitated a protocol version change in order for two communicating applications 2327 to determine each other's true capabilities. 2328 </p> 2329 <p id="rfc.section.C.p.2">HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding 2330 only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a 2331 party advertising compliance with HTTP/1.1. 2332 </p> 2333 <p id="rfc.section.C.p.3">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately 2368 2334 designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification 2369 2335 (1996), we would expect commercial HTTP/1.1 servers to: … … 2374 2340 <li>respond appropriately with a message in the same major version used by the client.</li> 2375 2341 </ul> 2376 <p id="rfc.section.C.p. 2">And we would expect HTTP/1.1 clients to: </p>2342 <p id="rfc.section.C.p.4">And we would expect HTTP/1.1 clients to: </p> 2377 2343 <ul> 2378 2344 <li>recognize the format of the Status-Line for HTTP/1.0 and 1.1 responses;</li> 2379 2345 <li>understand any valid response in the format of HTTP/0.9, 1.0, or 1.1.</li> 2380 2346 </ul> 2381 <p id="rfc.section.C.p. 3">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the2347 <p id="rfc.section.C.p.5">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the 2382 2348 server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described 2383 2349 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. … … 2429 2395 <p id="rfc.section.C.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 2430 2396 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 2431 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.4</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.1 3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)2397 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.4</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) 2432 2398 </p> 2433 2399 <p id="rfc.section.C.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 … … 2451 2417 <p id="rfc.section.C.4.p.4">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>) 2452 2418 </p> 2453 <p id="rfc.section.C.4.p.5"> Fix BNF to add query, as the abs_path production in <a href="http://tools.ietf.org/html/rfc2396#section-3">Section 3</a> of <a href="#RFC2396" id="rfc.xref.RFC2396.12"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> doesn't define it. (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>)2419 <p id="rfc.section.C.4.p.5">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>) 2454 2420 </p> 2455 2421 <p id="rfc.section.C.4.p.6">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 8.1</a>) … … 2491 2457 <dl class="empty"> 2492 2458 <dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of 2493 entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1 4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2459 entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.15"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2494 2460 </dd> 2495 2461 </dl> … … 2497 2463 </p> 2498 2464 <dl class="empty"> 2499 <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1 5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.2465 <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.16"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status. 2500 2466 </dd> 2501 2467 </dl> … … 2503 2469 </p> 2504 2470 <dl class="empty"> 2505 <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1 6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).2471 <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.17"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses). 2506 2472 </dd> 2507 2473 </dl> … … 2550 2516 </dd> 2551 2517 </dl> 2552 <p id="rfc.section.D.p.16"> <span id="rfc.iref.g.9 5"></span> <dfn>gateway</dfn>2518 <p id="rfc.section.D.p.16"> <span id="rfc.iref.g.97"></span> <dfn>gateway</dfn> 2553 2519 </p> 2554 2520 <dl class="empty"> … … 2596 2562 <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a> Since RFC2616 2597 2563 </h2> 2598 <p id="rfc.section.E.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616. 4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.2564 <p id="rfc.section.E.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 2599 2565 </p> 2600 2566 <h2 id="rfc.section.E.2"><a href="#rfc.section.E.2">E.2</a> Since draft-ietf-httpbis-p1-messaging-00 … … 2718 2684 <p id="rfc.section.E.6.p.1">Closed issues: </p> 2719 2685 <ul> 2686 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/34">http://tools.ietf.org/wg/httpbis/trac/ticket/34</a>>: "Out-of-date reference for URIs" 2687 </li> 2720 2688 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/132">http://tools.ietf.org/wg/httpbis/trac/ticket/132</a>>: "RFC 2822 is updated by RFC 5322" 2721 2689 </li> … … 2783 2751 </li> 2784 2752 <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind"> 2785 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.9 5">D</a></li>2753 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.97">D</a></li> 2786 2754 <li class="indline1"><tt>Grammar</tt> 2787 2755 <ul class="ind"> 2788 <li class="indline1"><tt>absolute URI</tt> <a class="iref" href="#rfc.iref.g.15"><b>3.2.1</b></a></li>2789 <li class="indline1"><tt>asctime-date</tt> <a class="iref" href="#rfc.iref.g.2 7"><b>3.3.1</b></a></li>2790 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g. 38"><b>3.4</b></a></li>2791 <li class="indline1"><tt>authority</tt> <a class="iref" href="#rfc.iref.g.1 6"><b>3.2.1</b></a></li>2756 <li class="indline1"><tt>absolute-URI</tt> <a class="iref" href="#rfc.iref.g.16"><b>3.2</b></a></li> 2757 <li class="indline1"><tt>asctime-date</tt> <a class="iref" href="#rfc.iref.g.29"><b>3.3.1</b></a></li> 2758 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.40"><b>3.4</b></a></li> 2759 <li class="indline1"><tt>authority</tt> <a class="iref" href="#rfc.iref.g.17"><b>3.2</b></a></li> 2792 2760 <li class="indline1"><tt>BWS</tt> <a class="iref" href="#rfc.iref.g.3"><b>2.2</b></a></li> 2793 <li class="indline1"><tt>chunk</tt> <a class="iref" href="#rfc.iref.g.4 1"><b>3.4.1</b></a></li>2794 <li class="indline1"><tt>chunk-data</tt> <a class="iref" href="#rfc.iref.g.4 7"><b>3.4.1</b></a></li>2795 <li class="indline1"><tt>chunk-ext</tt> <a class="iref" href="#rfc.iref.g.4 4"><b>3.4.1</b></a></li>2796 <li class="indline1"><tt>chunk-ext-name</tt> <a class="iref" href="#rfc.iref.g.4 5"><b>3.4.1</b></a></li>2797 <li class="indline1"><tt>chunk-ext-val</tt> <a class="iref" href="#rfc.iref.g.4 6"><b>3.4.1</b></a></li>2798 <li class="indline1"><tt>chunk-size</tt> <a class="iref" href="#rfc.iref.g.4 2"><b>3.4.1</b></a></li>2799 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.4 0"><b>3.4.1</b></a></li>2761 <li class="indline1"><tt>chunk</tt> <a class="iref" href="#rfc.iref.g.43"><b>3.4.1</b></a></li> 2762 <li class="indline1"><tt>chunk-data</tt> <a class="iref" href="#rfc.iref.g.49"><b>3.4.1</b></a></li> 2763 <li class="indline1"><tt>chunk-ext</tt> <a class="iref" href="#rfc.iref.g.46"><b>3.4.1</b></a></li> 2764 <li class="indline1"><tt>chunk-ext-name</tt> <a class="iref" href="#rfc.iref.g.47"><b>3.4.1</b></a></li> 2765 <li class="indline1"><tt>chunk-ext-val</tt> <a class="iref" href="#rfc.iref.g.48"><b>3.4.1</b></a></li> 2766 <li class="indline1"><tt>chunk-size</tt> <a class="iref" href="#rfc.iref.g.44"><b>3.4.1</b></a></li> 2767 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.42"><b>3.4.1</b></a></li> 2800 2768 <li class="indline1"><tt>comment</tt> <a class="iref" href="#rfc.iref.g.7"><b>2.2</b></a></li> 2801 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.7 0"><b>8.1</b></a></li>2802 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.7 2"><b>8.1</b></a></li>2803 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.7 1"><b>8.1</b></a></li>2804 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.7 3"><b>8.2</b></a></li>2805 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.7 4"><b>8.2</b></a></li>2769 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.72"><b>8.1</b></a></li> 2770 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.74"><b>8.1</b></a></li> 2771 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.73"><b>8.1</b></a></li> 2772 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.75"><b>8.2</b></a></li> 2773 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.76"><b>8.2</b></a></li> 2806 2774 <li class="indline1"><tt>ctext</tt> <a class="iref" href="#rfc.iref.g.8"><b>2.2</b></a></li> 2807 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.7 5"><b>8.3</b></a></li>2808 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g.7 6"><b>8.3</b></a></li>2809 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g. 28"><b>3.3.1</b></a></li>2810 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g. 29"><b>3.3.1</b></a></li>2811 <li class="indline1"><tt>date3</tt> <a class="iref" href="#rfc.iref.g.3 0"><b>3.3.1</b></a></li>2812 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g. 68"><b>6.1.1</b></a></li>2813 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.6 3"><b>5.1.1</b></a></li>2814 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.5 7"><b>4.2</b></a></li>2815 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.5 5"><b>4.2</b></a></li>2816 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.5 6"><b>4.2</b></a></li>2817 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g. 59"><b>4.5</b></a></li>2818 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g.5 2"><b>4.1</b></a></li>2819 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.7 7"><b>8.4</b></a></li>2820 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g. 78"><b>8.4</b></a></li>2821 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.2 3"><b>3.3.1</b></a></li>2822 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.5 1"><b>4.1</b></a></li>2775 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.77"><b>8.3</b></a></li> 2776 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g.78"><b>8.3</b></a></li> 2777 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.30"><b>3.3.1</b></a></li> 2778 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.31"><b>3.3.1</b></a></li> 2779 <li class="indline1"><tt>date3</tt> <a class="iref" href="#rfc.iref.g.32"><b>3.3.1</b></a></li> 2780 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.70"><b>6.1.1</b></a></li> 2781 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.65"><b>5.1.1</b></a></li> 2782 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.59"><b>4.2</b></a></li> 2783 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.57"><b>4.2</b></a></li> 2784 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.58"><b>4.2</b></a></li> 2785 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.61"><b>4.5</b></a></li> 2786 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g.54"><b>4.1</b></a></li> 2787 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.79"><b>8.4</b></a></li> 2788 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g.80"><b>8.4</b></a></li> 2789 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.25"><b>3.3.1</b></a></li> 2790 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.53"><b>4.1</b></a></li> 2823 2791 <li class="indline1"><tt>HTTP-Prot-Name</tt> <a class="iref" href="#rfc.iref.g.14"><b>3.1</b></a></li> 2824 <li class="indline1"><tt>http-UR L</tt> <a class="iref" href="#rfc.iref.g.22"><b>3.2.2</b></a></li>2792 <li class="indline1"><tt>http-URI</tt> <a class="iref" href="#rfc.iref.g.24"><b>3.2.1</b></a></li> 2825 2793 <li class="indline1"><tt>HTTP-Version</tt> <a class="iref" href="#rfc.iref.g.13"><b>3.1</b></a></li> 2826 <li class="indline1"><tt>last-chunk</tt> <a class="iref" href="#rfc.iref.g.4 3"><b>3.4.1</b></a></li>2827 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g. 58"><b>4.3</b></a></li>2828 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.5 4"><b>4.2</b></a></li>2829 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.6 2"><b>5.1.1</b></a></li>2830 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.3 4"><b>3.3.1</b></a></li>2831 <li class="indline1"><tt>obsolete-date</tt> <a class="iref" href="#rfc.iref.g.2 5"><b>3.3.1</b></a></li>2794 <li class="indline1"><tt>last-chunk</tt> <a class="iref" href="#rfc.iref.g.45"><b>3.4.1</b></a></li> 2795 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.60"><b>4.3</b></a></li> 2796 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.56"><b>4.2</b></a></li> 2797 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.64"><b>5.1.1</b></a></li> 2798 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.36"><b>3.3.1</b></a></li> 2799 <li class="indline1"><tt>obsolete-date</tt> <a class="iref" href="#rfc.iref.g.27"><b>3.3.1</b></a></li> 2832 2800 <li class="indline1"><tt>OWS</tt> <a class="iref" href="#rfc.iref.g.1"><b>2.2</b></a></li> 2833 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.3 7"><b>3.4</b></a></li>2834 <li class="indline1"><tt>path-absolute</tt> <a class="iref" href="#rfc.iref.g.1 7"><b>3.2.1</b></a></li>2835 <li class="indline1"><tt>port</tt> <a class="iref" href="#rfc.iref.g.1 8"><b>3.2.1</b></a></li>2836 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g. 49"><b>3.5</b></a></li>2837 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.5 0"><b>3.5</b></a></li>2838 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.9 1"><b>8.9</b></a></li>2839 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.9 2"><b>8.9</b></a></li>2840 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.9 4"><b>8.9</b></a></li>2801 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.39"><b>3.4</b></a></li> 2802 <li class="indline1"><tt>path-absolute</tt> <a class="iref" href="#rfc.iref.g.18"><b>3.2</b></a></li> 2803 <li class="indline1"><tt>port</tt> <a class="iref" href="#rfc.iref.g.19"><b>3.2</b></a></li> 2804 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.51"><b>3.5</b></a></li> 2805 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.52"><b>3.5</b></a></li> 2806 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.93"><b>8.9</b></a></li> 2807 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.94"><b>8.9</b></a></li> 2808 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.96"><b>8.9</b></a></li> 2841 2809 <li class="indline1"><tt>qdtext</tt> <a class="iref" href="#rfc.iref.g.10"><b>2.2</b></a></li> 2842 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g. 19"><b>3.2.1</b></a></li>2810 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g.20"><b>3.2</b></a></li> 2843 2811 <li class="indline1"><tt>quoted-pair</tt> <a class="iref" href="#rfc.iref.g.12"><b>2.2</b></a></li> 2844 2812 <li class="indline1"><tt>quoted-string</tt> <a class="iref" href="#rfc.iref.g.9"><b>2.2</b></a></li> 2845 2813 <li class="indline1"><tt>quoted-text</tt> <a class="iref" href="#rfc.iref.g.11"><b>2.2</b></a></li> 2846 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.69"><b>6.1.1</b></a></li> 2847 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.93"><b>8.9</b></a></li> 2848 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.90"><b>8.9</b></a></li> 2849 <li class="indline1"><tt>relativeURI</tt> <a class="iref" href="#rfc.iref.g.20"><b>3.2.1</b></a></li> 2850 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.60"><b>5</b></a></li> 2851 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.61"><b>5.1</b></a></li> 2852 <li class="indline1"><tt>Request-URI</tt> <a class="iref" href="#rfc.iref.g.64"><b>5.1.2</b></a></li> 2853 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.65"><b>6</b></a></li> 2854 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.24"><b>3.3.1</b></a></li> 2855 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g.26"><b>3.3.1</b></a></li> 2814 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.71"><b>6.1.1</b></a></li> 2815 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.95"><b>8.9</b></a></li> 2816 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.92"><b>8.9</b></a></li> 2817 <li class="indline1"><tt>relative-part</tt> <a class="iref" href="#rfc.iref.g.23"><b>3.2</b></a></li> 2818 <li class="indline1"><tt>relativeURI</tt> <a class="iref" href="#rfc.iref.g.22"><b>3.2</b></a></li> 2819 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.62"><b>5</b></a></li> 2820 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.63"><b>5.1</b></a></li> 2821 <li class="indline1"><tt>Request-URI</tt> <a class="iref" href="#rfc.iref.g.66"><b>5.1.2</b></a></li> 2822 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.67"><b>6</b></a></li> 2823 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.26"><b>3.3.1</b></a></li> 2824 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g.28"><b>3.3.1</b></a></li> 2856 2825 <li class="indline1"><tt>RWS</tt> <a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li> 2857 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g.5 3"><b>4.1</b></a></li>2858 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.6 7"><b>6.1.1</b></a></li>2859 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.6 6"><b>6.1</b></a></li>2860 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.8 1"><b>8.5</b></a></li>2826 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g.55"><b>4.1</b></a></li> 2827 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.69"><b>6.1.1</b></a></li> 2828 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.68"><b>6.1</b></a></li> 2829 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.83"><b>8.5</b></a></li> 2861 2830 <li class="indline1"><tt>tchar</tt> <a class="iref" href="#rfc.iref.g.6"><b>2.2</b></a></li> 2862 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g. 79"><b>8.5</b></a></li>2863 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g.8 0"><b>8.5</b></a></li>2831 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.81"><b>8.5</b></a></li> 2832 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g.82"><b>8.5</b></a></li> 2864 2833 <li class="indline1"><tt>TEXT</tt> <a class="iref" href="#rfc.iref.g.4"><b>2.2</b></a></li> 2865 <li class="indline1"><tt>time</tt> <a class="iref" href="#rfc.iref.g.3 1"><b>3.3.1</b></a></li>2834 <li class="indline1"><tt>time</tt> <a class="iref" href="#rfc.iref.g.33"><b>3.3.1</b></a></li> 2866 2835 <li class="indline1"><tt>token</tt> <a class="iref" href="#rfc.iref.g.5"><b>2.2</b></a></li> 2867 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.82"><b>8.6</b></a></li> 2868 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.48"><b>3.4.1</b></a></li> 2869 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.83"><b>8.6</b></a></li> 2870 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.35"><b>3.4</b></a></li> 2871 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.84"><b>8.7</b></a></li> 2872 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.85"><b>8.7</b></a></li> 2873 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.36"><b>3.4</b></a></li> 2874 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.86"><b>8.8</b></a></li> 2875 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.87"><b>8.8</b></a></li> 2876 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.21"><b>3.2.1</b></a></li> 2877 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.39"><b>3.4</b></a></li> 2878 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.88"><b>8.9</b></a></li> 2879 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.9</b></a></li> 2880 <li class="indline1"><tt>weekday</tt> <a class="iref" href="#rfc.iref.g.33"><b>3.3.1</b></a></li> 2881 <li class="indline1"><tt>wkday</tt> <a class="iref" href="#rfc.iref.g.32"><b>3.3.1</b></a></li> 2836 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.84"><b>8.6</b></a></li> 2837 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.50"><b>3.4.1</b></a></li> 2838 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.85"><b>8.6</b></a></li> 2839 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.4</b></a></li> 2840 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.86"><b>8.7</b></a></li> 2841 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.87"><b>8.7</b></a></li> 2842 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.38"><b>3.4</b></a></li> 2843 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.88"><b>8.8</b></a></li> 2844 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.8</b></a></li> 2845 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.21"><b>3.2</b></a></li> 2846 <li class="indline1"><tt>URI-reference</tt> <a class="iref" href="#rfc.iref.g.15"><b>3.2</b></a></li> 2847 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.41"><b>3.4</b></a></li> 2848 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.90"><b>8.9</b></a></li> 2849 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.91"><b>8.9</b></a></li> 2850 <li class="indline1"><tt>weekday</tt> <a class="iref" href="#rfc.iref.g.35"><b>3.3.1</b></a></li> 2851 <li class="indline1"><tt>wkday</tt> <a class="iref" href="#rfc.iref.g.34"><b>3.3.1</b></a></li> 2882 2852 </ul> 2883 2853 </li> … … 2899 2869 </li> 2900 2870 <li class="indline1">Host header <a class="iref" href="#rfc.iref.h.6"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">C.1.1</a></li> 2901 <li class="indline1">http URI scheme <a class="iref" href="#rfc.iref.h.1"><b>3.2. 2</b></a></li>2902 <li class="indline1">https URI scheme <a class="iref" href="#rfc.iref.h.2">3.2. 2</a></li>2871 <li class="indline1">http URI scheme <a class="iref" href="#rfc.iref.h.1"><b>3.2.1</b></a></li> 2872 <li class="indline1">https URI scheme <a class="iref" href="#rfc.iref.h.2">3.2.1</a></li> 2903 2873 </ul> 2904 2874 </li> … … 2934 2904 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2935 2905 <li class="indline1"><em>Pad1995</em> <a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12.2</b></a></li> 2936 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">3.2 .1</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">4.3</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">2906 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">3.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">4.3</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind"> 2937 2907 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.6">4.3</a></li> 2938 2908 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part2.1">2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a></li> … … 2943 2913 <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li> 2944 2914 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a></li> 2945 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2.3">3.2 .1</a></li>2915 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2.3">3.2</a></li> 2946 2916 <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a></li> 2947 2917 </ul> 2948 2918 </li> 2949 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1 .3</a>, <a class="iref" href="#rfc.xref.Part3.2">2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.12">A</a>, <a class="iref" href="#rfc.xref.Part3.13">C.3</a>, <a class="iref" href="#rfc.xref.Part3.14">D</a>, <a class="iref" href="#rfc.xref.Part3.15">D</a>, <a class="iref" href="#rfc.xref.Part3.16">D</a><ul class="ind">2950 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part3. 6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a></li>2951 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part3. 2">2.2</a></li>2952 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part3.1 1">8.5</a></li>2953 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3. 5">2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li>2954 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.1 4">D</a></li>2955 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part3. 4">2.3</a></li>2956 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.1 5">D</a>, <a class="iref" href="#rfc.xref.Part3.16">D</a></li>2957 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part3. 3">2.3</a></li>2958 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1 .3</a></li>2919 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2</a>, <a class="iref" href="#rfc.xref.Part3.3">2.2</a>, <a class="iref" href="#rfc.xref.Part3.4">2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">2.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">3.4</a>, <a class="iref" href="#rfc.xref.Part3.9">4.2</a>, <a class="iref" href="#rfc.xref.Part3.10">5</a>, <a class="iref" href="#rfc.xref.Part3.11">6</a>, <a class="iref" href="#rfc.xref.Part3.12">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.13">A</a>, <a class="iref" href="#rfc.xref.Part3.14">C.3</a>, <a class="iref" href="#rfc.xref.Part3.15">D</a>, <a class="iref" href="#rfc.xref.Part3.16">D</a>, <a class="iref" href="#rfc.xref.Part3.17">D</a><ul class="ind"> 2920 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">3.4</a></li> 2921 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part3.3">2.2</a></li> 2922 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part3.12">8.5</a></li> 2923 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.6">2.3</a>, <a class="iref" href="#rfc.xref.Part3.9">4.2</a>, <a class="iref" href="#rfc.xref.Part3.10">5</a>, <a class="iref" href="#rfc.xref.Part3.11">6</a></li> 2924 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.15">D</a></li> 2925 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part3.5">2.3</a></li> 2926 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.16">D</a>, <a class="iref" href="#rfc.xref.Part3.17">D</a></li> 2927 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part3.4">2.3</a></li> 2928 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2</a></li> 2959 2929 </ul> 2960 2930 </li> 2961 2931 <li class="indline1"><em>Part5</em> <a class="iref" href="#Part5"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">C.3</a></li> 2962 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1. 3</a>, <a class="iref" href="#rfc.xref.Part6.2">2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">C.3</a>, <a class="iref" href="#rfc.xref.Part6.9">D</a><ul class="ind">2963 <li class="indline1"><em>Section 1</em> <a class="iref" href="#rfc.xref.Part6.1">1. 3</a>, <a class="iref" href="#rfc.xref.Part6.9">D</a></li>2932 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2</a>, <a class="iref" href="#rfc.xref.Part6.2">2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">C.3</a>, <a class="iref" href="#rfc.xref.Part6.9">D</a><ul class="ind"> 2933 <li class="indline1"><em>Section 1</em> <a class="iref" href="#rfc.xref.Part6.1">1.2</a>, <a class="iref" href="#rfc.xref.Part6.9">D</a></li> 2964 2934 <li class="indline1"><em>Section 16.2</em> <a class="iref" href="#rfc.xref.Part6.5">4.5</a></li> 2965 2935 <li class="indline1"><em>Section 16.4</em> <a class="iref" href="#rfc.xref.Part6.2">2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a></li> … … 2977 2947 <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">3.3.1</a>, <a class="iref" href="#RFC1123"><b>12.2</b></a></li> 2978 2948 <li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1">8.3</a>, <a class="iref" href="#RFC1305"><b>12.2</b></a></li> 2979 <li class="indline1"><em>RFC1436</em> <a class="iref" href="#rfc.xref.RFC1436.1">1.1</a>, <a class="iref" href="#RFC1436"><b>12.2</b></a></li> 2980 <li class="indline1"><em>RFC1630</em> <a class="iref" href="#rfc.xref.RFC1630.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1630.2">3.2</a>, <a class="iref" href="#RFC1630"><b>12.2</b></a></li> 2981 <li class="indline1"><em>RFC1737</em> <a class="iref" href="#rfc.xref.RFC1737.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1737.2">3.2</a>, <a class="iref" href="#RFC1737"><b>12.2</b></a></li> 2982 <li class="indline1"><em>RFC1738</em> <a class="iref" href="#rfc.xref.RFC1738.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1738.2">3.2</a>, <a class="iref" href="#rfc.xref.RFC1738.3">3.2.1</a>, <a class="iref" href="#RFC1738"><b>12.2</b></a></li> 2983 <li class="indline1"><em>RFC1808</em> <a class="iref" href="#rfc.xref.RFC1808.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC1808.2">3.2.1</a>, <a class="iref" href="#RFC1808"><b>12.2</b></a></li> 2984 <li class="indline1"><em>RFC1900</em> <a class="iref" href="#rfc.xref.RFC1900.1">3.2.2</a>, <a class="iref" href="#rfc.xref.RFC1900.2">10.4</a>, <a class="iref" href="#RFC1900"><b>12.2</b></a></li> 2985 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#rfc.xref.RFC1945.1">1</a>, <a class="iref" href="#RFC1945"><b>12.2</b></a></li> 2986 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.4</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.1</b></a></li> 2949 <li class="indline1"><em>RFC1436</em> <a class="iref" href="#rfc.xref.RFC1436.1">1</a>, <a class="iref" href="#RFC1436"><b>12.2</b></a></li> 2950 <li class="indline1"><em>RFC1900</em> <a class="iref" href="#rfc.xref.RFC1900.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC1900.2">10.4</a>, <a class="iref" href="#RFC1900"><b>12.2</b></a></li> 2951 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">C</a></li> 2952 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.4</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.1</b></a></li> 2987 2953 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">2.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li> 2988 2954 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.5">11</a>, <a class="iref" href="#RFC2068"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.6">C</a>, <a class="iref" href="#rfc.xref.RFC2068.7">C.2</a><ul class="ind"> … … 2991 2957 </li> 2992 2958 <li class="indline1"><em>RFC2109</em> <a class="iref" href="#rfc.xref.RFC2109.1">4.2</a>, <a class="iref" href="#RFC2109"><b>12.2</b></a></li> 2993 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1. 2</a>, <a class="iref" href="#RFC2119"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">C.3</a></li>2959 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">C.3</a></li> 2994 2960 <li class="indline1"><em>RFC2145</em> <a class="iref" href="#rfc.xref.RFC2145.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2145.2">3.1</a>, <a class="iref" href="#RFC2145"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2145.3">C.3</a></li> 2995 <li class="indline1"><em>RFC2324</em> <a class="iref" href="#rfc.xref.RFC2324.1">1.1</a>, <a class="iref" href="#RFC2324"><b>12.2</b></a></li> 2996 <li class="indline1"><em>RFC2396</em> <a class="iref" href="#rfc.xref.RFC2396.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.2">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.3">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.4">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.5">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.6">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.7">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.8">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.9">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.10">3.2.3</a>, <a class="iref" href="#rfc.xref.RFC2396.11">5.1.2</a>, <a class="iref" href="#RFC2396"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.RFC2396.12">C.4</a><ul class="ind"> 2997 <li class="indline1"><em>Section 2.4.1</em> <a class="iref" href="#rfc.xref.RFC2396.11">5.1.2</a></li> 2998 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.RFC2396.10">3.2.3</a></li> 2999 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.RFC2396.6">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.9">3.2.1</a></li> 3000 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.RFC2396.3">3.2.1</a></li> 3001 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.RFC2396.7">3.2.1</a></li> 3002 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.RFC2396.2">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.5">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.12">C.4</a></li> 3003 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.RFC2396.4">3.2.1</a></li> 3004 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.RFC2396.8">3.2.1</a></li> 2961 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">11</a>, <a class="iref" href="#RFC2616"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a></li> 2962 <li class="indline1"><em>RFC2818</em> <a class="iref" href="#rfc.xref.RFC2818.1">3.2.1</a>, <a class="iref" href="#RFC2818"><b>12.2</b></a></li> 2963 <li class="indline1"><em>RFC2965</em> <a class="iref" href="#rfc.xref.RFC2965.1">4.2</a>, <a class="iref" href="#RFC2965"><b>12.2</b></a></li> 2964 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">9.1</a>, <a class="iref" href="#RFC3864"><b>12.2</b></a></li> 2965 <li class="indline1"><em>RFC3977</em> <a class="iref" href="#rfc.xref.RFC3977.1">1</a>, <a class="iref" href="#RFC3977"><b>12.2</b></a></li> 2966 <li class="indline1"><em>RFC3986</em> <a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.3">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.4">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.5">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.6">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.7">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.8">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.9">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.10">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.11">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.12">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.13">3.2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.14">5.1.2</a>, <a class="iref" href="#RFC3986"><b>12.1</b></a><ul class="ind"> 2967 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.RFC3986.13">3.2.2</a></li> 2968 <li class="indline1"><em>Section 2.4</em> <a class="iref" href="#rfc.xref.RFC3986.14">5.1.2</a></li> 2969 <li class="indline1"><em>Section 3.2.3</em> <a class="iref" href="#rfc.xref.RFC3986.9">3.2</a></li> 2970 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.RFC3986.11">3.2</a></li> 2971 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.RFC3986.5">3.2</a></li> 2972 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.RFC3986.7">3.2</a>, <a class="iref" href="#rfc.xref.RFC3986.8">3.2</a></li> 2973 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.RFC3986.10">3.2</a></li> 2974 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.RFC3986.6">3.2</a></li> 2975 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.RFC3986.12">3.2</a></li> 2976 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.RFC3986.4">3.2</a></li> 3005 2977 </ul> 3006 2978 </li> 3007 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#rfc.xref.RFC2616.3">11</a>, <a class="iref" href="#RFC2616"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.4">E.1</a></li>3008 <li class="indline1"><em>RFC2818</em> <a class="iref" href="#rfc.xref.RFC2818.1">3.2.2</a>, <a class="iref" href="#RFC2818"><b>12.2</b></a></li>3009 <li class="indline1"><em>RFC2821</em> <a class="iref" href="#rfc.xref.RFC2821.1">1.1</a>, <a class="iref" href="#RFC2821"><b>12.2</b></a></li>3010 <li class="indline1"><em>RFC2965</em> <a class="iref" href="#rfc.xref.RFC2965.1">4.2</a>, <a class="iref" href="#RFC2965"><b>12.2</b></a></li>3011 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">9.1</a>, <a class="iref" href="#RFC3864"><b>12.2</b></a></li>3012 <li class="indline1"><em>RFC3977</em> <a class="iref" href="#rfc.xref.RFC3977.1">1.1</a>, <a class="iref" href="#RFC3977"><b>12.2</b></a></li>3013 2979 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">9.3</a>, <a class="iref" href="#RFC4288"><b>12.2</b></a></li> 3014 2980 <li class="indline1"><em>RFC4395</em> <a class="iref" href="#rfc.xref.RFC4395.1">9.2</a>, <a class="iref" href="#RFC4395"><b>12.2</b></a></li> … … 3017 2983 </ul> 3018 2984 </li> 3019 <li class="indline1"><em>RFC5322</em> <a class="iref" href="#rfc.xref.RFC5322.1">1 .1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">4.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind">2985 <li class="indline1"><em>RFC5322</em> <a class="iref" href="#rfc.xref.RFC5322.1">1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">4.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind"> 3020 2986 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a></li> 3021 2987 <li class="indline1"><em>Section 3.6.1</em> <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a></li> … … 3024 2990 </li> 3025 2991 <li class="indline1"><em>RFC822</em> <a class="iref" href="#rfc.xref.RFC822.1">3.3.1</a>, <a class="iref" href="#RFC822"><b>12.2</b></a></li> 3026 <li class="indline1"><em>RFC959</em> <a class="iref" href="#rfc.xref.RFC959.1">1 .1</a>, <a class="iref" href="#RFC959"><b>12.2</b></a></li>2992 <li class="indline1"><em>RFC959</em> <a class="iref" href="#rfc.xref.RFC959.1">1</a>, <a class="iref" href="#RFC959"><b>12.2</b></a></li> 3027 2993 </ul> 3028 2994 </li> … … 3045 3011 <li class="indline1">URI scheme 3046 3012 <ul class="ind"> 3047 <li class="indline1">http <a class="iref" href="#rfc.iref.u.1"><b>3.2. 2</b></a></li>3048 <li class="indline1">https <a class="iref" href="#rfc.iref.u.2">3.2. 2</a></li>3013 <li class="indline1">http <a class="iref" href="#rfc.iref.u.1"><b>3.2.1</b></a></li> 3014 <li class="indline1">https <a class="iref" href="#rfc.iref.u.2">3.2.1</a></li> 3049 3015 </ul> 3050 3016 </li> … … 3059 3025 </li> 3060 3026 <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 3061 <li class="indline1"><em>WAIS</em> <a class="iref" href="#rfc.xref.WAIS.1">1 .1</a>, <a class="iref" href="#WAIS"><b>12.2</b></a></li>3027 <li class="indline1"><em>WAIS</em> <a class="iref" href="#rfc.xref.WAIS.1">1</a>, <a class="iref" href="#WAIS"><b>12.2</b></a></li> 3062 3028 </ul> 3063 3029 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r372 r374 229 229 <t> 230 230 The Hypertext Transfer Protocol (HTTP) is an application-level 231 protocol for distributed, collaborative, hypermedia information 232 systems. HTTP has been in use by the World-Wide Web global 233 information initiative since 1990. The first version of HTTP, commonly 234 referred to as HTTP/0.9, was a simple protocol for raw data transfer 235 across the Internet with only a single method and no metadata. 236 HTTP/1.0, as defined by <xref target="RFC1945"/>, improved 237 the protocol by allowing messages to be in the format of MIME-like 238 messages, containing metadata about the data transferred and 239 modifiers on the request/response semantics. However, HTTP/1.0 did 240 not sufficiently take into consideration the effects of hierarchical 241 proxies, caching, the need for persistent connections, or name-based 242 virtual hosts. In addition, the proliferation of incompletely-implemented 243 applications calling themselves "HTTP/1.0" necessitated a 244 protocol version change in order for two communicating applications 245 to determine each other's true capabilities. 246 </t> 247 <t> 248 This document is Part 1 of the seven-part specification that defines 249 the protocol referred to as "HTTP/1.1", obsoleting <xref target="RFC2616"/>. 250 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 251 requirements that enable reliable implementations and adding only 252 those new features that will either be safely ignored by an HTTP/1.0 253 recipient or only sent when communicating with a party advertising 254 compliance with HTTP/1.1. 255 Part 1 defines those aspects of HTTP/1.1 related to overall network 256 operation, message framing, interaction with transport protocols, and 257 URI schemes. 258 </t> 259 <t> 260 This document is currently disorganized in order to minimize the changes 261 between drafts and enable reviewers to see the smaller errata changes. 262 The next draft will reorganize the sections to better reflect the content. 263 In particular, the sections will be organized according to the typical 264 process of deciding when to use HTTP (URI schemes), overall network operation, 265 connection management, message framing, and generic message parsing. 266 The current mess reflects how widely dispersed these topics and associated 267 requirements had become in <xref target="RFC2616"/>. 268 </t> 269 270 <section title="Purpose" anchor="intro.purpose"> 271 <t> 272 Practical information systems require more functionality than simple 273 retrieval, including search, front-end update, and annotation. HTTP 274 allows an open-ended set of methods and headers that indicate the 275 purpose of a request <xref target="RFC2324"/>. It builds on the discipline of reference 276 provided by the Uniform Resource Identifier (URI) <xref target="RFC1630"/>, as a location 277 (URL) <xref target="RFC1738"/> or name (URN) <xref target="RFC1737"/>, for indicating the resource to which a 278 method is to be applied. Messages are passed in a format similar to 279 that used by Internet mail <xref target="RFC5322"/> as defined by the Multipurpose 280 Internet Mail Extensions (MIME) <xref target="RFC2045"/>. 281 </t> 282 <t> 283 HTTP is also used as a generic protocol for communication between 284 user agents and proxies/gateways to other Internet systems, including 285 those supported by the SMTP <xref target="RFC2821"/>, NNTP <xref target="RFC3977"/>, FTP <xref target="RFC959"/>, Gopher <xref target="RFC1436"/>, 286 and WAIS <xref target="WAIS"/> protocols. In this way, HTTP allows basic hypermedia 287 access to resources available from diverse applications. 288 </t> 289 </section> 231 request/response protocol that uses extensible semantics and MIME-like 232 message payloads for flexible interaction with network-based hypermedia 233 information systems. HTTP relies upon the Uniform Resource Identifier (URI) 234 standard <xref target="RFC3986"/> to indicate resource targets for 235 interaction and to identify other resources. 236 Messages are passed in a format similar to that used by Internet mail 237 <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions 238 (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences 239 between HTTP and MIME messages). 240 </t> 241 <t> 242 HTTP is also designed for use as a generic protocol for translating 243 communication to and from other Internet information systems, such as 244 USENET news services via NNTP <xref target="RFC3977"/>, 245 file services via FTP <xref target="RFC959"/>, 246 Gopher <xref target="RFC1436"/>, and WAIS <xref target="WAIS"/>. 247 HTTP proxies and gateways provide access to alternative information 248 services by translating their diverse protocols into a hypermedia 249 format that can be viewed and manipulated by clients in the same way 250 as HTTP services. 251 </t> 252 <t> 253 This document is Part 1 of the seven-part specification of HTTP, 254 defining the protocol referred to as "HTTP/1.1" and obsoleting 255 <xref target="RFC2616"/>. 256 Part 1 defines how clients determine when to use HTTP, the URI schemes 257 specific to HTTP-based resources, overall network operation with 258 transport protocol connection management, and HTTP message framing. 259 Our goal is to define all of the mechanisms necessary for HTTP message 260 handling that are independent of message semantics, thereby defining the 261 complete set of requirements for an HTTP message relay or generic 262 message parser. 263 </t> 290 264 291 265 <section title="Requirements" anchor="intro.requirements"> … … 697 671 <section title="Uniform Resource Identifiers" anchor="uri"> 698 672 <t> 699 URIs have been known by many names: WWW addresses, Universal Document 700 Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the 701 combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN) 702 <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are 703 simply formatted strings which identify--via name, location, or any 704 other characteristic--a resource. 705 </t> 706 707 <section title="General Syntax" anchor="general.syntax"> 708 <x:anchor-alias value="absoluteURI"/> 673 Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used in HTTP 674 to indicate the target of a request and to identify additional resources related 675 to that resource, the request, or the response. Each protocol element in HTTP 676 that allows a URI reference will indicate in its ABNF whether the element allows 677 only a URI in absolute form, any relative reference, or some limited subset of 678 the URI-reference grammar. Unless otherwise indicated, relative URI references 679 are to be parsed relative to the URI corresponding to the request target 680 (the base URI). 681 </t> 682 <x:anchor-alias value="URI-reference"/> 683 <x:anchor-alias value="absolute-URI"/> 709 684 <x:anchor-alias value="authority"/> 710 685 <x:anchor-alias value="fragment"/> 686 <x:anchor-alias value="path-abempty"/> 711 687 <x:anchor-alias value="path-absolute"/> 712 688 <x:anchor-alias value="port"/> 713 689 <x:anchor-alias value="query"/> 714 690 <x:anchor-alias value="relativeURI"/> 691 <x:anchor-alias value="relative-part"/> 715 692 <x:anchor-alias value="uri-host"/> 716 693 <t> 717 URIs in HTTP can be represented in absolute form or relative to some 718 known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two 719 forms are differentiated by the fact that absolute URIs always begin 720 with a scheme name followed by a colon. For definitive information on 721 URL syntax and semantics, see "Uniform Resource Identifiers (URI): 722 Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/> 723 and <xref target="RFC1808"/>). This specification adopts the 724 definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port", 725 "host", "abs_path", "query", and "authority" from that specification: 726 </t> 727 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="absoluteURI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="uri-host"/> 728 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> 729 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>> 730 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>> 731 <x:ref>path-absolute</x:ref> = <abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> 732 <x:ref>port</x:ref> = <port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> 733 <x:ref>query</x:ref> = <query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>> 734 <x:ref>relativeURI</x:ref> = <relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>> 735 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> 736 </artwork></figure> 737 <t> 738 HTTP does not place any a priori limit on the length of 694 This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port", 695 "host", "path-abempty", "path-absolute", "query", and "authority" from <xref target="RFC3986"/>: 696 </t> 697 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="relative-part"/> 698 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>> 699 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>> 700 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>> 701 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 702 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 703 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>> 704 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>> 705 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>> 706 707 <x:ref>relative-part</x:ref> = <relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>> 708 <x:ref>relativeURI</x:ref> = <x:ref>relative-part</x:ref> [ "?" <x:ref>query</x:ref> ] 709 </artwork></figure> 710 <t> 711 HTTP does not place an a priori limit on the length of 739 712 a URI. Servers &MUST; be able to handle the URI of any resource they 740 713 serve, and &SHOULD; be able to handle URIs of unbounded length if they … … 752 725 </list> 753 726 </t> 754 </section> 755 756 <section title="http URL" anchor="http.url"> 757 <x:anchor-alias value="http-URL"/> 727 728 <section title="http URI scheme" anchor="http.uri"> 729 <x:anchor-alias value="http-URI"/> 758 730 <iref item="http URI scheme" primary="true"/> 759 731 <iref item="URI scheme" subitem="http" primary="true"/> 760 732 <t> 761 733 The "http" scheme is used to locate network resources via the HTTP 762 protocol. This section defines the scheme-specific syntax and 763 semantics for http URLs. 764 </t> 765 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/> 766 <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] 767 [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]] 734 protocol. This section defines the syntax and semantics for identifiers 735 using the http or https URI schemes. 736 </t> 737 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/> 738 <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ] 768 739 </artwork></figure> 769 740 <t> … … 802 773 <t> 803 774 Characters other than those in the "reserved" set (see 804 <xref target="RFC 2396" x:fmt="," x:sec="2.2"/>) are equivalent to their775 <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their 805 776 ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding. 806 777 </t> … … 1449 1420 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/> 1450 1421 <x:ref>Request-URI</x:ref> = "*" 1451 / <x:ref>absolute URI</x:ref>1422 / <x:ref>absolute-URI</x:ref> 1452 1423 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] ) 1453 1424 / <x:ref>authority</x:ref> … … 1464 1435 </artwork></figure> 1465 1436 <t> 1466 The absolute URI form is &REQUIRED; when the request is being made to a1437 The absolute-URI form is &REQUIRED; when the request is being made to a 1467 1438 proxy. The proxy is requested to forward the request or service it 1468 1439 from a valid cache, and return the response. Note that the proxy &MAY; 1469 1440 forward the request on to another proxy or directly to the server 1470 specified by the absolute URI. In order to avoid request loops, a1441 specified by the absolute-URI. In order to avoid request loops, a 1471 1442 proxy &MUST; be able to recognize all of its server names, including 1472 1443 any aliases, local variations, and the numeric IP address. An example … … 1477 1448 </artwork></figure> 1478 1449 <t> 1479 To allow for transition to absolute URIs in all requests in future1480 versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute URI1450 To allow for transition to absolute-URIs in all requests in future 1451 versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI 1481 1452 form in requests, even though HTTP/1.1 clients will only generate 1482 1453 them in requests to proxies. … … 1488 1459 The most common form of Request-URI is that used to identify a 1489 1460 resource on an origin server or gateway. In this case the absolute 1490 path of the URI &MUST; be transmitted (see <xref target=" general.syntax"/>, path-absolute) as1461 path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as 1491 1462 the Request-URI, and the network location of the URI (authority) &MUST; 1492 1463 be transmitted in a Host header field. For example, a client wishing … … 1506 1477 <t> 1507 1478 The Request-URI is transmitted in the format specified in 1508 <xref target=" general.syntax"/>. If the Request-URI is encoded using the1479 <xref target="http.uri"/>. If the Request-URI is encoded using the 1509 1480 "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding 1510 (<xref target="RFC 2396" x:fmt="," x:sec="2.4.1"/>), the origin server1481 (<xref target="RFC3986" x:fmt="," x:sec="2.4"/>), the origin server 1511 1482 &MUST; decode the Request-URI in order to 1512 1483 properly interpret the request. Servers &SHOULD; respond to invalid … … 1548 1519 resource on an HTTP/1.1 request: 1549 1520 <list style="numbers"> 1550 <t>If Request-URI is an absolute URI, the host is part of the1521 <t>If Request-URI is an absolute-URI, the host is part of the 1551 1522 Request-URI. Any Host header field value in the request &MUST; be 1552 1523 ignored.</t> 1553 <t>If the Request-URI is not an absolute URI, and the request includes1524 <t>If the Request-URI is not an absolute-URI, and the request includes 1554 1525 a Host header field, the host is determined by the Host header 1555 1526 field value.</t> … … 2246 2217 number of the resource being requested, as obtained from the original 2247 2218 URI given by the user or referring resource (generally an HTTP URL, 2248 as described in <xref target="http.ur l"/>). The Host field value &MUST; represent2219 as described in <xref target="http.uri"/>). The Host field value &MUST; represent 2249 2220 the naming authority of the origin server or gateway given by the 2250 2221 original URL. This allows the origin server or gateway to … … 2254 2225 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/> 2255 2226 <x:ref>Host</x:ref> = "Host" ":" <x:ref>OWS</x:ref> <x:ref>Host-v</x:ref> 2256 <x:ref>Host-v</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.ur l"/>2227 <x:ref>Host-v</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/> 2257 2228 </artwork></figure> 2258 2229 <t> … … 2677 2648 The entry for the "http" URI Scheme in the registry located at 2678 2649 <eref target="http://www.iana.org/assignments/uri-schemes.html"/> 2679 should be updated to point to <xref target="http.ur l"/> of this document2650 should be updated to point to <xref target="http.uri"/> of this document 2680 2651 (see <xref target="RFC4395"/>). 2681 2652 </t> … … 2976 2947 <section title="Acknowledgments" anchor="ack"> 2977 2948 <t> 2978 This specification makes heavy use of the augmented BNF and generic2979 constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it2980 reuses many of the definitions provided by Nathaniel Borenstein and2981 Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this2982 specification will help reduce past confusion over the relationship2983 between HTTP and Internet mail message formats.2984 </t>2985 <t>2986 2949 HTTP has evolved considerably over the years. It has 2987 2950 benefited from a large and active developer community--the many … … 3031 2994 discovery of many of the problems that this document attempts to 3032 2995 rectify. 2996 </t> 2997 <t> 2998 This specification makes heavy use of the augmented BNF and generic 2999 constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it 3000 reuses many of the definitions provided by Nathaniel Borenstein and 3001 Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this 3002 specification will help reduce past confusion over the relationship 3003 between HTTP and Internet mail message formats. 3033 3004 </t> 3034 3005 </section> … … 3305 3276 </reference> 3306 3277 3307 <reference anchor="RFC2396"> 3308 <front> 3309 <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title> 3310 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3311 <organization abbrev="MIT/LCS">World Wide Web Consortium</organization> 3312 <address><email>timbl@w3.org</email></address> 3313 </author> 3314 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3315 <organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization> 3316 <address><email>fielding@ics.uci.edu</email></address> 3317 </author> 3318 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 3319 <organization abbrev="Xerox Corporation">Xerox PARC</organization> 3320 <address><email>masinter@parc.xerox.com</email></address> 3321 </author> 3322 <date month="August" year="1998"/> 3323 </front> 3324 <seriesInfo name="RFC" value="2396"/> 3278 <reference anchor="RFC3986"> 3279 <front> 3280 <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title> 3281 <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'> 3282 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 3283 <address> 3284 <email>timbl@w3.org</email> 3285 <uri>http://www.w3.org/People/Berners-Lee/</uri> 3286 </address> 3287 </author> 3288 <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'> 3289 <organization abbrev="Day Software">Day Software</organization> 3290 <address> 3291 <email>fielding@gbiv.com</email> 3292 <uri>http://roy.gbiv.com/</uri> 3293 </address> 3294 </author> 3295 <author initials='L.' surname='Masinter' fullname='Larry Masinter'> 3296 <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization> 3297 <address> 3298 <email>LMM@acm.org</email> 3299 <uri>http://larry.masinter.net/</uri> 3300 </address> 3301 </author> 3302 <date month='January' year='2005'></date> 3303 </front> 3304 <seriesInfo name="RFC" value="3986"/> 3305 <seriesInfo name="STD" value="66"/> 3325 3306 </reference> 3326 3307 … … 3462 3443 </reference> 3463 3444 3464 <reference anchor="RFC1630">3465 <front>3466 <title abbrev="URIs in WWW">Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web</title>3467 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">3468 <organization>CERN, World-Wide Web project</organization>3469 <address><email>timbl@info.cern.ch</email></address>3470 </author>3471 <date month="June" year="1994"/>3472 </front>3473 <seriesInfo name="RFC" value="1630"/>3474 </reference>3475 3476 <reference anchor="RFC1737">3477 <front>3478 <title abbrev="Requirements for Uniform Resource Names">Functional Requirements for Uniform Resource Names</title>3479 <author initials="L." surname="Masinter" fullname="Larry Masinter">3480 <organization>Xerox Palo Alto Research Center</organization>3481 <address><email>masinter@parc.xerox.com</email></address>3482 </author>3483 <author initials="K." surname="Sollins" fullname="Karen Sollins">3484 <organization>MIT Laboratory for Computer Science</organization>3485 <address><email>sollins@lcs.mit.edu</email></address>3486 </author>3487 <date month="December" year="1994"/>3488 </front>3489 <seriesInfo name="RFC" value="1737"/>3490 </reference>3491 3492 <reference anchor="RFC1738">3493 <front>3494 <title>Uniform Resource Locators (URL)</title>3495 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">3496 <organization>CERN, World-Wide Web project</organization>3497 <address><email>timbl@info.cern.ch</email></address>3498 </author>3499 <author initials="L." surname="Masinter" fullname="Larry Masinter">3500 <organization>Xerox PARC</organization>3501 <address><email>masinter@parc.xerox.com</email></address>3502 </author>3503 <author initials="M." surname="McCahill" fullname="Mark McCahill">3504 <organization>University of Minnesota, Computer and Information Services</organization>3505 <address><email>mpm@boombox.micro.umn.edu</email></address>3506 </author>3507 <date month="December" year="1994"/>3508 </front>3509 <seriesInfo name="RFC" value="1738"/>3510 </reference>3511 3512 <reference anchor="RFC1808">3513 <front>3514 <title>Relative Uniform Resource Locators</title>3515 <author initials="R." surname="Fielding" fullname="Roy T. Fielding">3516 <organization>University of California Irvine, Department of Information and Computer Science</organization>3517 <address><email>fielding@ics.uci.edu</email></address>3518 </author>3519 <date month="June" year="1995"/>3520 </front>3521 <seriesInfo name="RFC" value="1808"/>3522 </reference>3523 3524 3445 <reference anchor="RFC1900"> 3525 3446 <front> … … 3626 3547 </reference> 3627 3548 3628 <reference anchor="RFC2324">3629 <front>3630 <title abbrev="HTCPCP/1.0">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>3631 <author initials="L." surname="Masinter" fullname="Larry Masinter">3632 <organization>Xerox Palo Alto Research Center</organization>3633 <address><email>masinter@parc.xerox.com</email></address>3634 </author>3635 <date month="April" day="1" year="1998"/>3636 </front>3637 <seriesInfo name="RFC" value="2324"/>3638 </reference>3639 3640 3549 <reference anchor="RFC2616"> 3641 3550 <front> … … 3684 3593 </front> 3685 3594 <seriesInfo name='RFC' value='2818' /> 3686 </reference>3687 3688 <reference anchor="RFC2821">3689 <front>3690 <title>Simple Mail Transfer Protocol</title>3691 <author initials="J." surname="Klensin" fullname="J. Klensin">3692 <organization>AT&T Laboratories</organization>3693 <address><email>klensin@research.att.com</email></address>3694 </author>3695 <date year="2001" month="April"/>3696 </front>3697 <seriesInfo name="RFC" value="2821"/>3698 3595 </reference> 3699 3596 … … 3946 3843 <section title="Compatibility with Previous Versions" anchor="compatibility"> 3947 3844 <t> 3845 HTTP has been in use by the World-Wide Web global information initiative 3846 since 1990. The first version of HTTP, later referred to as HTTP/0.9, 3847 was a simple protocol for hypertext data transfer across the Internet 3848 with only a single method and no metadata. 3849 HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request 3850 methods and MIME-like messaging that could include metadata about the data 3851 transferred and modifiers on the request/response semantics. However, 3852 HTTP/1.0 did not sufficiently take into consideration the effects of 3853 hierarchical proxies, caching, the need for persistent connections, or 3854 name-based virtual hosts. The proliferation of incompletely-implemented 3855 applications calling themselves "HTTP/1.0" further necessitated a 3856 protocol version change in order for two communicating applications 3857 to determine each other's true capabilities. 3858 </t> 3859 <t> 3860 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3861 requirements that enable reliable implementations, adding only 3862 those new features that will either be safely ignored by an HTTP/1.0 3863 recipient or only sent when communicating with a party advertising 3864 compliance with HTTP/1.1. 3865 </t> 3866 <t> 3948 3867 It is beyond the scope of a protocol specification to mandate 3949 3868 compliance with previous versions. HTTP/1.1 was deliberately … … 4115 4034 </t> 4116 4035 <t> 4117 Fix BNF to add query, as the abs_path production in4118 <xref x:sec="3" x:fmt="of" target="RFC2396"/> doesn't define it.4036 Update use of abs_path production from RFC1808 to the path-absolute + query 4037 components of RFC3986. 4119 4038 (<xref target="request-uri"/>) 4120 4039 </t> … … 4524 4443 Add rules for terms imported from URI spec ("absoluteURI", "authority", 4525 4444 "path-absolute", "port", "query", "relativeURI", "host) -- these will 4526 have to be updated when switching over to RFC3986. 4445 have to be updated when switching over to RFC3986. 4527 4446 </t> 4528 4447 <t> … … 4631 4550 <list style="symbols"> 4632 4551 <t> 4552 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/34"/>: 4553 "Out-of-date reference for URIs" 4554 </t> 4555 <t> 4633 4556 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>: 4634 4557 "RFC 2822 is updated by RFC 5322" -
draft-ietf-httpbis/latest/p2-semantics.html
r371 r374 683 683 <p id="rfc.section.2.p.4"> The ABNF rules below are defined in other parts:</p> 684 684 </div> 685 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute URI</a> = <absoluteURI, 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#general.syntax" title="General Syntax">Section 3.2.1</a>>686 <a href="#abnf.dependencies" class="smpl">fragment</a> = <fragment, 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# general.syntax" title="General Syntax">Section 3.2.1</a>>687 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, 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.host" title="Host">Section 8.4</a>>685 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 3.2</a>> 686 <a href="#abnf.dependencies" class="smpl">fragment</a> = <fragment, 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 3.2</a>> 687 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 3.2</a>> 688 688 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, 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#full.date" title="Full Date">Section 3.3.1</a>> 689 689 <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 3.5</a>> 690 <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, 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# general.syntax" title="General Syntax">Section 3.2.1</a>>690 <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, 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 3.2</a>> 691 691 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a>> 692 692 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> … … 926 926 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". 927 927 </p> 928 <p id="rfc.section.8.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absolute URI for which928 <p id="rfc.section.8.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absolute-URI for which 929 929 request forwarding is permitted, the proxy <em class="bcp14">MUST</em> check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy <em class="bcp14">MUST NOT</em> forward the message; instead, the proxy <em class="bcp14">SHOULD</em> respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy <em class="bcp14">MUST</em> decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded 930 930 request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. … … 1527 1527 </p> 1528 1528 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.location" class="smpl">Location</a> = "Location" ":" <a href="#notation" class="smpl">OWS</a> <a href="#header.location" class="smpl">Location-v</a> 1529 <a href="#header.location" class="smpl">Location-v</a> = <a href="#abnf.dependencies" class="smpl">absolute URI</a> [ "#" <a href="#abnf.dependencies" class="smpl">fragment</a> ]1529 <a href="#header.location" class="smpl">Location-v</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> [ "#" <a href="#abnf.dependencies" class="smpl">fragment</a> ] 1530 1530 </pre><p id="rfc.section.10.4.p.3">An example is:</p> 1531 1531 <div id="rfc.figure.u.19"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html … … 1567 1567 </p> 1568 1568 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#header.referer" class="smpl">Referer</a> = "Referer" ":" <a href="#notation" class="smpl">OWS</a> <a href="#header.referer" class="smpl">Referer-v</a> 1569 <a href="#header.referer" class="smpl">Referer-v</a> = <a href="#abnf.dependencies" class="smpl">absolute URI</a> / <a href="#abnf.dependencies" class="smpl">relativeURI</a>1569 <a href="#header.referer" class="smpl">Referer-v</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">relativeURI</a> 1570 1570 </pre><p id="rfc.section.10.6.p.3">Example:</p> 1571 1571 <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html … … 2532 2532 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a></li> 2533 2533 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.23">9.5.6</a></li> 2534 <li class="indline1"><em>Section 3.2 .1</em> <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.15">2</a></li>2534 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a>, <a class="iref" href="#rfc.xref.Part1.15">2</a></li> 2535 2535 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.13">2</a></li> 2536 2536 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part1.14">2</a>, <a class="iref" href="#rfc.xref.Part1.25">10.8</a>, <a class="iref" href="#rfc.xref.Part1.27">10.9</a></li> 2537 2537 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.19">7</a></li> 2538 2538 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.22">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">10.2</a></li> 2539 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.1 2">2</a>, <a class="iref" href="#rfc.xref.Part1.17">4</a></li>2539 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.17">4</a></li> 2540 2540 <li class="indline1"><em>Section 8.8</em> <a class="iref" href="#rfc.xref.Part1.16">2</a>, <a class="iref" href="#rfc.xref.Part1.18">4</a></li> 2541 2541 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1.20">8.8</a>, <a class="iref" href="#rfc.xref.Part1.26">10.8</a>, <a class="iref" href="#rfc.xref.Part1.28">A.2</a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r371 r374 24 24 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 25 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 <!ENTITY general-syntax "<xref target='Part1' x:rel='#general.syntax' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">27 26 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 27 <!ENTITY full-date "<xref target='Part1' x:rel='#full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 313 312 </artwork></figure> 314 313 <t anchor="abnf.dependencies"> 315 <x:anchor-alias value="absolute URI"/>314 <x:anchor-alias value="absolute-URI"/> 316 315 <x:anchor-alias value="Accept"/> 317 316 <x:anchor-alias value="Accept-Charset"/> … … 341 340 </t> 342 341 <figure><!--Part1--><artwork type="abnf2616"> 343 <x:ref>absolute URI</x:ref> = <absoluteURI, defined in &general-syntax;>344 <x:ref>fragment</x:ref> = <fragment, defined in & general-syntax;>345 <x:ref>Host</x:ref> = <Host, defined in & header-host;>342 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> 343 <x:ref>fragment</x:ref> = <fragment, defined in &uri;> 344 <x:ref>Host</x:ref> = <Host, defined in &uri;> 346 345 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> 347 346 <x:ref>product</x:ref> = <product, defined in &product-tokens;> 348 <x:ref>relativeURI</x:ref> = <relativeURI, defined in & general-syntax;>347 <x:ref>relativeURI</x:ref> = <relativeURI, defined in &uri;> 349 348 <x:ref>TE</x:ref> = <TE, defined in &header-te;> 350 349 </artwork></figure> … … 748 747 The Max-Forwards request-header field &MAY; be used to target a 749 748 specific proxy in the request chain. When a proxy receives an OPTIONS 750 request on an absolute URI for which request forwarding is permitted,749 request on an absolute-URI for which request forwarding is permitted, 751 750 the proxy &MUST; check for a Max-Forwards field. If the Max-Forwards 752 751 field-value is zero ("0"), the proxy &MUST-NOT; forward the message; … … 1948 1947 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/><iref primary="true" item="Grammar" subitem="Location-v"/> 1949 1948 <x:ref>Location</x:ref> = "Location" ":" <x:ref>OWS</x:ref> <x:ref>Location-v</x:ref> 1950 <x:ref>Location-v</x:ref> = <x:ref>absolute URI</x:ref> [ "#" <x:ref>fragment</x:ref> ]1949 <x:ref>Location-v</x:ref> = <x:ref>absolute-URI</x:ref> [ "#" <x:ref>fragment</x:ref> ] 1951 1950 </artwork></figure> 1952 1951 <t> … … 2030 2029 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/><iref primary="true" item="Grammar" subitem="Referer-v"/> 2031 2030 <x:ref>Referer</x:ref> = "Referer" ":" <x:ref>OWS</x:ref> <x:ref>Referer-v</x:ref> 2032 <x:ref>Referer-v</x:ref> = <x:ref>absolute URI</x:ref> / <x:ref>relativeURI</x:ref>2031 <x:ref>Referer-v</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>relativeURI</x:ref> 2033 2032 </artwork></figure> 2034 2033 <t> -
draft-ietf-httpbis/latest/p3-payload.html
r371 r374 642 642 <p id="rfc.section.2.p.4"> The ABNF rules below are defined in other parts:</p> 643 643 </div> 644 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute URI</a> = <absoluteURI, 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#general.syntax" title="General Syntax">Section 3.2.1</a>>644 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 3.2</a>> 645 645 <a href="#abnf.dependencies" class="smpl">Content-Length</a> = <Content-Length, 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#header.content-length" title="Content-Length">Section 8.2</a>> 646 <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, 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# general.syntax" title="General Syntax">Section 3.2.1</a>>646 <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, 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 3.2</a>> 647 647 <a href="#abnf.dependencies" class="smpl">message-header</a> = <message-header, 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#message.headers" title="Message Headers">Section 4.2</a>> 648 648 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Last-Modified</a> = <Last-Modified, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 7.6</a>> … … 1205 1205 <a href="#header.content-location" class="smpl">Content-Location-v</a> 1206 1206 <a href="#header.content-location" class="smpl">Content-Location-v</a> = 1207 <a href="#abnf.dependencies" class="smpl">absolute URI</a> / <a href="#abnf.dependencies" class="smpl">relativeURI</a>1207 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">relativeURI</a> 1208 1208 </pre><p id="rfc.section.6.7.p.3">The value of Content-Location also defines the base URI for the entity.</p> 1209 1209 <p id="rfc.section.6.7.p.4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of … … 1918 1918 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a></li> 1919 1919 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a></li> 1920 <li class="indline1"><em>Section 3.2 .1</em> <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a></li>1920 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a></li> 1921 1921 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.12">2</a></li> 1922 1922 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.14">4.2</a></li> -
draft-ietf-httpbis/latest/p3-payload.xml
r371 r374 28 28 <!ENTITY message-length "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 29 <!ENTITY message-headers "<xref target='Part1' x:rel='#message.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 <!ENTITY general-syntax "<xref target='Part1' x:rel='#general.syntax' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">31 30 <!ENTITY multipart-byteranges "<xref target='Part5' x:rel='#internet.media.type.multipart.byteranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 ]> 33 33 <?rfc toc="yes" ?> … … 275 275 </artwork></figure> 276 276 <t anchor="abnf.dependencies"> 277 <x:anchor-alias value="absolute URI"/>277 <x:anchor-alias value="absolute-URI"/> 278 278 <x:anchor-alias value="Allow"/> 279 279 <x:anchor-alias value="Content-Length"/> … … 286 286 </t> 287 287 <figure><!--Part1--><artwork type="abnf2616"> 288 <x:ref>absolute URI</x:ref> = <absoluteURI, defined in &general-syntax;>288 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> 289 289 <x:ref>Content-Length</x:ref> = <Content-Length, defined in &header-content-length;> 290 <x:ref>relativeURI</x:ref> = <relativeURI, defined in & general-syntax;>290 <x:ref>relativeURI</x:ref> = <relativeURI, defined in &uri;> 291 291 <x:ref>message-header</x:ref> = <message-header, defined in &message-headers;> 292 292 </artwork></figure> … … 1381 1381 <x:ref>Content-Location-v</x:ref> 1382 1382 <x:ref>Content-Location-v</x:ref> = 1383 <x:ref>absolute URI</x:ref> / <x:ref>relativeURI</x:ref>1383 <x:ref>absolute-URI</x:ref> / <x:ref>relativeURI</x:ref> 1384 1384 </artwork></figure> 1385 1385 <t> -
draft-ietf-httpbis/latest/p6-cache.html
r371 r374 730 730 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = <field-name, 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#message.headers" title="Message Headers">Section 4.2</a>> 731 731 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, 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#full.date" title="Full Date">Section 3.3.1</a>> 732 <a href="#abnf.dependencies" class="smpl">port</a> = <port, 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# general.syntax" title="General Syntax">Section 3.2.1</a>>732 <a href="#abnf.dependencies" class="smpl">port</a> = <port, 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 3.2</a>> 733 733 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, 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.via" title="Via">Section 8.9</a>> 734 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, 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# general.syntax" title="General Syntax">Section 3.2.1</a>>734 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, 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 3.2</a>> 735 735 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="caching.overview" href="#caching.overview">Overview</a></h1> 736 736 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="cache.correctness" href="#cache.correctness">Cache Correctness</a></h2> … … 2155 2155 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a></li> 2156 2156 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a></li> 2157 <li class="indline1"><em>Section 3.2 .1</em> <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.13">2</a></li>2157 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.13">2</a></li> 2158 2158 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.19">16.3</a></li> 2159 2159 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.18">8</a></li> -
draft-ietf-httpbis/latest/p6-cache.xml
r371 r374 17 17 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 18 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 <!ENTITY general-syntax "<xref target='Part1' x:rel='#general.syntax' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">20 19 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 20 <!ENTITY conditional "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 31 30 <!ENTITY safe-methods "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 31 <!ENTITY server-driven-negotiation "<xref target='Part3' x:rel='#server-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 33 ]> 34 34 <?rfc toc="yes" ?> … … 459 459 <x:ref>field-name</x:ref> = <field-name, defined in &message-headers;> 460 460 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> 461 <x:ref>port</x:ref> = <port, defined in & general-syntax;>461 <x:ref>port</x:ref> = <port, defined in &uri;> 462 462 <x:ref>pseudonym</x:ref> = <pseudonym, defined in &header-via;> 463 <x:ref>uri-host</x:ref> = <uri-host, defined in & general-syntax;>463 <x:ref>uri-host</x:ref> = <uri-host, defined in &uri;> 464 464 </artwork></figure> 465 465 </section>
Note: See TracChangeset
for help on using the changeset viewer.