![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 97 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 23/12/07 13:22:38 (13 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (24 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r96 r97 616 616 <p id="rfc.section.1.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information 617 617 systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred 618 to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945<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 metainformation about the618 to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. 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 metainformation about the 619 619 data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration 620 620 the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation … … 838 838 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h2> 839 839 <p id="rfc.section.2.1.p.1">All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar 840 to that used by RFC 822<a href="#RFC822" id="rfc.xref.RFC822.2"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes840 to that used by <a href="#RFC822" id="rfc.xref.RFC822.2"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes 841 841 the following constructs: 842 842 </p> … … 934 934 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span> LWS = [CRLF] 1*( SP | HT ) 935 935 </pre><p id="rfc.section.2.2.p.7">The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message 936 parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[ISO-8859]</cite></a> only when encoded according to the rules of RFC 2047<a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.936 parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[ISO-8859]</cite></a> only when encoded according to the rules of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>. 937 937 </p> 938 938 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span> TEXT = <any OCTET except CTLs, … … 971 971 when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may 972 972 add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format 973 of a message within the protocol is changed. See RFC 2145<a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation.973 of a message within the protocol is changed. See <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation. 974 974 </p> 975 975 <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> … … 980 980 <p id="rfc.section.3.1.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this 981 981 specification <em class="bcp14">SHOULD</em> use an HTTP-Version of "HTTP/1.1" in their messages, and <em class="bcp14">MUST</em> do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, 982 see RFC 2145<a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>.982 see <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. 983 983 </p> 984 984 <p id="rfc.section.3.1.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p> … … 987 987 the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior. 988 988 </p> 989 <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.989 <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request. 990 990 </p> 991 991 <p id="rfc.section.3.1.p.9"> </p> … … 1001 1001 <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 1002 1002 a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers 1003 (URI): Generic Syntax and Semantics," RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces RFCs 1738 <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and RFC 1808<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", "relativeURI", "port", "host","abs_path",1003 (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", "relativeURI", "port", "host","abs_path", 1004 1004 "rel_path", and "authority" from that specification. 1005 1005 </p> … … 1018 1018 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.25"></span>http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 1019 1019 </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 1020 listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<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 RFC 1900<a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the abs_path 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.1020 listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<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 abs_path 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. 1021 1021 </p> 1022 1022 <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> … … 1031 1031 <li>An empty abs_path is equivalent to an abs_path of "/".</li> 1032 1032 </ul> 1033 <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see RFC 2396<a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.1033 <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.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>) are equivalent to their ""%" HEX HEX" encoding. 1034 1034 </p> 1035 1035 <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p> … … 1043 1043 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1044 1044 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1045 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to RFC 822<a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers1045 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers 1046 1046 that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix B</a> for further information. 1047 1047 </p> … … 1168 1168 <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1169 1169 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.51"></span> HTTP-message = Request | Response ; HTTP/1.1 messages 1170 </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 RFC 822<a href="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header1170 </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="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header 1171 1171 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1172 1172 fields, and possibly a message-body. … … 1184 1184 </p> 1185 1185 <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> 1186 <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.2"><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.3"><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 3.1</a> of <a href="#Part3" id="rfc.xref.Part3.10"><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/rfc822#section-3.1" id="rfc.xref.RFC822.5">Section 3.1</a> of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The1186 <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.2"><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.3"><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 3.1</a> of <a href="#Part3" id="rfc.xref.Part3.10"><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/rfc822#section-3.1">Section 3.1</a> of <a href="#RFC822" id="rfc.xref.RFC822.5"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The 1187 1187 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 1188 1188 each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when … … 1409 1409 servers and causing congestion on the Internet. The use of inline images and other associated data often require a client 1410 1410 to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results 1411 from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 ( RFC 2068) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.1411 from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (<cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.2">RFC 2068</cite>) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. 1412 1412 </p> 1413 1413 <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p> … … 1466 1466 to. Each persistent connection applies to only one transport link. 1467 1467 </p> 1468 <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).1468 <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients). 1469 1469 </p> 1470 1470 <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 1524 1524 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" 1525 1525 expectation, and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this 1526 rule: for compatibility with RFC 2068, a server <em class="bcp14">MAY</em> send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header1526 rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header 1527 1527 field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays 1528 1528 associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with … … 1634 1634 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.date" href="#header.date">Date</a></h2> 1635 1635 <p id="rfc.section.8.3.p.1">The Date general-header field represents the date and time at which the message was originated, having the same semantics 1636 as orig-date in RFC 822. 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.1636 as orig-date in <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</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. 1637 1637 </p> 1638 1638 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span> Date = "Date" ":" HTTP-date … … 1684 1684 requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field. 1685 1685 </p> 1686 <p id="rfc.section.8.4.p.6">See sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">D.1.1</a> for other requirements relating to Host.1686 <p id="rfc.section.8.4.p.6">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">D.1.1</a> for other requirements relating to Host. 1687 1687 </p> 1688 1688 <div id="rfc.iref.t.2"></div> … … 1797 1797 <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a> <a id="header.via" href="#header.via">Via</a></h2> 1798 1798 <p id="rfc.section.8.9.p.1">The Via general-header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server 1799 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822<a href="#RFC822" id="rfc.xref.RFC822.7"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities1799 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of <a href="#RFC822" id="rfc.xref.RFC822.7"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 1800 1800 of all senders along the request/response chain. 1801 1801 </p> … … 1905 1905 <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p> 1906 1906 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1907 <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 RFC 822<a href="#RFC822" id="rfc.xref.RFC822.8"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</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 and1907 <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="#RFC822" id="rfc.xref.RFC822.8"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</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 1908 1908 Internet mail message formats. 1909 1909 </p> … … 2241 2241 <p id="rfc.section.D.p.3">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the 2242 2242 server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described 2243 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1" id="rfc.xref.RFC2068.3">Section 19.7.1</a> of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.2243 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.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2244 2244 </p> 2245 2245 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2> … … 2281 2281 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 8.1</a>. 2282 2282 </p> 2283 <p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in RFC 2284 2068. <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> 2283 <p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2285 2284 </p> 2286 2285 <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> 2287 2286 <p id="rfc.section.D.3.p.1">This specification has been carefully audited to correct and disambiguate key word usage; RFC 2068 had many problems in respect 2288 to the conventions laid out in RFC 2119<a href="#RFC2119" id="rfc.xref.RFC2119.2"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.2287 to the conventions laid out in <a href="#RFC2119" id="rfc.xref.RFC2119.2"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 2289 2288 </p> 2290 2289 <p id="rfc.section.D.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow … … 2292 2291 computed. 2293 2292 </p> 2294 <p id="rfc.section.D.3.p.3">The use and interpretation of HTTP version numbers has been clarified by RFC 2145. Require proxies to upgrade requests to2295 highest protocol version they support to deal with problems discovered in HTTP/1.0implementations (<a href="#http.version" title="HTTP Version">Section 3.1</a>)2293 <p id="rfc.section.D.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 2294 implementations (<a href="#http.version" title="HTTP Version">Section 3.1</a>) 2296 2295 </p> 2297 2296 <p id="rfc.section.D.3.p.4">Proxies should be able to add Content-Length when appropriate.</p> … … 2540 2539 <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</b></a></li> 2541 2540 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">2.2</a>, <a class="iref" href="#RFC2047"><b>12</b></a></li> 2542 <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. 3</a>, <a class="iref" href="#RFC2068"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">D</a>, <a class="iref" href="#rfc.xref.RFC2068.4">D</a>, <a class="iref" href="#rfc.xref.RFC2068.5">D.2</a><ul class="ind">2543 <li class="indline1"><em>Section 19.7.1</em> <a class="iref" href="#rfc.xref.RFC2068. 3">D</a></li>2541 <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="#RFC2068"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2068.5">D</a>, <a class="iref" href="#rfc.xref.RFC2068.6">D.2</a><ul class="ind"> 2542 <li class="indline1"><em>Section 19.7.1</em> <a class="iref" href="#rfc.xref.RFC2068.5">D</a></li> 2544 2543 </ul> 2545 2544 </li> 2546 2545 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">D.3</a></li> 2547 <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</b></a> </li>2546 <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</b></a>, <a class="iref" href="#rfc.xref.RFC2145.3">D.3</a></li> 2548 2547 <li class="indline1"><em>RFC2324</em> <a class="iref" href="#rfc.xref.RFC2324.1">1.1</a>, <a class="iref" href="#RFC2324"><b>12</b></a></li> 2549 2548 <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.3</a>, <a class="iref" href="#rfc.xref.RFC2396.3">5.1.2</a>, <a class="iref" href="#RFC2396"><b>12</b></a></li> … … 2552 2551 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#RFC4288"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li> 2553 2552 <li class="indline1"><em>RFC821</em> <a class="iref" href="#rfc.xref.RFC821.1">1.1</a>, <a class="iref" href="#RFC821"><b>12</b></a></li> 2554 <li class="indline1"><em>RFC822</em> <a class="iref" href="#rfc.xref.RFC822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC822.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC822.3">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC822.4">4.1</a>, <a class="iref" href="#rfc.xref.RFC822.5">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.6"> 4.2</a>, <a class="iref" href="#rfc.xref.RFC822.7">8.9</a>, <a class="iref" href="#rfc.xref.RFC822.8">11</a>, <a class="iref" href="#RFC822"><b>12</b></a><ul class="ind">2553 <li class="indline1"><em>RFC822</em> <a class="iref" href="#rfc.xref.RFC822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC822.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC822.3">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC822.4">4.1</a>, <a class="iref" href="#rfc.xref.RFC822.5">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.6">8.3</a>, <a class="iref" href="#rfc.xref.RFC822.7">8.9</a>, <a class="iref" href="#rfc.xref.RFC822.8">11</a>, <a class="iref" href="#RFC822"><b>12</b></a><ul class="ind"> 2555 2554 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.RFC822.5">4.2</a></li> 2556 2555 </ul>
Note: See TracChangeset
for help on using the changeset viewer.
