Ignore:
Timestamp:
Mar 5, 2011, 2:54:54 AM (9 years ago)
Author:
fielding@…
Message:

update generated files

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1145 r1149  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 2, 2011";
     361       content: "Expires September 6, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    410410      <meta name="dct.creator" content="Reschke, J. F.">
    411411      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    412       <meta name="dct.issued" scheme="ISO8601" content="2011-03-01">
     412      <meta name="dct.issued" scheme="ISO8601" content="2011-03-05">
     413      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    413414      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    414415      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
    … …  
    427428            </tr>
    428429            <tr>
    429                <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
     430               <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2145">2145</a>, <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
    430431               </td>
    431432               <td class="right">J. Gettys</td>
    … …  
    441442            </tr>
    442443            <tr>
    443                <td class="left">Expires: September 2, 2011</td>
     444               <td class="left">Expires: September 6, 2011</td>
    444445               <td class="right">HP</td>
    445446            </tr>
    … …  
    494495            <tr>
    495496               <td class="left"></td>
    496                <td class="right">March 1, 2011</td>
     497               <td class="right">March 5, 2011</td>
    497498            </tr>
    498499         </tbody>
    … …  
    522523         in progress”.
    523524      </p>
    524       <p>This Internet-Draft will expire on September 2, 2011.</p>
     525      <p>This Internet-Draft will expire on September 6, 2011.</p>
    525526      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    526527      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    552553         <li>2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP-related architecture</a><ul>
    553554               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li>
    554                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
    555                <li>2.3&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
    556                <li>2.4&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Transport Independence</a></li>
    557                <li>2.5&nbsp;&nbsp;&nbsp;<a href="#http.version">HTTP Version</a></li>
     555               <li>2.2&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Connections and Transport Independence</a></li>
     556               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
     557               <li>2.4&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
     558               <li>2.5&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li>
    558559               <li>2.6&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul>
    559560                     <li>2.6.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
    … …  
    736737         at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
    737738      </p>
    738       <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes,
     739      <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1", obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Part 1 describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes,
    739740         describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements.
    740741         Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics,
    … …  
    930931
    931932<span id="exbody">Hello World!
    932 </span></pre><div id="rfc.iref.i.1"></div>
    933       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
    934       <p id="rfc.section.2.2.p.1">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three
    935          common forms of intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server,
    936          proxy, gateway, or tunnel, switching behavior based on the nature of each request.
     933</span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2>
     934      <p id="rfc.section.2.2.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable
     935         transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request
     936         and response structures onto the data units of the underlying transport protocol is outside the scope of this specification.
     937      </p>
     938      <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the identifier
     939         (if any) provided for the request target. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use
     940         a proxy via some other connection port or protocol instead of using the defaults.
     941      </p>
     942      <p id="rfc.section.2.2.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>.
     943      </p>
     944      <div id="rfc.iref.i.1"></div>
     945      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
     946      <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of
     947         HTTP intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy,
     948         gateway, or tunnel, switching behavior based on the nature of each request.
    937949      </p>
    938950      <div id="rfc.figure.u.18"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
    939951    UA =========== A =========== B =========== C =========== O
    940952               &lt;             &lt;             &lt;             &lt;
    941 </pre><p id="rfc.section.2.2.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
     953</pre><p id="rfc.section.2.3.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
    942954         message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply
    943955         only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along
    … …  
    946958         at the same time that it is handling A's request.
    947959      </p>
    948       <p id="rfc.section.2.2.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:
     960      <p id="rfc.section.2.3.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:
    949961         all messages flow from upstream to downstream. Likewise, we use the terms "inbound" and "outbound" to refer to directions
    950962         in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent.
    951963      </p>
    952       <p id="rfc.section.2.2.p.5"><span id="rfc.iref.p.1"></span> A "proxy" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive
     964      <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "proxy" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive
    953965         requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface.
    954966         Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation
    … …  
    956968         through a common intermediary for the sake of security, annotation services, or shared caching.
    957969      </p>
    958       <p id="rfc.section.2.2.p.6"> <span id="rfc.iref.t.1"></span>  <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed or configured to modify request or response messages
     970      <p id="rfc.section.2.3.p.6"> <span id="rfc.iref.t.1"></span>  <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed or configured to modify request or response messages
    959971         in a semantically meaningful way (i.e., modifications, beyond those required by normal HTTP processing, that change the message
    960972         in a way that would be significant to the original sender or potentially significant to downstream recipients). For example,
    … …  
    965977         that preserve HTTP message semantics.
    966978      </p>
    967       <p id="rfc.section.2.2.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
     979      <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
    968980         the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP
    969981         services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the target
    … …  
    973985         the scope of this specification.
    974986      </p>
    975       <p id="rfc.section.2.2.p.8"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
     987      <p id="rfc.section.2.3.p.8"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
    976988         a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist
    977989         when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary,
    978990         such as when transport-layer security is used to establish private communication through a shared firewall proxy.
    979991      </p>
    980       <p id="rfc.section.2.2.p.9"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
     992      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.i.3"></span><span id="rfc.iref.t.3"></span> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
    981993         act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a
    982994         mess of things). Such a network intermediary, referred to as an "interception proxy" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> or "transparent proxy" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects outgoing
    … …  
    986998      </p>
    987999      <div id="rfc.iref.c.3"></div>
    988       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
    989       <p id="rfc.section.2.3.p.1">A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and
     1000      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
     1001      <p id="rfc.section.2.4.p.1">A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and
    9901002         deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future,
    9911003         equivalent requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.
    9921004      </p>
    993       <p id="rfc.section.2.3.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
     1005      <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
    9941006         response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response
    9951007         from O (via C) for a request which has not been cached by UA or A.
    … …  
    9981010       UA =========== A =========== B - - - - - - C - - - - - - O
    9991011                  &lt;             &lt;
    1000 </pre><p id="rfc.section.2.3.p.4"><span id="rfc.iref.c.4"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
     1012</pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.4"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    10011013         Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when
    10021014         that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are
    10031015         defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    10041016      </p>
    1005       <p id="rfc.section.2.3.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
     1017      <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
    10061018         inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems
    10071019         that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so
    10081020         on.
    10091021      </p>
    1010       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="transport-independence" href="#transport-independence">Transport Independence</a></h2>
    1011       <p id="rfc.section.2.4.p.1">HTTP systems are used in a wide variety of environments, from corporate intranets with high-bandwidth links to long-distance
    1012          communication over low-power radio links and intermittent connectivity.
    1013       </p>
    1014       <p id="rfc.section.2.4.p.2">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (&lt;<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>&gt;), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,
    1015          or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the
    1016          mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside
    1017          the scope of this specification.
    1018       </p>
    1019       <p id="rfc.section.2.4.p.3">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection might
    1020          be used for one or more request/response exchanges, although connections might be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>).
    1021       </p>
    1022       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="http.version" href="#http.version">HTTP Version</a></h2>
    1023       <p id="rfc.section.2.5.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended
    1024          to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather
    1025          than the features obtained via that communication. No change is made to the version number for the addition of message components
    1026          which do not affect communication behavior or which only add to extensible field values. The &lt;minor&gt; number is incremented
    1027          when the changes made to the protocol add features which do not change the general message parsing algorithm, but which might
    1028          add to the message semantics and imply additional capabilities of the sender. The &lt;major&gt; number is incremented when the format
    1029          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.
     1022      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
     1023      <p id="rfc.section.2.5.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. This specification defines version "1.1".
     1024         The protocol version as a whole indicates the sender's compliance with the set of requirements laid out in that version's
     1025         corresponding specification of HTTP.
    10301026      </p>
    10311027      <p id="rfc.section.2.5.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>
    10321028      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>
    10331029  <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive
    1034 </pre><p id="rfc.section.2.5.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3.
    1035          Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent.
    1036       </p>
    1037       <p id="rfc.section.2.5.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
    1038          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,
    1039          see <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>.
    1040       </p>
    1041       <p id="rfc.section.2.5.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p>
    1042       <p id="rfc.section.2.5.p.7">Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the
    1043          application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway <em class="bcp14">MUST NOT</em> send a message with a version indicator which is greater than its actual version. If a higher version request is received,
    1044          the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior.
    1045       </p>
    1046       <p id="rfc.section.2.5.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.
    1047       </p>
    1048       <div class="note" id="rfc.section.2.5.p.9">
    1049          <p> <b>Note:</b> Converting between versions of HTTP might involve modification of header fields required or forbidden by the versions involved.
    1050          </p>
    1051       </div>
     1030</pre><p id="rfc.section.2.5.p.4">The HTTP version number consists of two non-negative decimal integers separated by the "." (period or decimal point) character.
     1031         The first number ("major version") indicates the HTTP messaging syntax, whereas the second number ("minor version") indicates
     1032         the highest minor version to which the sender is at least conditionally compliant and able to understand for future communication.
     1033         The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible
     1034         subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers)
     1035         or in future requests (by clients).
     1036      </p>
     1037      <p id="rfc.section.2.5.p.5">When comparing HTTP versions, the numbers <em class="bcp14">MUST</em> be compared numerically rather than lexically. For example, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower
     1038         than HTTP/12.3. Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent.
     1039      </p>
     1040      <p id="rfc.section.2.5.p.6">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient (or a recipient whose version is unknown), the HTTP/1.1 message
     1041         is constructed such that it will be interpreted as a valid HTTP/1.0 message even if all of the provided header fields not
     1042         defined in the HTTP/1.0 specification <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> are ignored. This specification excludes incompatible message constructions by imposing recipient-version requirements on
     1043         new HTTP/1.1 features that are not safely interpreted by earlier HTTP/1.0 recipients.
     1044      </p>
     1045      <p id="rfc.section.2.5.p.7">The interpretation of an HTTP message header field does not change between minor versions of the same major version, though
     1046         the default behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined
     1047         in HTTP/1.1 are defined for all versions of HTTP/1.x. The most popular example of this is the Host header field, which was
     1048         introduced during the standardization process of HTTP/1.1 and widely deployed for HTTP/1.0 requests out of necessity.
     1049      </p>
     1050      <p id="rfc.section.2.5.p.8">Likewise, new header fields can be defined such that, when they are understood by a recipient, they might override or enhance
     1051         the interpretation of previously defined header fields. When an implementation receives an unrecognized header field, the
     1052         recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
     1053         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
     1054      </p>
     1055      <p id="rfc.section.2.5.p.9">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary
     1056         understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP
     1057         message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message
     1058         sender's version to determine what features are safe to use for later communication with that sender.
     1059      </p>
     1060      <p id="rfc.section.2.5.p.10">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant and whose major
     1061         version is no higher than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant.
     1062      </p>
     1063      <p id="rfc.section.2.5.p.11">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
     1064         the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server)
     1065         that the server improperly handles higher request versions.
     1066      </p>
     1067      <p id="rfc.section.2.5.p.12">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant and whose major
     1068         version is less than or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's
     1069         request.
     1070      </p>
     1071      <p id="rfc.section.2.5.p.13">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP
     1072         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
     1073         number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the
     1074         given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g.,
     1075         User-Agent) uniquely match the values sent by a client known to be in error.
     1076      </p>
     1077      <p id="rfc.section.2.5.p.14">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
     1078         is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding
     1079         to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented
     1080         for the changes introduced in <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol.
     1081      </p>
    10521082      <div id="rfc.iref.r.4"></div>
    10531083      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    … …  
    13371367               <tr>
    13381368                  <td class="left">Connection</td>
    1339                   <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a></td>
     1369                  <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;9.1</a></td>
    13401370               </tr>
    13411371               <tr>
    … …  
    18281858      </p>
    18291859      <p id="rfc.section.7.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
    1830          takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
     1860         takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
    18311861      </p>
    18321862      <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    … …  
    18541884      </p>
    18551885      <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
    1856       <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;9.1</a>.
     1886      <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>.
    18571887      </p>
    18581888      <p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects
    18591889         to. Each persistent connection applies to only one transport link.
    18601890      </p>
    1861       <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="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <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 field implemented by many HTTP/1.0 clients).
     1891      <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="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
    18621892      </p>
    18631893      <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4>
    … …  
    18831913      </ul>
    18841914      <p id="rfc.section.7.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
    1885       <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>).
     1915      <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;9.1</a>).
    18861916      </p>
    18871917      <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4>
    … …  
    19852015         <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"
    19862016            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
    1987             rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
     2017            rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
    19882018            field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays
    19892019            associated with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests
    … …  
    21912221  TE:
    21922222  TE: trailers, deflate;q=0.5
    2193 </pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;9.1</a>) whenever TE is present in an HTTP/1.1 message.
     2223</pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;9.1</a>) whenever TE is present in an HTTP/1.1 message.
    21942224      </p>
    21952225      <p id="rfc.section.9.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
    … …  
    22772307         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field.
    22782308      </p>
    2279       <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
     2309      <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    22802310      </p>
    22812311      <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    … …  
    22862316      </p>
    22872317      <p id="rfc.section.9.8.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    2288          by the HTTP version rules of <a href="#http.version" title="HTTP Version">Section&nbsp;2.5</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
     2318         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    22892319         below.
    22902320      </p>
    … …  
    23752405                  <td class="left">http</td>
    23762406                  <td class="left">standard</td>
    2377                   <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;9.1</a>
     2407                  <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;9.1</a>
    23782408                  </td>
    23792409               </tr>
    … …  
    26172647                  <td class="left">HTTP</td>
    26182648                  <td class="left">Hypertext Transfer Protocol</td>
    2619                   <td class="left"><a href="#http.version" title="HTTP Version">Section&nbsp;2.5</a> of this specification
     2649                  <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a> of this specification
    26202650                  </td>
    26212651               </tr>
    … …  
    27092739      </p>
    27102740      <p id="rfc.section.12.p.4">Thanks to the "cave men" of Palo Alto. You know who you are.</p>
    2711       <p id="rfc.section.12.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.4"><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
     2741      <p id="rfc.section.12.p.5">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.3"><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
    27122742         Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the
    27132743         "MUST/MAY/SHOULD" audit.
    … …  
    27462776            <td class="reference"><b id="RFC1950">[RFC1950]</b></td>
    27472777            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.<br>RFC 1950 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    2748                was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.1"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
     2778               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.1"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    27492779            </td>
    27502780         </tr>
    … …  
    27522782            <td class="reference"><b id="RFC1951">[RFC1951]</b></td>
    27532783            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC&nbsp;1951, May&nbsp;1996.<br>RFC 1951 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    2754                was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.2"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
     2784               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.2"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    27552785            </td>
    27562786         </tr>
    … …  
    27582788            <td class="reference"><b id="RFC1952">[RFC1952]</b></td>
    27592789            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.<br>RFC 1952 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    2760                was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.3"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
     2790               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.3"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    27612791            </td>
    27622792         </tr>
    … …  
    29602990      <p id="rfc.section.B.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred
    29612991         to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single method and no metadata.
    2962          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
     2992         HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.2"><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
    29632993         on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical
    29642994         proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely-implemented
    … …  
    29843014      <p id="rfc.section.B.p.5">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the
    29853015         server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described
    2986          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.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     3016         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.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    29873017      </p>
    29883018      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
    … …  
    30223052         Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when
    30233053         talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce
    3024          a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;9.1</a>.
     3054         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;9.1</a>.
    30253055      </p>
    30263056      <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header field) is documented
    3027          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.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     3057         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.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    30283058      </p>
    30293059      <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    30353065         and made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>)
    30363066      </p>
    3037       <p id="rfc.section.B.3.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section&nbsp;2.5</a>)
     3067      <p id="rfc.section.B.3.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a>)
    30383068      </p>
    30393069      <p id="rfc.section.B.3.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
    … …  
    30513081      <p id="rfc.section.B.3.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;7.1.4</a>)
    30523082      </p>
    3053       <p id="rfc.section.B.3.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;9.1</a>)
     3083      <p id="rfc.section.B.3.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;9.1</a>)
    30543084      </p>
    30553085      <p id="rfc.section.B.3.p.11">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;9.8</a>)
    … …  
    32673297      <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a>&nbsp;Since RFC 2616
    32683298      </h2>
    3269       <p id="rfc.section.D.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>.
     3299      <p id="rfc.section.D.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>.
    32703300      </p>
    32713301      <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a>&nbsp;Since draft-ietf-httpbis-p1-messaging-00
    … …  
    35823612            </li>
    35833613            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    3584                   <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li>
    3585                   <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.3</b></a></li>
     3614                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.4</b></a></li>
     3615                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.4</b></a></li>
    35863616                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.5">6.2.1</a></li>
    35873617                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    … …  
    35963626                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">6.2.2.1</a></li>
    35973627                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3598                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.4</a>, <a href="#rfc.xref.header.connection.2">7.1.2</a>, <a href="#rfc.xref.header.connection.3">7.1.3</a>, <a href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a href="#rfc.iref.c.11"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.5">9.5</a>, <a href="#rfc.xref.header.connection.6">9.8</a>, <a href="#rfc.xref.header.connection.7">10.1</a>, <a href="#rfc.xref.header.connection.8">B.2</a>, <a href="#rfc.xref.header.connection.9">B.3</a></li>
     3628                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.5</a>, <a href="#rfc.xref.header.connection.2">3.4</a>, <a href="#rfc.xref.header.connection.3">7.1.2</a>, <a href="#rfc.xref.header.connection.4">7.1.3</a>, <a href="#rfc.xref.header.connection.5">7.1.3.1</a>, <a href="#rfc.iref.c.11"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.6">9.5</a>, <a href="#rfc.xref.header.connection.7">9.8</a>, <a href="#rfc.xref.header.connection.8">10.1</a>, <a href="#rfc.xref.header.connection.9">B.2</a>, <a href="#rfc.xref.header.connection.10">B.3</a></li>
    35993629                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.12"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>
    36003630               </ul>
    … …  
    36033633                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li>
    36043634                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">6.2.2.2</a></li>
    3605                   <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.2</b></a></li>
     3635                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3</b></a></li>
    36063636               </ul>
    36073637            </li>
    … …  
    36113641            </li>
    36123642            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    3613                   <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.2</b></a></li>
     3643                  <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.3</b></a></li>
    36143644                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    36153645                     <ul>
    … …  
    37383768                  <li>Header Fields&nbsp;&nbsp;
    37393769                     <ul>
    3740                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.4</a>, <a href="#rfc.xref.header.connection.2">7.1.2</a>, <a href="#rfc.xref.header.connection.3">7.1.3</a>, <a href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.5">9.5</a>, <a href="#rfc.xref.header.connection.6">9.8</a>, <a href="#rfc.xref.header.connection.7">10.1</a>, <a href="#rfc.xref.header.connection.8">B.2</a>, <a href="#rfc.xref.header.connection.9">B.3</a></li>
     3770                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.5</a>, <a href="#rfc.xref.header.connection.2">3.4</a>, <a href="#rfc.xref.header.connection.3">7.1.2</a>, <a href="#rfc.xref.header.connection.4">7.1.3</a>, <a href="#rfc.xref.header.connection.5">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.6">9.5</a>, <a href="#rfc.xref.header.connection.7">9.8</a>, <a href="#rfc.xref.header.connection.8">10.1</a>, <a href="#rfc.xref.header.connection.9">B.2</a>, <a href="#rfc.xref.header.connection.10">B.3</a></li>
    37413771                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>
    37423772                        <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li>
    … …  
    37573787            </li>
    37583788            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    3759                   <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.2</b></a></li>
    3760                   <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.2</b></a></li>
    3761                   <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.2</b></a></li>
     3789                  <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.3</b></a></li>
     3790                  <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.3</b></a></li>
     3791                  <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.3</b></a></li>
    37623792                  <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2</a>, <a href="#ISO-8859-1"><b>13.1</b></a></li>
    37633793               </ul>
    … …  
    37803810            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul>
    37813811                  <li><em>Nie1997</em>&nbsp;&nbsp;<a href="#rfc.xref.Nie1997.1">7.1.1</a>, <a href="#Nie1997"><b>13.2</b></a></li>
    3782                   <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.2</b></a></li>
     3812                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.3</b></a></li>
    37833813               </ul>
    37843814            </li>
    37853815            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    37863816                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li>
    3787                   <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.2</b></a></li>
     3817                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li>
    37883818               </ul>
    37893819            </li>
    … …  
    38103840                     </ul>
    38113841                  </li>
    3812                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.3">1.2.3</a>, <a href="#rfc.xref.Part6.4">2.3</a>, <a href="#rfc.xref.Part6.5">3.3</a>, <a href="#rfc.xref.Part6.6">3.4</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">7.1.3.2</a>, <a href="#Part6"><b>13.1</b></a><ul>
    3813                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.3</a></li>
     3842                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.3">1.2.3</a>, <a href="#rfc.xref.Part6.4">2.4</a>, <a href="#rfc.xref.Part6.5">3.3</a>, <a href="#rfc.xref.Part6.6">3.4</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">7.1.3.2</a>, <a href="#Part6"><b>13.1</b></a><ul>
     3843                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.4</a></li>
    38143844                        <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">3.3</a></li>
    38153845                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.6">3.4</a></li>
    … …  
    38183848                  </li>
    38193849                  <li>path-absolute form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.p.2">4.1.2</a></li>
    3820                   <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.2</b></a></li>
     3850                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
    38213851               </ul>
    38223852            </li>
    … …  
    38253855                  <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.6</b></a></li>
    38263856                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>2.1</b></a></li>
    3827                   <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.2</b></a></li>
     3857                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.3</b></a></li>
    38283858                  <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul>
    38293859                        <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">6.1</a></li>
    … …  
    38313861                  </li>
    38323862                  <li><em>RFC1900</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1900.1">11.4</a>, <a href="#RFC1900"><b>13.2</b></a></li>
    3833                   <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.2</a>, <a href="#RFC1919"><b>13.2</b></a></li>
    3834                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#RFC1945"><b>13.2</b></a>, <a href="#rfc.xref.RFC1945.1">B</a></li>
     3863                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>13.2</b></a></li>
     3864                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.5</a>, <a href="#RFC1945"><b>13.2</b></a>, <a href="#rfc.xref.RFC1945.2">B</a></li>
    38353865                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">6.2.2.2</a>, <a href="#rfc.xref.RFC1950.2">10.4</a>, <a href="#RFC1950"><b>13.1</b></a></li>
    38363866                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">6.2.2.2</a>, <a href="#rfc.xref.RFC1951.2">10.4</a>, <a href="#RFC1951"><b>13.1</b></a></li>
    … …  
    38413871                  </li>
    38423872                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li>
    3843                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">2.5</a>, <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.3">7.2.3</a>, <a href="#rfc.xref.RFC2068.4">12</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">B</a>, <a href="#rfc.xref.RFC2068.9">B.2</a><ul>
    3844                         <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B</a>, <a href="#rfc.xref.RFC2068.9">B.2</a></li>
     3873                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.1.3</a>, <a href="#rfc.xref.RFC2068.2">7.2.3</a>, <a href="#rfc.xref.RFC2068.3">12</a>, <a href="#rfc.xref.RFC2068.4">13.1</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.7">B</a>, <a href="#rfc.xref.RFC2068.8">B.2</a><ul>
     3874                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.1.3</a>, <a href="#rfc.xref.RFC2068.7">B</a>, <a href="#rfc.xref.RFC2068.8">B.2</a></li>
    38453875                     </ul>
    38463876                  </li>
    38473877                  <li><em>RFC2109</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2109.1">3.2</a>, <a href="#RFC2109"><b>13.2</b></a></li>
    38483878                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>13.1</b></a></li>
    3849                   <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">2.5</a>, <a href="#rfc.xref.RFC2145.2">2.5</a>, <a href="#RFC2145"><b>13.2</b></a></li>
    3850                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.3">D.1</a></li>
     3879                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">1</a>, <a href="#RFC2145"><b>13.2</b></a></li>
     3880                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.5</a>, <a href="#rfc.xref.RFC2616.3">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.4">D.1</a></li>
    38513881                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">B.3</a><ul>
    38523882                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.5</a></li>
    … …  
    38553885                  <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.6.2</a>, <a href="#RFC2818"><b>13.2</b></a></li>
    38563886                  <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>13.2</b></a></li>
    3857                   <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.2</a>, <a href="#RFC3040"><b>13.2</b></a></li>
     3887                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>13.2</b></a></li>
    38583888                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">10.1</a>, <a href="#RFC3864"><b>13.2</b></a></li>
    38593889                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.6</a>, <a href="#rfc.xref.RFC3986.3">2.6</a>, <a href="#rfc.xref.RFC3986.4">2.6</a>, <a href="#rfc.xref.RFC3986.5">2.6</a>, <a href="#rfc.xref.RFC3986.6">2.6</a>, <a href="#rfc.xref.RFC3986.7">2.6</a>, <a href="#rfc.xref.RFC3986.8">2.6</a>, <a href="#rfc.xref.RFC3986.9">2.6</a>, <a href="#rfc.xref.RFC3986.10">2.6</a>, <a href="#rfc.xref.RFC3986.11">2.6</a>, <a href="#rfc.xref.RFC3986.12">2.6</a>, <a href="#rfc.xref.RFC3986.13">2.6</a>, <a href="#rfc.xref.RFC3986.14">2.6.1</a>, <a href="#rfc.xref.RFC3986.15">2.6.1</a>, <a href="#rfc.xref.RFC3986.16">2.6.3</a>, <a href="#rfc.xref.RFC3986.17">2.6.3</a>, <a href="#rfc.xref.RFC3986.18">4.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1.2</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>13.1</b></a><ul>
    … …  
    39023932                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">3.4</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.t.6"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>
    39033933                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
    3904                   <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.2</b></a></li>
    3905                   <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.2</b></a></li>
    3906                   <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.2</b></a></li>
     3934                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
     3935                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>
     3936                  <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.3</b></a></li>
    39073937               </ul>
    39083938            </li>
    39093939            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    39103940                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.3</a></li>
    3911                   <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.2</b></a></li>
     3941                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    39123942                  <li>URI scheme&nbsp;&nbsp;
    39133943                     <ul>
Note: See TracChangeset for help on using the changeset viewer.