Ignore:
Timestamp:
Dec 23, 2007, 5:22:38 AM (12 years ago)
Author:
julian.reschke@…
Message:

Cleanup references after switch to symbolic references (removing duplicated RFC numbers), clean up some of the references XML code.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r96 r97  
    616616      <p id="rfc.section.1.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information
    617617         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 the
     618         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
    619619         data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration
    620620         the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation
     
    838838      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h2>
    839839      <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 includes
     840         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
    841841         the following constructs:
    842842      </p>
     
    934934      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span>    LWS            = [CRLF] 1*( SP | HT )
    935935</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>.
    937937      </p>
    938938      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span>    TEXT           = &lt;any OCTET except CTLs,
     
    971971         when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may
    972972         add to the message semantics and imply additional capabilities of the sender. The &lt;major&gt; 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.
    974974      </p>
    975975      <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>
     
    980980      <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
    981981         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>.
    983983      </p>
    984984      <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>
     
    987987         the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior.
    988988      </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.
    990990      </p>
    991991      <p id="rfc.section.3.1.p.9"> </p>
     
    10011001      <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
    10021002         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",
    10041004         "rel_path", and "authority" from that specification.
    10051005      </p>
     
    10181018      <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 ]]
    10191019</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&nbsp;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&nbsp;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&nbsp;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&nbsp;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.
    10211021      </p>
    10221022      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
     
    10311031         <li>An empty abs_path is equivalent to an abs_path of "/".</li>
    10321032      </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.
    10341034      </p>
    10351035      <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p>
     
    10431043   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    10441044   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 servers
     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 <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
    10461046         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&nbsp;B</a> for further information.
    10471047      </p>
     
    11681168      <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p>
    11691169      <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&nbsp;5</a>) and Response (<a href="#response" title="Response">Section&nbsp;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 header
     1170</pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section&nbsp;5</a>) and Response (<a href="#response" title="Response">Section&nbsp;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
    11711171         fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header
    11721172         fields, and possibly a message-body.
     
    11841184      </p>
    11851185      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<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&nbsp;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. The
     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&nbsp;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
    11871187         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
    11881188         each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when
     
    14091409         servers and causing congestion on the Internet. The use of inline images and other associated data often require a client
    14101410         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>.
    14121412      </p>
    14131413      <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
     
    14661466         to. Each persistent connection applies to only one transport link.
    14671467      </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).
    14691469      </p>
    14701470      <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
     
    15241524         <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"
    15251525            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-header
     1526            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
    15271527            field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays
    15281528            associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with
     
    16341634      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    16351635      <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&nbsp;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&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    16371637      </p>
    16381638      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span>    Date  = "Date" ":" HTTP-date
     
    16841684         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.
    16851685      </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.
    16871687      </p>
    16881688      <div id="rfc.iref.t.2"></div>
     
    17971797      <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    17981798      <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 capabilities
     1799         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
    18001800         of all senders along the request/response chain.
    18011801      </p>
     
    19051905      <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
    19061906      <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<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 and
     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 <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
    19081908         Internet mail message formats.
    19091909      </p>
     
    22412241      <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
    22422242         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>.
    22442244      </p>
    22452245      <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
     
    22812281         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;8.1</a>.
    22822282      </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>.
    22852284      </p>
    22862285      <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
    22872286      <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>.
    22892288      </p>
    22902289      <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
     
    22922291         computed.
    22932292      </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 to
    2295          highest protocol version they support to deal with problems discovered in HTTP/1.0 implementations (<a href="#http.version" title="HTTP Version">Section&nbsp;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&nbsp;3.1</a>)
    22962295      </p>
    22972296      <p id="rfc.section.D.3.p.4">Proxies should be able to add Content-Length when appropriate.</p>
     
    25402539                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<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>
    25412540                  <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.3">D</a></li>
     2541                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.5">D</a></li>
    25442543                     </ul>
    25452544                  </li>
    25462545                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    25482547                  <li class="indline1"><em>RFC2324</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2324.1">1.1</a>, <a class="iref" href="#RFC2324"><b>12</b></a></li>
    25492548                  <li class="indline1"><em>RFC2396</em>&nbsp;&nbsp;<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>
     
    25522551                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#RFC4288"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li>
    25532552                  <li class="indline1"><em>RFC821</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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">
    25552554                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.5">4.2</a></li>
    25562555                     </ul>
Note: See TracChangeset for help on using the changeset viewer.