Changeset 1762 for draft-ietf-httpbis


Ignore:
Timestamp:
13/07/12 08:57:46 (8 years ago)
Author:
fielding@…
Message:

(editorial) clean up a few Notes

Created a section on implementation diversity to replace the confusing
and awkward note about user agents not always having interactive users.

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r1760 r1762  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 12, 2013";
     451       content: "Expires January 14, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-07-11">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-07-13">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: January 12, 2013</td>
     525               <td class="left">Expires: January 14, 2013</td>
    526526               <td class="right">greenbytes</td>
    527527            </tr>
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">July 11, 2012</td>
     530               <td class="right">July 13, 2012</td>
    531531            </tr>
    532532         </tbody>
    … …  
    545545      </p>
    546546      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
    547       <p>Discussion of this draft ought to take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived
    548          at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.
     547      <p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.
    549548      </p> 
    550549      <p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.
    … …  
    561560         in progress”.
    562561      </p>
    563       <p>This Internet-Draft will expire on January 12, 2013.</p>
     562      <p>This Internet-Draft will expire on January 14, 2013.</p>
    564563      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    565564      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    586585         <li>2.&nbsp;&nbsp;&nbsp;<a href="#architecture">Architecture</a><ul>
    587586               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li>
    588                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Connections and Transport Independence</a></li>
    589                <li>2.3&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
    590                <li>2.4&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
    591                <li>2.5&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    592                <li>2.6&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li>
    593                <li>2.7&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul>
    594                      <li>2.7.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
    595                      <li>2.7.2&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI scheme</a></li>
    596                      <li>2.7.3&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li>
     587               <li>2.2&nbsp;&nbsp;&nbsp;<a href="#implementation-diversity">Implementation Diversity</a></li>
     588               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#transport-independence">Connections and Transport Independence</a></li>
     589               <li>2.4&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
     590               <li>2.5&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
     591               <li>2.6&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
     592               <li>2.7&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li>
     593               <li>2.8&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul>
     594                     <li>2.8.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
     595                     <li>2.8.2&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI scheme</a></li>
     596                     <li>2.8.3&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li>
    597597                  </ul>
    598598               </li>
    … …  
    811811      <div id="rfc.iref.s.3"></div>
    812812      <div id="rfc.iref.r.1"></div>
    813       <p id="rfc.section.2.1.p.2">Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The
    814          same program might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the
     813      <p id="rfc.section.2.1.p.2">The terms client and server refer only to the roles that these programs perform for a particular connection. The same program
     814         might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the
    815815         term "<dfn>origin server</dfn>" to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term
    816816         "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message.
    817817      </p>
    818       <div class="note" id="rfc.section.2.1.p.3">
    819          <p> <b>Note:</b> The term 'user agent' covers both those situations where there is a user (human) interacting with the software agent (and
    820             for which user interface or interactive suggestions might be made, e.g., warning the user or given the user an option in the
    821             case of security or privacy options) and also those where the software agent can act autonomously.
    822          </p>
    823       </div>
    824       <p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
     818      <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
    825819         the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and
    826820         the origin server (O).
    … …  
    832826      <div id="rfc.iref.r.2"></div>
    833827      <div id="rfc.iref.r.3"></div>
    834       <p id="rfc.section.2.1.p.6">A client sends an HTTP request to the server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and representation metadata (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
    835       </p>
    836       <p id="rfc.section.2.1.p.7">A server responds to the client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason
     828      <p id="rfc.section.2.1.p.5">A client sends an HTTP request to a server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and representation metadata (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
     829      </p>
     830      <p id="rfc.section.2.1.p.6">A server responds to a client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason
    837831         phrase (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>), possibly followed by MIME-like header fields containing server information, resource metadata, and representation metadata
    838832         (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
    839833      </p>
    840       <p id="rfc.section.2.1.p.8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
     834      <p id="rfc.section.2.1.p.7">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
    841835      <div id="rfc.figure.u.2"></div>
    842836      <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
    … …  
    857851
    858852<span id="exbody">Hello World!
    859 </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>
    860       <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
     853</span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="implementation-diversity" href="#implementation-diversity">Implementation Diversity</a></h2>
     854      <p id="rfc.section.2.2.p.1">When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers
     855         and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household
     856         appliances, stereos, scales, software/firmware updaters, command-line programs, mobile apps, and communication devices in
     857         a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking
     858         components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms.
     859      </p>
     860      <p id="rfc.section.2.2.p.2">The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of
     861         a request. In many cases, a user agent is installed or configured to run in the background and save its results for later
     862         inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically
     863         given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph.
     864      </p>
     865      <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that we cannot assume the user agent can make interactive suggestions to a user
     866         or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting
     867         of errors to the user, it is acceptable for such reporting to only be visible in an error console or log file. Likewise, requirements
     868         that an automated action be confirmed by the user before proceeding can me met via advance configuration choices, run-time
     869         options, or simply not proceeding with the unsafe action.
     870      </p>
     871      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2>
     872      <p id="rfc.section.2.3.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable
    861873         transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request
    862874         and response structures onto the data units of the underlying transport protocol is outside the scope of this specification.
    863875      </p>
    864       <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 target URI
    865          (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>). For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.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
     876      <p id="rfc.section.2.3.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target URI
     877         (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>). For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.8.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
    866878         a proxy via some other connection port or protocol instead of using the defaults.
    867879      </p>
    868       <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;6.3</a>.
     880      <p id="rfc.section.2.3.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;6.3</a>.
    869881      </p>
    870882      <div id="rfc.iref.i.1"></div>
    871       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
    872       <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
     883      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
     884      <p id="rfc.section.2.4.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of
    873885         HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel,
    874886         switching behavior based on the nature of each request.
    … …  
    877889    <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b>
    878890               &lt;             &lt;             &lt;             &lt;
    879 </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
     891</pre><p id="rfc.section.2.4.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
    880892         message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply
    881893         only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along
    … …  
    884896         at the same time that it is handling A's request.
    885897      </p>
    886       <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 "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream.
     898      <p id="rfc.section.2.4.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 "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream.
    887899         Likewise, we use the terms inbound and outbound to refer to directions in relation to the request path: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent.
    888900      </p>
    889       <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests
     901      <p id="rfc.section.2.4.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests
    890902         for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
    891903         are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
    … …  
    893905         for the sake of security, annotation services, or shared caching.
    894906      </p>
    895       <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 "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications,
     907      <p id="rfc.section.2.4.p.6"> <span id="rfc.iref.t.1"></span>  <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications,
    896908         beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original
    897909         sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared
    … …  
    901913         a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    902914      </p>
    903       <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
     915      <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
    904916         server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance
    905917         through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines.
    906918      </p>
    907       <p id="rfc.section.2.3.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements
     919      <p id="rfc.section.2.4.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements
    908920         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    909921         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    910922         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;6.2</a>) header fields for both connections.
    911923      </p>
    912       <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
     924      <p id="rfc.section.2.4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    913925         to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
    914926         ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
    915927         when transport-layer security is used to establish private communication through a shared firewall proxy.
    916928      </p>
    917       <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span>  <span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
     929      <p id="rfc.section.2.4.p.10"><span id="rfc.iref.i.3"></span>  <span id="rfc.iref.t.3"></span>  <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
    918930         intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the
    919931         knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems
    … …  
    923935         and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack.
    924936      </p>
    925       <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
     937      <p id="rfc.section.2.4.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
    926938         depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple
    927939         servers. Hence, servers <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific
    … …  
    929941      </p>
    930942      <div id="rfc.iref.c.4"></div>
    931       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
    932       <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
     943      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
     944      <p id="rfc.section.2.5.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
    933945         A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
    934946         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.
    935947      </p>
    936       <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
     948      <p id="rfc.section.2.5.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
    937949         response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response
    938950         from O (via C) for a request which has not been cached by UA or A.
    … …  
    941953       <b>UA</b> =========== <b>A</b> =========== <b>B</b> - - - - - - <b>C</b> - - - - - - <b>O</b>
    942954                  &lt;             &lt;
    943 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response
     955</pre><p id="rfc.section.2.5.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response
    944956         is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response
    945957         can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    946958      </p>
    947       <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
     959      <p id="rfc.section.2.5.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
    948960         inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems
    949961         that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so
    950962         on.
    951963      </p>
    952       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
    953       <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
     964      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
     965      <p id="rfc.section.2.6.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    954966         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    955967         or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send"
    956968         where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream.
    957969      </p>
    958       <p id="rfc.section.2.5.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     970      <p id="rfc.section.2.6.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    959971         in HTTP.
    960972      </p>
    961       <p id="rfc.section.2.5.p.3">A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable
     973      <p id="rfc.section.2.6.p.3">A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable
    962974         to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable
    963975         to the recipient's role.
    964976      </p>
    965       <p id="rfc.section.2.5.p.4">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
     977      <p id="rfc.section.2.6.p.4">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
    966978         except when they have a direct impact on security, since different applications of the protocol require different error handling
    967979         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery
    968980         to be dangerous.
    969981      </p>
    970       <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
    971       <p id="rfc.section.2.6.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".
     982      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
     983      <p id="rfc.section.2.7.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".
    972984         The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's
    973985         corresponding specification of HTTP.
    974986      </p>
    975       <p id="rfc.section.2.6.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>
     987      <p id="rfc.section.2.7.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>
    976988      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#http.version" class="smpl">HTTP-version</a>  = <a href="#http.version" class="smpl">HTTP-name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>
    977989  <a href="#http.version" class="smpl">HTTP-name</a>     = %x48.54.54.50 ; "HTTP", case-sensitive
    978 </pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major
     990</pre><p id="rfc.section.2.7.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major
    979991         version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version
    980992         to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's
    … …  
    982994         the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).
    983995      </p>
    984       <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0
     996      <p id="rfc.section.2.7.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0
    985997         message if all of the newer features are ignored. This specification places recipient-version requirements on some new features
    986998         so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt
    987999         of a message, that the recipient supports HTTP/1.1.
    9881000      </p>
    989       <p id="rfc.section.2.6.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default
     1001      <p id="rfc.section.2.7.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default
    9901002         behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
    9911003         are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.
    9921004      </p>
    993       <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
     1005      <p id="rfc.section.2.7.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
    9941006         of previously defined header fields. When an implementation receives an unrecognized header field, the 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
    9951007         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's <a href="#header.connection" class="smpl">Connection</a> header field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
    9961008      </p>
    997       <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <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 in that message matches a version
     1009      <p id="rfc.section.2.7.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <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 in that message matches a version
    9981010         to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without
    9991011         rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version
    10001012         to determine what features are safe to use for later communication with that sender.
    10011013      </p>
    1002       <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher
     1014      <p id="rfc.section.2.7.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher
    10031015         than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant.
    10041016      </p>
    1005       <p id="rfc.section.2.6.p.10">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
     1017      <p id="rfc.section.2.7.p.10">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
    10061018         the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
    10071019      </p>
    1008       <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
     1020      <p id="rfc.section.2.7.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
    10091021         or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not
    10101022            Supported)</a> response if it cannot send a response using the major version used in the client's request.
    10111023      </p>
    1012       <p id="rfc.section.2.6.p.12">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
     1024      <p id="rfc.section.2.7.p.12">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
    10131025         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
    10141026         number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the
    10151027         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., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error.
    10161028      </p>
    1017       <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
     1029      <p id="rfc.section.2.7.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
    10181030         is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding
    10191031         to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented
    … …  
    10211033      </p>
    10221034      <div id="rfc.iref.r.5"></div>
    1023       <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    1024       <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects,
     1035      <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
     1036      <p id="rfc.section.2.8.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects,
    10251037         and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to
    10261038         interact with a resource via HTTP. More information on the scope of URIs and resources can be found in <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.
    10271039      </p>
    1028       <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",
     1040      <p id="rfc.section.2.8.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",
    10291041         "path-absolute", "query", and "authority" from the URI generic syntax <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI but not a fragment.
    10301042      </p>
    … …  
    10401052 
    10411053  <a href="#uri" class="smpl">partial-URI</a>   = relative-part [ "?" query ]
    1042 </pre><p id="rfc.section.2.7.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows
     1054</pre><p id="rfc.section.2.8.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows
    10431055         any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components,
    10441056         or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request
    10451057         URI (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>).
    10461058      </p>
    1047       <h3 id="rfc.section.2.7.1"><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3>
     1059      <h3 id="rfc.section.2.8.1"><a href="#rfc.section.2.8.1">2.8.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3>
    10481060      <div id="rfc.iref.h.1"></div>
    10491061      <div id="rfc.iref.u.3"></div>
    1050       <p id="rfc.section.2.7.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
     1062      <p id="rfc.section.2.8.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
    10511063         namespace governed by a potential HTTP origin server listening for TCP connections on a given port.
    10521064      </p>
    10531065      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    1054 </pre><p id="rfc.section.2.7.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an
     1066</pre><p id="rfc.section.2.8.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an
    10551067         identifier for a potential resource within that origin server's name space.
    10561068      </p>
    1057       <p id="rfc.section.2.7.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated
     1069      <p id="rfc.section.2.8.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated
    10581070         TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient
    10591071         might use a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved
    10601072         port for WWW services).
    10611073      </p>
    1062       <p id="rfc.section.2.7.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
     1074      <p id="rfc.section.2.8.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
    10631075         The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening
    10641076         to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish
    … …  
    10661078         authority to determine which names are valid and how they might be used.
    10671079      </p>
    1068       <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
     1080      <p id="rfc.section.2.8.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    10691081         and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    10701082      </p>
    1071       <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
     1083      <p id="rfc.section.2.8.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    10721084         delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol
    10731085         would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require
    … …  
    10751087         — it is only the authoritative interface used for mapping the namespace that is specific to TCP.
    10761088      </p>
    1077       <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
     1089      <p id="rfc.section.2.8.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
    10781090         configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists,
    10791091         even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> include a userinfo subcomponent (and its "@" delimiter) when transmitting an "http" URI in a message. Recipients of HTTP messages
    … …  
    10811093         is being used to obscure the authority for the sake of phishing attacks.
    10821094      </p>
    1083       <h3 id="rfc.section.2.7.2"><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;<a id="https.uri" href="#https.uri">https URI scheme</a></h3>
     1095      <h3 id="rfc.section.2.8.2"><a href="#rfc.section.2.8.2">2.8.2</a>&nbsp;<a id="https.uri" href="#https.uri">https URI scheme</a></h3>
    10841096      <div id="rfc.iref.h.2"></div>
    10851097      <div id="rfc.iref.u.4"></div>
    1086       <p id="rfc.section.2.7.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
     1098      <p id="rfc.section.2.8.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
    10871099         namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port.
    10881100      </p>
    1089       <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default
     1101      <p id="rfc.section.2.8.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default
    10901102         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request.
    10911103      </p>
    10921104      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    1093 </pre><p id="rfc.section.2.7.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP
     1105</pre><p id="rfc.section.2.8.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP
    10941106         or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    10951107      </p>
    1096       <p id="rfc.section.2.7.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
     1108      <p id="rfc.section.2.8.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
    10971109         indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered
    10981110         to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the
    10991111         Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains.
    11001112      </p>
    1101       <p id="rfc.section.2.7.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
    1102       </p>
    1103       <h3 id="rfc.section.2.7.3"><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3>
    1104       <p id="rfc.section.2.7.3.p.1">Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to
     1113      <p id="rfc.section.2.8.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
     1114      </p>
     1115      <h3 id="rfc.section.2.8.3"><a href="#rfc.section.2.8.3">2.8.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3>
     1116      <p id="rfc.section.2.8.3.p.1">Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to
    11051117         the algorithm defined in <a href="#RFC3986" id="rfc.xref.RFC3986.16"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-6">Section 6</a>, using the defaults described above for each scheme.
    11061118      </p>
    1107       <p id="rfc.section.2.7.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty
     1119      <p id="rfc.section.2.8.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty
    11081120         path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme
    11091121         and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.
    11101122         Characters other than those in the "reserved" set are equivalent to their percent-encoded octets (see <a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>): the normal form is to not encode them.
    11111123      </p>
    1112       <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p>
     1124      <p id="rfc.section.2.8.3.p.3">For example, the following three URIs are equivalent:</p>
    11131125      <div id="rfc.figure.u.10"></div><pre class="text">   http://example.com:80/~smith/home.html
    11141126   http://EXAMPLE.com/%7Esmith/home.html
    … …  
    14281440         have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
    14291441      </p>
    1430       <p id="rfc.section.3.3.2.p.6">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only
    1431          within the "message/external-body" media-type.
    1432       </p>
    1433       <p id="rfc.section.3.3.2.p.7">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
     1442      <p id="rfc.section.3.3.2.p.6">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
    14341443         an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Protocol Element Size Overflows">Section&nbsp;8.6</a>).
    14351444      </p>
    1436       <p id="rfc.section.3.3.2.p.8">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
     1445      <p id="rfc.section.3.3.2.p.7">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
    14371446         a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields
    14381447         have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing
    14391448         that decimal value prior to determining the message body length.
    14401449      </p>
     1450      <div class="note" id="rfc.section.3.3.2.p.8">
     1451         <p> <b>Note:</b> HTTP's use of Content-Length for message framing differs significantly from the same field's use in MIME, where it is an optional
     1452            field used only within the "message/external-body" media-type.
     1453         </p>
     1454      </div>
    14411455      <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="message.body.length" href="#message.body.length">Message Body Length</a></h3>
    14421456      <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p>
    … …  
    17431757      </p>
    17441758      <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1745          are defined in <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order
     1759         are defined in <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.8</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order
    17461760         to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment
    17471761         identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    … …  
    17621776         connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and
    17631777         defined by its associated specification, similar to how this specification defines origin server access for resolution of
    1764          the "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) schemes.
     1778         the "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.8.1</a>) and "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.8.2</a>) schemes.
    17651779      </p>
    17661780      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="request-target" href="#request-target">Request Target</a></h2>
    … …  
    18281842         is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line.
    18291843      </p>
    1830       <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
     1844      <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.8.1</a>
    18311845</pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then the Host
    1832          field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
     1846         field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.8.1</a>). If the authority component is missing or undefined for the target URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
    18331847      </p>
    18341848      <p id="rfc.section.5.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    … …  
    18881902      </p>
    18891903      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="intermediary.forwarding" href="#intermediary.forwarding">Intermediary Forwarding</a></h2>
    1890       <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used
     1904      <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.4</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used
    18911905         to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has
    18921906         characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can
    … …  
    22492263      </p>
    22502264      <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    2251          by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
     2265         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.7</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    22522266         in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
    22532267      </p>
    … …  
    23742388                  <td class="left">http</td>
    23752389                  <td class="left">Hypertext Transfer Protocol</td>
    2376                   <td class="left"><a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a></td>
     2390                  <td class="left"><a href="#http.uri" title="http URI scheme">Section&nbsp;2.8.1</a></td>
    23772391               </tr>
    23782392               <tr>
    23792393                  <td class="left">https</td>
    23802394                  <td class="left">Hypertext Transfer Protocol Secure</td>
    2381                   <td class="left"><a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a></td>
     2395                  <td class="left"><a href="#https.uri" title="https URI scheme">Section&nbsp;2.8.2</a></td>
    23822396               </tr>
    23832397            </tbody>
    … …  
    25952609                  <td class="left">Hypertext Transfer Protocol</td>
    25962610                  <td class="left">any DIGIT.DIGIT (e.g, "2.0")</td>
    2597                   <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a></td>
     2611                  <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.7</a></td>
    25982612               </tr>
    25992613            </tbody>
    … …  
    29692983      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    29702984      <p id="rfc.section.A.2.p.1">Clarify that the string "HTTP" in the HTTP-version ABFN production is case sensitive. Restrict the version numbers to be single
    2971          digits due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a>)
     2985         digits due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.7</a>)
    29722986      </p>
    29732987      <p id="rfc.section.A.2.p.2">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
    … …  
    35473561            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    35483562                  <li>absolute-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">5.3</a></li>
    3549                   <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li>
     3563                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.4</b></a></li>
    35503564                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>7.3.2</b></a></li>
    35513565                  <li>asterisk-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.3</a></li>
    … …  
    35583572            </li>
    35593573            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    3560                   <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.4</b></a></li>
    3561                   <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.4</b></a></li>
    3562                   <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li>
     3574                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>2.5</b></a></li>
     3575                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.5</b></a></li>
     3576                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.4</b></a></li>
    35633577                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">4.1</a></li>
    35643578                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    … …  
    35733587                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    35743588                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3575                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3589                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
    35763590                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">7.1</a></li>
    35773591               </ul>
    … …  
    35793593            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    35803594                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">4.2.2</a></li>
    3581                   <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3</b></a></li>
     3595                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.4</b></a></li>
    35823596               </ul>
    35833597            </li>
    … …  
    35873601            </li>
    35883602            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    3589                   <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>2.3</b></a></li>
     3603                  <li>gateway&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>2.4</b></a></li>
    35903604                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    35913605                     <ul>
    35923606                        <li><tt>absolute-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>5.3</b></a></li>
    3593                         <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.7</b></a></li>
     3607                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.8</b></a></li>
    35943608                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
    35953609                        <li><tt>asterisk-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>5.3</b></a></li>
    35963610                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    3597                         <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.7</b></a></li>
     3611                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.8</b></a></li>
    35983612                        <li><tt>authority-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>5.3</b></a></li>
    35993613                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>3.2.1</b></a></li>
    … …  
    36253639                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    36263640                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>3</b></a></li>
    3627                         <li><tt>HTTP-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>2.6</b></a></li>
    3628                         <li><tt>http-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.7.1</b></a></li>
    3629                         <li><tt>HTTP-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.6</b></a></li>
    3630                         <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7.2</b></a></li>
     3641                        <li><tt>HTTP-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>2.7</b></a></li>
     3642                        <li><tt>http-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.8.1</b></a></li>
     3643                        <li><tt>HTTP-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.7</b></a></li>
     3644                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.8.2</b></a></li>
    36313645                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>4.1</b></a></li>
    36323646                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li>
    … …  
    36383652                        <li><tt>origin-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.3</b></a></li>
    36393653                        <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>3.2.1</b></a></li>
    3640                         <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    3641                         <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
     3654                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.8</b></a></li>
     3655                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.8</b></a></li>
    36423656                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>6.2</b></a></li>
    36433657                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>6.2</b></a></li>
    … …  
    36453659                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.4</b></a></li>
    36463660                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>4.1</b></a></li>
    3647                         <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
     3661                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.8</b></a></li>
    36483662                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.4</b></a></li>
    36493663                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.4</b></a></li>
    … …  
    36753689                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    36763690                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.5</b></a></li>
    3677                         <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    3678                         <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
     3691                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.8</b></a></li>
     3692                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.8</b></a></li>
    36793693                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>4</b></a></li>
    36803694                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    … …  
    36903704                  <li>Header Fields&nbsp;&nbsp;
    36913705                     <ul>
    3692                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.h.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3706                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.7</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.h.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
    36933707                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">7.1</a></li>
    36943708                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>
    … …  
    36973711                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li>
    36983712                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.iref.h.14"><b>6.5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
    3699                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.h.13"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
     3713                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.h.13"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
    37003714                     </ul>
    37013715                  </li>
    … …  
    37033717                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    37043718                  <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.10"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>
    3705                   <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    3706                   <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
     3719                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.8.1</b></a></li>
     3720                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.8.2</a></li>
    37073721               </ul>
    37083722            </li>
    37093723            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    3710                   <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.3</b></a></li>
    3711                   <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.3</b></a></li>
    3712                   <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.3</b></a></li>
     3724                  <li>inbound&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>2.4</b></a></li>
     3725                  <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.4</b></a></li>
     3726                  <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.4</b></a></li>
    37133727                  <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2.2</a>, <a href="#ISO-8859-1"><b>10.1</b></a></li>
    37143728               </ul>
    … …  
    37323746            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul>
    37333747                  <li><em>Nie1997</em>&nbsp;&nbsp;<a href="#rfc.xref.Nie1997.1">6.3.1</a>, <a href="#Nie1997"><b>10.2</b></a></li>
    3734                   <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.3</b></a></li>
     3748                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.4</b></a></li>
    37353749               </ul>
    37363750            </li>
    … …  
    37383752                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li>
    37393753                  <li>origin-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">5.3</a></li>
    3740                   <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li>
     3754                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.4</b></a></li>
    37413755               </ul>
    37423756            </li>
    37433757            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    37443758                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li>
    3745                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3759                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.4</a>, <a href="#rfc.xref.Part2.3">2.8.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    37463760                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a></li>
    37473761                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a></li>
    … …  
    37493763                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">5.3</a></li>
    37503764                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    3751                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li>
     3765                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.8.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li>
    37523766                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.22">6.4.3</a></li>
    37533767                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">6.4.3</a></li>
    3754                         <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
     3768                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.4</a></li>
    37553769                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.5</a></li>
    37563770                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">8.6</a></li>
    … …  
    37733787                     </ul>
    37743788                  </li>
    3775                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">5.6.2</a>, <a href="#rfc.xref.Part6.8">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
    3776                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
     3789                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.8.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">5.6.2</a>, <a href="#rfc.xref.Part6.8">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
     3790                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.5</a></li>
    37773791                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
    3778                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.8">6.1</a></li>
     3792                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.8.2</a>, <a href="#rfc.xref.Part6.8">6.1</a></li>
    37793793                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">5.6.2</a></li>
    3780                         <li><em>Section 7.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.7">5.6.2</a></li>
     3794                        <li><em>Section 7.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.7">5.6.2</a></li>
    37813795                     </ul>
    37823796                  </li>
    … …  
    37863800                     </ul>
    37873801                  </li>
    3788                   <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
     3802                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.4</b></a></li>
    37893803               </ul>
    37903804            </li>
    … …  
    37933807                  <li>request&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>2.1</b></a></li>
    37943808                  <li>request-target&nbsp;&nbsp;<a href="#rfc.iref.r.6">3.1.1</a></li>
    3795                   <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.5"><b>2.7</b></a></li>
     3809                  <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.5"><b>2.8</b></a></li>
    37963810                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.1</b></a></li>
    3797                   <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.3</b></a></li>
    3798                   <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>10.2</b></a></li>
    3799                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#rfc.xref.RFC1945.2">9</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.3">A</a></li>
     3811                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.4</b></a></li>
     3812                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>10.2</b></a></li>
     3813                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.7</a>, <a href="#rfc.xref.RFC1945.2">9</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.3">A</a></li>
    38003814                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7.5</a>, <a href="#RFC1950"><b>10.1</b></a></li>
    38013815                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.5</a>, <a href="#RFC1951"><b>10.1</b></a></li>
    … …  
    38063820                  </li>
    38073821                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li>
    3808                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">5.6.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">6.4.3</a>, <a href="#rfc.xref.RFC2068.6">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a><ul>
     3822                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.7</a>, <a href="#rfc.xref.RFC2068.3">5.6.1</a>, <a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">6.4.3</a>, <a href="#rfc.xref.RFC2068.6">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a><ul>
    38093823                        <li><em>Section 19.7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">5.6.1</a></li>
    38103824                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.4">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.7">A.1.2</a></li>
    … …  
    38133827                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li>
    38143828                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">§</a>, <a href="#rfc.xref.RFC2145.2">1</a>, <a href="#rfc.xref.RFC2145.3">9</a>, <a href="#RFC2145"><b>10.2</b></a></li>
    3815                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2.6</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">C.1</a><ul>
     3829                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2.7</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.6">C.1</a><ul>
    38163830                        <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">9</a></li>
    38173831                     </ul>
    … …  
    38213835                     </ul>
    38223836                  </li>
    3823                   <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>10.2</b></a></li>
     3837                  <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.8.2</a>, <a href="#RFC2818"><b>10.2</b></a></li>
    38243838                  <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>10.2</b></a></li>
    3825                   <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>10.2</b></a></li>
     3839                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>10.2</b></a></li>
    38263840                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">7.1</a>, <a href="#RFC3864"><b>10.2</b></a></li>
    3827                   <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul>
    3828                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a></li>
    3829                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
    3830                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.7.1</a></li>
    3831                         <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a></li>
    3832                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.11">2.7</a></li>
    3833                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a></li>
    3834                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.12">2.7</a></li>
     3841                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.8</a>, <a href="#rfc.xref.RFC3986.3">2.8</a>, <a href="#rfc.xref.RFC3986.4">2.8</a>, <a href="#rfc.xref.RFC3986.5">2.8</a>, <a href="#rfc.xref.RFC3986.6">2.8</a>, <a href="#rfc.xref.RFC3986.7">2.8</a>, <a href="#rfc.xref.RFC3986.8">2.8</a>, <a href="#rfc.xref.RFC3986.9">2.8</a>, <a href="#rfc.xref.RFC3986.10">2.8</a>, <a href="#rfc.xref.RFC3986.11">2.8</a>, <a href="#rfc.xref.RFC3986.12">2.8</a>, <a href="#rfc.xref.RFC3986.13">2.8</a>, <a href="#rfc.xref.RFC3986.14">2.8.1</a>, <a href="#rfc.xref.RFC3986.15">2.8.1</a>, <a href="#rfc.xref.RFC3986.16">2.8.3</a>, <a href="#rfc.xref.RFC3986.17">2.8.3</a>, <a href="#rfc.xref.RFC3986.18">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul>
     3842                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.8.3</a></li>
     3843                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.8</a></li>
     3844                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.8.1</a></li>
     3845                        <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.13">2.8</a>, <a href="#rfc.xref.RFC3986.14">2.8.1</a></li>
     3846                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.11">2.8</a></li>
     3847                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.9">2.8</a>, <a href="#rfc.xref.RFC3986.10">2.8</a></li>
     3848                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.12">2.8</a></li>
    38353849                        <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.18">5.1</a></li>
    3836                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.7</a></li>
    3837                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.7</a></li>
    3838                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a></li>
    3839                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.7.3</a></li>
     3850                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.8</a></li>
     3851                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.8</a></li>
     3852                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.8</a></li>
     3853                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.8.3</a></li>
    38403854                     </ul>
    38413855                  </li>
    … …  
    38433857                  <li><em>RFC4288</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4288.1">7.3</a>, <a href="#RFC4288"><b>10.2</b></a></li>
    38443858                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">7.2</a>, <a href="#RFC4395"><b>10.2</b></a></li>
    3845                   <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li>
     3859                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.4</a>, <a href="#RFC4559"><b>10.2</b></a></li>
    38463860                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a>, <a href="#RFC5226"><b>10.2</b></a><ul>
    38473861                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a></li>
    … …  
    38563870                     </ul>
    38573871                  </li>
    3858                   <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>10.2</b></a></li>
     3872                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.8.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>10.2</b></a></li>
    38593873               </ul>
    38603874            </li>
    … …  
    38733887                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>
    38743888                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li>
    3875                   <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
    3876                   <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>
    3877                   <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.3</b></a></li>
     3889                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.4</b></a></li>
     3890                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.4</b></a></li>
     3891                  <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.4</b></a></li>
    38783892               </ul>
    38793893            </li>
    38803894            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    38813895                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.iref.u.5"><b>6.5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
    3882                   <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
     3896                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.4</b></a></li>
    38833897                  <li>URI scheme&nbsp;&nbsp;
    38843898                     <ul>
    3885                         <li>http&nbsp;&nbsp;<a href="#rfc.iref.u.3"><b>2.7.1</b></a></li>
    3886                         <li>https&nbsp;&nbsp;<a href="#rfc.iref.u.4">2.7.2</a></li>
     3899                        <li>http&nbsp;&nbsp;<a href="#rfc.iref.u.3"><b>2.8.1</b></a></li>
     3900                        <li>https&nbsp;&nbsp;<a href="#rfc.iref.u.4">2.8.2</a></li>
    38873901                     </ul>
    38883902                  </li>
    … …  
    38923906            </li>
    38933907            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3894                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.v.1"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
     3908                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.iref.v.1"><b>6.2</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
    38953909               </ul>
    38963910            </li>

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

    r1760 r1762  
    145145<note title="Editorial Note (To be removed by RFC Editor)">
    146146  <t>
    147     Discussion of this draft ought to take place on the HTTPBIS working group
     147    Discussion of this draft takes place on the HTTPBIS working group
    148148    mailing list (ietf-http-wg@w3.org), which is archived at
    149149    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    … …  
    303303<iref primary="true" item="recipient"/>
    304304<t>
    305    Note that the terms client and server refer only to the roles that
     305   The terms client and server refer only to the roles that
    306306   these programs perform for a particular connection.  The same program
    307307   might act as a client on some connections and a server on others.  We use
    … …  
    314314   message.
    315315</t>
    316 <x:note>
    317   <t>
    318     &Note; The term 'user agent' covers both those situations where
    319     there is a user (human) interacting with the software agent (and for which
    320     user interface or interactive suggestions might be made, e.g., warning the
    321     user or given the user an option in the case of security or privacy
    322     options) and also those where the software agent can act autonomously.
    323   </t>
    324 </x:note>
    325316<t>
    326317   Most HTTP communication consists of a retrieval request (GET) for
    … …  
    338329<iref primary="true" item="response"/>
    339330<t>
    340    A client sends an HTTP request to the server in the form of a <x:dfn>request</x:dfn>
     331   A client sends an HTTP request to a server in the form of a <x:dfn>request</x:dfn>
    341332   message, beginning with a request-line that includes a method, URI, and
    342333   protocol version (<xref target="request.line"/>),
    … …  
    349340</t>
    350341<t>
    351    A server responds to the client's request by sending one or more HTTP
     342   A server responds to a client's request by sending one or more HTTP
    352343   <x:dfn>response</x:dfn>
    353344   messages, each beginning with a status line that
    … …  
    389380<x:span anchor="exbody">Hello World!
    390381</x:span></artwork></figure>
     382</section>
     383
     384<section title="Implementation Diversity" anchor="implementation-diversity">
     385<t>
     386   When considering the design of HTTP, it is easy to fall into a trap of
     387   thinking that all user agents are general-purpose browsers and all origin
     388   servers are large public websites. That is not the case in practice.
     389   Common HTTP user agents include household appliances, stereos, scales,
     390   software/firmware updaters, command-line programs, mobile apps,
     391   and communication devices in a multitude of shapes and sizes.  Likewise,
     392   common HTTP origin servers include home automation units, configurable
     393   networking components, office machines, autonomous robots, news feeds,
     394   traffic cameras, ad selectors, and video delivery platforms.
     395</t>
     396<t>
     397   The term "user agent" does not imply that there is a human user directly
     398   interacting with the software agent at the time of a request. In many
     399   cases, a user agent is installed or configured to run in the background
     400   and save its results for later inspection (or save only a subset of those
     401   results that might be interesting or erroneous). Spiders, for example, are
     402   typically given a start URI and configured to follow certain behavior while
     403   crawling the Web as a hypertext graph.
     404</t>
     405<t>
     406   The implementation diversity of HTTP means that we cannot assume the
     407   user agent can make interactive suggestions to a user or provide adequate
     408   warning for security or privacy options.  In the few cases where this
     409   specification requires reporting of errors to the user, it is acceptable
     410   for such reporting to only be visible in an error console or log file.
     411   Likewise, requirements that an automated action be confirmed by the user
     412   before proceeding can me met via advance configuration choices,
     413   run-time options, or simply not proceeding with the unsafe action.
     414</t>
    391415</section>
    392416
    … …  
    16351659</t>
    16361660<t>
    1637    HTTP's use of Content-Length is significantly different from how it is
    1638    used in MIME, where it is an optional field used only within the
    1639    "message/external-body" media-type.
    1640 </t>
    1641 <t>
    16421661   Any Content-Length field value greater than or equal to zero is valid.
    16431662   Since there is no predefined limit to the length of an HTTP payload,
    … …  
    16581677   length.
    16591678</t>
     1679<x:note>
     1680  <t>
     1681   &Note; HTTP's use of Content-Length for message framing differs
     1682   significantly from the same field's use in MIME, where it is an optional
     1683   field used only within the "message/external-body" media-type.
     1684  </t>
     1685</x:note>
    16601686</section>
    16611687
Note: See TracChangeset for help on using the changeset viewer.