Ignore:
Timestamp:
12/03/12 03:57:38 (11 years ago)
Author:
fielding@…
Message:

Split connections into forwarding of messages by intermediaries and
connection management (relocations and minor wording additions only).
Move definition of Connection, Via, and Upgrade into connection management.
Related to #284.

Remove miscellaneous notes and now-empty header field section.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1582 r1583  
    487487      <link rel="Chapter" title="4 Transfer Codings" href="#rfc.section.4">
    488488      <link rel="Chapter" title="5 Message Routing" href="#rfc.section.5">
    489       <link rel="Chapter" title="6 Connections" href="#rfc.section.6">
    490       <link rel="Chapter" title="7 Miscellaneous notes that might disappear" href="#rfc.section.7">
    491       <link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8">
    492       <link rel="Chapter" title="9 IANA Considerations" href="#rfc.section.9">
    493       <link rel="Chapter" title="10 Security Considerations" href="#rfc.section.10">
    494       <link rel="Chapter" title="11 Acknowledgments" href="#rfc.section.11">
    495       <link rel="Chapter" href="#rfc.section.12" title="12 References">
     489      <link rel="Chapter" title="6 Connection Management" href="#rfc.section.6">
     490      <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7">
     491      <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8">
     492      <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9">
     493      <link rel="Chapter" href="#rfc.section.10" title="10 References">
    496494      <link rel="Appendix" title="A HTTP Version History" href="#rfc.section.A">
    497495      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    … …  
    712710               <li>5.4&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
    713711               <li>5.5&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    714                <li>5.6&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
     712               <li>5.6&nbsp;&nbsp;&nbsp;<a href="#intermediary.forwarding">Intermediary Forwarding</a><ul>
     713                     <li>5.6.1&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></li>
     714                     <li>5.6.2&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></li>
     715                  </ul>
     716               </li>
     717               <li>5.7&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
    715718            </ul>
    716719         </li>
    717          <li>6.&nbsp;&nbsp;&nbsp;<a href="#connections">Connections</a><ul>
    718                <li>6.1&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul>
    719                      <li>6.1.1&nbsp;&nbsp;&nbsp;<a href="#persistent.purpose">Purpose</a></li>
    720                      <li>6.1.2&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul>
    721                            <li>6.1.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
    722                            <li>6.1.2.2&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     720         <li>6.&nbsp;&nbsp;&nbsp;<a href="#connection.management">Connection Management</a><ul>
     721               <li>6.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
     722               <li>6.2&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     723               <li>6.3&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul>
     724                     <li>6.3.1&nbsp;&nbsp;&nbsp;<a href="#persistent.purpose">Purpose</a></li>
     725                     <li>6.3.2&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul>
     726                           <li>6.3.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
     727                           <li>6.3.2.2&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
    723728                        </ul>
    724729                     </li>
    725                      <li>6.1.3&nbsp;&nbsp;&nbsp;<a href="#persistent.proxy">Proxy Servers</a><ul>
    726                            <li>6.1.3.1&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></li>
    727                            <li>6.1.3.2&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></li>
    728                         </ul>
    729                      </li>
    730                      <li>6.1.4&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
    731                      <li>6.1.5&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
     730                     <li>6.3.3&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
     731                     <li>6.3.4&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
    732732                  </ul>
    733733               </li>
    734                <li>6.2&nbsp;&nbsp;&nbsp;<a href="#message.transmission.requirements">Message Transmission Requirements</a><ul>
    735                      <li>6.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
    736                      <li>6.2.2&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
    737                      <li>6.2.3&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
    738                      <li>6.2.4&nbsp;&nbsp;&nbsp;<a href="#closing.connections.on.error">Closing Connections on Error</a></li>
     734               <li>6.4&nbsp;&nbsp;&nbsp;<a href="#message.transmission.requirements">Message Transmission Requirements</a><ul>
     735                     <li>6.4.1&nbsp;&nbsp;&nbsp;<a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
     736                     <li>6.4.2&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
     737                     <li>6.4.3&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
     738                     <li>6.4.4&nbsp;&nbsp;&nbsp;<a href="#closing.connections.on.error">Closing Connections on Error</a></li>
     739                  </ul>
     740               </li>
     741               <li>6.5&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
     742                     <li>6.5.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
    739743                  </ul>
    740744               </li>
    741745            </ul>
    742746         </li>
    743          <li>7.&nbsp;&nbsp;&nbsp;<a href="#misc">Miscellaneous notes that might disappear</a><ul>
    744                <li>7.1&nbsp;&nbsp;&nbsp;<a href="#scheme.aliases">Scheme aliases considered harmful</a></li>
    745                <li>7.2&nbsp;&nbsp;&nbsp;<a href="#http.proxy">Use of HTTP for proxy communication</a></li>
    746                <li>7.3&nbsp;&nbsp;&nbsp;<a href="#http.intercept">Interception of HTTP for access control</a></li>
    747                <li>7.4&nbsp;&nbsp;&nbsp;<a href="#http.others">Use of HTTP by other protocols</a></li>
    748                <li>7.5&nbsp;&nbsp;&nbsp;<a href="#http.media">Use of HTTP by media type specification</a></li>
    749             </ul>
    750          </li>
    751          <li>8.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
    752                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    753                <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
    754                      <li>8.2.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
     747         <li>7.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
     748               <li>7.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     749               <li>7.2&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li>
     750               <li>7.3&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registrations</a><ul>
     751                     <li>7.3.1&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li>
     752                     <li>7.3.2&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li>
    755753                  </ul>
    756754               </li>
    757                <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     755               <li>7.4&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Transfer Coding Registry</a></li>
     756               <li>7.5&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
    758757            </ul>
    759758         </li>
    760          <li>9.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    761                <li>9.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    762                <li>9.2&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li>
    763                <li>9.3&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registrations</a><ul>
    764                      <li>9.3.1&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li>
    765                      <li>9.3.2&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li>
    766                   </ul>
    767                </li>
    768                <li>9.4&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Transfer Coding Registry</a></li>
    769                <li>9.5&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
     759         <li>8.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
     760               <li>8.1&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
     761               <li>8.2&nbsp;&nbsp;&nbsp;<a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
     762               <li>8.3&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
     763               <li>8.4&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
     764               <li>8.5&nbsp;&nbsp;&nbsp;<a href="#attack.proxies">Proxies and Caching</a></li>
     765               <li>8.6&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li>
     766               <li>8.7&nbsp;&nbsp;&nbsp;<a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
    770767            </ul>
    771768         </li>
    772          <li>10.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    773                <li>10.1&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
    774                <li>10.2&nbsp;&nbsp;&nbsp;<a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
    775                <li>10.3&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
    776                <li>10.4&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
    777                <li>10.5&nbsp;&nbsp;&nbsp;<a href="#attack.proxies">Proxies and Caching</a></li>
    778                <li>10.6&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li>
    779                <li>10.7&nbsp;&nbsp;&nbsp;<a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
    780             </ul>
    781          </li>
    782          <li>11.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
    783          <li>12.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    784                <li>12.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    785                <li>12.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     769         <li>9.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
     770         <li>10.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     771               <li>10.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     772               <li>10.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    786773            </ul>
    787774         </li>
    … …  
    913900      <div id="rfc.iref.r.2"></div>
    914901      <div id="rfc.iref.r.3"></div>
    915       <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 payload 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>).
     902      <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>).
    916903      </p>
    917904      <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
    918          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 payload 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>).
     905         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
     906         (<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>).
    919907      </p>
    920908      <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>
    … …  
    946934         a proxy via some other connection port or protocol instead of using the defaults.
    947935      </p>
    948       <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.1</a>.
     936      <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>.
    949937      </p>
    950938      <div id="rfc.iref.i.1"></div>
    … …  
    988976         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    989977         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    990          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 Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.3</a>) header fields for both connections.
     978         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 Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;6.2</a>) header fields for both connections.
    991979      </p>
    992980      <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
    … …  
    10711059      <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
    10721060         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
    1073          by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
     1061         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
    10741062      </p>
    10751063      <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
    … …  
    13001288         them.
    13011289      </p>
    1302       <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1290      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
    13031291      </p>
    13041292      <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
    … …  
    13581346      <p id="rfc.section.3.2.2.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
    13591347         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    1360          (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the
     1348         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the
    13611349         message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets
    13621350         (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream.
    … …  
    15201508      </p>
    15211509      <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
    1522          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;10.6</a>).
     1510         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>).
    15231511      </p>
    15241512      <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
    … …  
    16121600      <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
    16131601         on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple
    1614          requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.1.2.2</a>.
     1602         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.3.2.2</a>.
    16151603      </p>
    16161604      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    … …  
    17801768  TE:
    17811769  TE: trailers, deflate;q=0.5
    1782 </pre><p id="rfc.section.4.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;8.1</a>) whenever TE is present in an HTTP/1.1 message.
     1770</pre><p id="rfc.section.4.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>) whenever TE is present in an HTTP/1.1 message.
    17831771      </p>
    17841772      <p id="rfc.section.4.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
    … …  
    18731861      </p>
    18741862      <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>
    1875       <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained (<a href="#connections" title="Connections">Section&nbsp;6</a>), the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on
     1863      <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained (<a href="#connection.management" title="Connection Management">Section&nbsp;6</a>), the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on
    18761864         both the method being requested and whether the request is to a proxy.
    18771865      </p>
    … …  
    19021890         <p id="rfc.section.5.3.p.9"><span id="rfc.iref.a.2"></span> When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send the target URI in absolute-form as the request-target. The proxy is requested to either service that request from a valid
    19031891            cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to
    1904             the origin server indicated by the request-target. In order to avoid request loops, a proxy that forwards requests to other
    1905             proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
     1892            the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in <a href="#intermediary.forwarding" title="Intermediary Forwarding">Section&nbsp;5.6</a>.
    19061893         </p>
    19071894      </div>
    … …  
    19301917Host: www.example.org:8001
    19311918</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
    1932       <p id="rfc.section.5.3.p.20">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
    1933       </p>
    1934       <p id="rfc.section.5.3.p.21">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
    1935          except as noted above to replace an empty path with "/" or "*".
    1936       </p>
    19371919      <div id="rfc.iref.h.10"></div>
    19381920      <div id="rfc.iref.h.11"></div>
    … …  
    20011983         the effective request URI's authority component.
    20021984      </p>
    2003       <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    2004       <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    2005          messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    2006          on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
    2007          see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
    2008       </p>
    2009       <p id="rfc.section.5.6.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response.
    2010       </p>
    2011       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    2012       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
    2013       <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;<a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
    2014       <p id="rfc.section.6.1.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers
    2015          and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make
    2016          multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a
    2017          prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
    2018       </p>
    2019       <p id="rfc.section.6.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
    2020       <ul>
    2021          <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways,
    2022             tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
    2023          </li>
    2024          <li>HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without
    2025             waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.
    2026          </li>
    2027          <li>Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to
    2028             determine the congestion state of the network.
    2029          </li>
    2030          <li>Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.</li>
    2031          <li>HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using
    2032             future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old
    2033             semantics after an error is reported.
    2034          </li>
    2035       </ul>
    2036       <p id="rfc.section.6.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
    2037       </p>
    2038       <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
    2039       <p id="rfc.section.6.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
    2040          of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server.
    2041       </p>
    2042       <p id="rfc.section.6.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
    2043          takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
    2044       </p>
    2045       <h4 id="rfc.section.6.1.2.1"><a href="#rfc.section.6.1.2.1">6.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    2046       <p id="rfc.section.6.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header field including the connection-token
    2047          "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token "close".
    2048       </p>
    2049       <p id="rfc.section.6.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
    2050          a Connection header field with the connection-token close. In case the client does not want to maintain a connection for more
    2051          than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token close.
    2052       </p>
    2053       <p id="rfc.section.6.1.2.1.p.3">If either the client or the server sends the close token in the Connection header field, that request becomes the last one
    2054          for the connection.
    2055       </p>
    2056       <p id="rfc.section.6.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    2057       </p>
    2058       <p id="rfc.section.6.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>.
    2059       </p>
    2060       <h4 id="rfc.section.6.1.2.2"><a href="#rfc.section.6.1.2.2">6.1.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
    2061       <p id="rfc.section.6.1.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
    2062       </p>
    2063       <p id="rfc.section.6.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    2064       </p>
    2065       <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    2066          send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    2067       </p>
    2068       <h3 id="rfc.section.6.1.3"><a href="#rfc.section.6.1.3">6.1.3</a>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
    2069       <p id="rfc.section.6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;8.1</a>.
    2070       </p>
    2071       <p id="rfc.section.6.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects
    2072          to. Each persistent connection applies to only one transport link.
    2073       </p>
    2074       <p id="rfc.section.6.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
    2075       </p>
    2076       <h4 id="rfc.section.6.1.3.1"><a href="#rfc.section.6.1.3.1">6.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4>
    2077       <p id="rfc.section.6.1.3.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP header fields into two categories: </p>
     1985      <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>
     1986      <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
     1987         to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has
     1988         characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can
     1989         enhance (or interfere) with either direction of the stream.
     1990      </p>
     1991      <p id="rfc.section.5.6.p.2">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
     1992      </p>
     1993      <p id="rfc.section.5.6.p.3">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
     1994      </p>
     1995      <p id="rfc.section.5.6.p.4">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
     1996         except as noted above to replace an empty path with "/" or "*".
     1997      </p>
     1998      <p id="rfc.section.5.6.p.5">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>.
     1999      </p>
     2000      <h3 id="rfc.section.5.6.1"><a href="#rfc.section.5.6.1">5.6.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h3>
     2001      <p id="rfc.section.5.6.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP header fields into two categories: </p>
    20782002      <ul>
    20792003         <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields
    … …  
    20842008         </li>
    20852009      </ul>
    2086       <p id="rfc.section.6.1.3.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p>
     2010      <p id="rfc.section.5.6.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p>
    20872011      <ul>
    20882012         <li>Connection</li>
    … …  
    20952019         <li>Upgrade</li>
    20962020      </ul>
    2097       <p id="rfc.section.6.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
    2098       <p id="rfc.section.6.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;8.1</a>).
    2099       </p>
    2100       <h4 id="rfc.section.6.1.3.2"><a href="#rfc.section.6.1.3.2">6.1.3.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4>
    2101       <p id="rfc.section.6.1.3.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end header fields. A non-transforming
     2021      <p id="rfc.section.5.6.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
     2022      <p id="rfc.section.5.6.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a>).
     2023      </p>
     2024      <h3 id="rfc.section.5.6.2"><a href="#rfc.section.5.6.2">5.6.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h3>
     2025      <p id="rfc.section.5.6.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end header fields. A non-transforming
    21022026         proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header field unless the definition of that header field requires or specifically allows that.
    21032027      </p>
    2104       <p id="rfc.section.6.1.3.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
     2028      <p id="rfc.section.5.6.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
    21052029      </p>
    21062030      <ul>
    … …  
    21122036         <li>Server</li>
    21132037      </ul>
    2114       <p id="rfc.section.6.1.3.2.p.3">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response:
     2038      <p id="rfc.section.5.6.2.p.3">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response:
    21152039      </p>
    21162040      <ul>
    21172041         <li>Expires</li>
    21182042      </ul>
    2119       <p id="rfc.section.6.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
    2120       </p>
    2121       <p id="rfc.section.6.1.3.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
     2043      <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
     2044      </p>
     2045      <p id="rfc.section.5.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
    21222046      </p>
    21232047      <ul>
    … …  
    21262050         <li>Content-Type</li>
    21272051      </ul>
    2128       <p id="rfc.section.6.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    2129       </p>
    2130       <div class="note" id="rfc.section.6.1.3.2.p.7">
     2052      <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     2053      </p>
     2054      <div class="note" id="rfc.section.5.6.2.p.7">
    21312055         <p> <b>Warning:</b> Unnecessary modification of end-to-end header fields might cause authentication failures if stronger authentication mechanisms
    21322056            are introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
    21332057         </p>
    21342058      </div>
    2135       <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    2136       </p>
    2137       <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    2138       <p id="rfc.section.6.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
     2059      <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     2060      </p>
     2061      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
     2062      <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
     2063         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
     2064         on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
     2065         see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
     2066      </p>
     2067      <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response.
     2068      </p>
     2069      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connection.management" href="#connection.management">Connection Management</a></h1>
     2070      <div id="rfc.iref.c.13"></div>
     2071      <div id="rfc.iref.h.12"></div>
     2072      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
     2073      <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such
     2074         connection options <em class="bcp14">MUST</em> be removed or replaced before the message can be forwarded downstream by a proxy or gateway. This mechanism also allows the
     2075         sender to indicate which HTTP header fields used in the message are only intended for the immediate recipient ("hop-by-hop"),
     2076         as opposed to all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future
     2077         connection-specific extensions to be deployed in HTTP without fear that they will be blindly forwarded by previously deployed
     2078         intermediaries.
     2079      </p>
     2080      <p id="rfc.section.6.1.p.2">The Connection header field's value has the following grammar:</p>
     2081      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
     2082  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
     2083</pre><p id="rfc.section.6.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove
     2084         any header field(s) from the message with the same name as the connection-token, and then remove the Connection header field
     2085         itself or replace it with the sender's own connection options for the forwarded message.
     2086      </p>
     2087      <p id="rfc.section.6.1.p.5">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
     2088         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     2089      </p>
     2090      <p id="rfc.section.6.1.p.6">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
     2091         field might not be needed if there are no parameters associated with that connection option. Recipients that trigger certain
     2092         connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-token rather than only the presence of the optional header field. In other words,
     2093         if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient <em class="bcp14">MUST</em> ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially
     2094         conformant.
     2095      </p>
     2096      <p id="rfc.section.6.1.p.7">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
     2097         that the new connection-token does not share the same name as an unrelated header field that might already be deployed. Defining
     2098         a new connection-token essentially reserves that potential field-name for carrying additional information related to the connection
     2099         option, since it would be unwise for senders to use that field-name for anything else.
     2100      </p>
     2101      <p id="rfc.section.6.1.p.8">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
     2102         of the response. For example,
     2103      </p>
     2104      <div id="rfc.figure.u.60"></div><pre class="text">  Connection: close
     2105</pre><p id="rfc.section.6.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.3</a>) after the current request/response is complete.
     2106      </p>
     2107      <p id="rfc.section.6.1.p.11">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
     2108      </p>
     2109      <p id="rfc.section.6.1.p.12">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code.
     2110      </p>
     2111      <div id="rfc.iref.v.1"></div>
     2112      <div id="rfc.iref.h.13"></div>
     2113      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
     2114      <p id="rfc.section.6.2.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
     2115         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
     2116         systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
     2117         of all senders along the request/response chain.
     2118      </p>
     2119      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
     2120                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
     2121  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
     2122  <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
     2123  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
     2124</pre><p id="rfc.section.6.2.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
     2125         the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
     2126         so that information about the protocol capabilities of upstream applications remains visible to all recipients.
     2127      </p>
     2128      <p id="rfc.section.6.2.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
     2129         number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
     2130         be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
     2131      </p>
     2132      <p id="rfc.section.6.2.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
     2133      </p>
     2134      <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
     2135         fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
     2136      </p>
     2137      <p id="rfc.section.6.2.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
     2138         HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
     2139         server at www.example.com. The request received by www.example.com would then have the following Via header field:
     2140      </p>
     2141      <div id="rfc.figure.u.62"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2142</pre><p id="rfc.section.6.2.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
     2143         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
     2144      </p>
     2145      <p id="rfc.section.6.2.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
     2146         For example,
     2147      </p>
     2148      <div id="rfc.figure.u.63"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2149</pre><p id="rfc.section.6.2.p.12">could be collapsed to</p>
     2150      <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2151</pre><p id="rfc.section.6.2.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
     2152         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
     2153      </p>
     2154      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
     2155      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
     2156      <p id="rfc.section.6.3.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers
     2157         and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make
     2158         multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a
     2159         prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
     2160      </p>
     2161      <p id="rfc.section.6.3.1.p.2">Persistent HTTP connections have a number of advantages: </p>
     2162      <ul>
     2163         <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways,
     2164            tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
     2165         </li>
     2166         <li>HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without
     2167            waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.
     2168         </li>
     2169         <li>Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to
     2170            determine the congestion state of the network.
     2171         </li>
     2172         <li>Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.</li>
     2173         <li>HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using
     2174            future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old
     2175            semantics after an error is reported.
     2176         </li>
     2177      </ul>
     2178      <p id="rfc.section.6.3.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
     2179      </p>
     2180      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
     2181      <p id="rfc.section.6.3.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
     2182         of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server.
     2183      </p>
     2184      <p id="rfc.section.6.3.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
     2185         takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
     2186      </p>
     2187      <h4 id="rfc.section.6.3.2.1"><a href="#rfc.section.6.3.2.1">6.3.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
     2188      <p id="rfc.section.6.3.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header field including the connection-token
     2189         "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token "close".
     2190      </p>
     2191      <p id="rfc.section.6.3.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
     2192         a Connection header field with the connection-token close. In case the client does not want to maintain a connection for more
     2193         than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token close.
     2194      </p>
     2195      <p id="rfc.section.6.3.2.1.p.3">If either the client or the server sends the close token in the Connection header field, that request becomes the last one
     2196         for the connection.
     2197      </p>
     2198      <p id="rfc.section.6.3.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
     2199      </p>
     2200      <p id="rfc.section.6.3.2.1.p.5">Each persistent connection applies to only one transport link.</p>
     2201      <p id="rfc.section.6.3.2.1.p.6">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
     2202      </p>
     2203      <p id="rfc.section.6.3.2.1.p.7">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>.
     2204      </p>
     2205      <h4 id="rfc.section.6.3.2.2"><a href="#rfc.section.6.3.2.2">6.3.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
     2206      <p id="rfc.section.6.3.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
     2207      </p>
     2208      <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
     2209      </p>
     2210      <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2211         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
     2212      </p>
     2213      <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
     2214      <p id="rfc.section.6.3.3.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
    21392215         might make this a higher value since it is likely that the client will be making more connections through the same server.
    21402216         The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client
    21412217         or the server.
    21422218      </p>
    2143       <p id="rfc.section.6.1.4.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does
     2219      <p id="rfc.section.6.3.3.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does
    21442220         not detect the other side's close promptly it could cause unnecessary resource drain on the network.
    21452221      </p>
    2146       <p id="rfc.section.6.1.4.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time
     2222      <p id="rfc.section.6.3.3.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time
    21472223         that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed
    21482224         while it was idle, but from the client's point of view, a request is in progress.
    21492225      </p>
    2150       <p id="rfc.section.6.1.4.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
    2151       </p>
    2152       <p id="rfc.section.6.1.4.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
     2226      <p id="rfc.section.6.3.3.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
     2227      </p>
     2228      <p id="rfc.section.6.3.3.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
    21532229         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    21542230         clients to be conservative when opening multiple connections.
    21552231      </p>
    2156       <p id="rfc.section.6.1.4.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
     2232      <p id="rfc.section.6.3.3.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
    21572233         server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used
    21582234         consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side
    21592235         effects in congested networks.
    21602236      </p>
    2161       <p id="rfc.section.6.1.4.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
    2162       <h3 id="rfc.section.6.1.5"><a href="#rfc.section.6.1.5">6.1.5</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    2163       <p id="rfc.section.6.1.5.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
     2237      <p id="rfc.section.6.3.3.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
     2238      <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
     2239      <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    21642240         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    21652241         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    21662242      </p>
    2167       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
    2168       <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
    2169       <p id="rfc.section.6.2.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
     2243      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
     2244      <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
     2245      <p id="rfc.section.6.4.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
    21702246         connections with the expectation that clients will retry. The latter technique can exacerbate network congestion.
    21712247      </p>
    2172       <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    2173       <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
     2248      <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
     2249      <p id="rfc.section.6.4.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
    21742250         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    21752251      </p>
    2176       <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2177       <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     2252      <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
     2253      <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    21782254         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21792255         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    21802256         looking at the body.
    21812257      </p>
    2182       <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
     2258      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21832259      <ul>
    21842260         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    … …  
    21872263         </li>
    21882264      </ul>
    2189       <p id="rfc.section.6.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
     2265      <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    21902266         100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client
    21912267         sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code,
    21922268         the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
    21932269      </p>
    2194       <p id="rfc.section.6.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
     2270      <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    21952271      <ul>
    21962272         <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
    … …  
    22162292         </li>
    22172293      </ul>
    2218       <p id="rfc.section.6.2.3.p.5">Requirements for HTTP/1.1 proxies: </p>
     2294      <p id="rfc.section.6.4.3.p.5">Requirements for HTTP/1.1 proxies: </p>
    22192295      <ul>
    22202296         <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either
    … …  
    22312307         </li>
    22322308      </ul>
    2233       <h3 id="rfc.section.6.2.4"><a href="#rfc.section.6.2.4">6.2.4</a>&nbsp;<a id="closing.connections.on.error" href="#closing.connections.on.error">Closing Connections on Error</a></h3>
    2234       <p id="rfc.section.6.2.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
     2309      <h3 id="rfc.section.6.4.4"><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;<a id="closing.connections.on.error" href="#closing.connections.on.error">Closing Connections on Error</a></h3>
     2310      <p id="rfc.section.6.4.4.p.1">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
    22352311         the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send
    22362312         a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted
    22372313         by the HTTP application.
    22382314      </p>
    2239       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="misc" href="#misc">Miscellaneous notes that might disappear</a></h1>
    2240       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="scheme.aliases" href="#scheme.aliases">Scheme aliases considered harmful</a></h2>
    2241       <p id="rfc.section.7.1.p.1"> <span class="comment" id="TBD-aliases-harmful">[<a href="#TBD-aliases-harmful" class="smpl">TBD-aliases-harmful</a>: describe why aliases like webcal are harmful.]</span>
    2242       </p>
    2243       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="http.proxy" href="#http.proxy">Use of HTTP for proxy communication</a></h2>
    2244       <p id="rfc.section.7.2.p.1"> <span class="comment" id="TBD-proxy-other">[<a href="#TBD-proxy-other" class="smpl">TBD-proxy-other</a>: Configured to use HTTP to proxy HTTP or other protocols.]</span>
    2245       </p>
    2246       <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="http.intercept" href="#http.intercept">Interception of HTTP for access control</a></h2>
    2247       <p id="rfc.section.7.3.p.1"> <span class="comment" id="TBD-intercept">[<a href="#TBD-intercept" class="smpl">TBD-intercept</a>: Interception of HTTP traffic for initiating access control.]</span>
    2248       </p>
    2249       <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="http.others" href="#http.others">Use of HTTP by other protocols</a></h2>
    2250       <p id="rfc.section.7.4.p.1"> <span class="comment" id="TBD-profiles">[<a href="#TBD-profiles" class="smpl">TBD-profiles</a>: Profiles of HTTP defined by other protocol. Extensions of HTTP like WebDAV.]</span>
    2251       </p>
    2252       <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="http.media" href="#http.media">Use of HTTP by media type specification</a></h2>
    2253       <p id="rfc.section.7.5.p.1"> <span class="comment" id="TBD-hypertext">[<a href="#TBD-hypertext" class="smpl">TBD-hypertext</a>: Instructions on composing HTTP requests via hypertext formats.]</span>
    2254       </p>
    2255       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
    2256       <p id="rfc.section.8.p.1">This section defines the syntax and semantics of HTTP header fields related to message origination, framing, and routing.</p>
    2257       <div id="rfc.table.u.1">
    2258          <table class="tt full left" cellpadding="3" cellspacing="0">
    2259             <thead>
    2260                <tr>
    2261                   <th>Header Field Name</th>
    2262                   <th>Defined in...</th>
    2263                </tr>
    2264             </thead>
    2265             <tbody>
    2266                <tr>
    2267                   <td class="left">Connection</td>
    2268                   <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;8.1</a></td>
    2269                </tr>
    2270                <tr>
    2271                   <td class="left">Content-Length</td>
    2272                   <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;3.3.2</a></td>
    2273                </tr>
    2274                <tr>
    2275                   <td class="left">Host</td>
    2276                   <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;5.4</a></td>
    2277                </tr>
    2278                <tr>
    2279                   <td class="left">TE</td>
    2280                   <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;4.4</a></td>
    2281                </tr>
    2282                <tr>
    2283                   <td class="left">Trailer</td>
    2284                   <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;4.5</a></td>
    2285                </tr>
    2286                <tr>
    2287                   <td class="left">Transfer-Encoding</td>
    2288                   <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;3.3.1</a></td>
    2289                </tr>
    2290                <tr>
    2291                   <td class="left">Upgrade</td>
    2292                   <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.2</a></td>
    2293                </tr>
    2294                <tr>
    2295                   <td class="left">Via</td>
    2296                   <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;8.3</a></td>
    2297                </tr>
    2298             </tbody>
    2299          </table>
    2300       </div>
    2301       <div id="rfc.iref.c.13"></div>
    2302       <div id="rfc.iref.h.12"></div>
    2303       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    2304       <p id="rfc.section.8.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such
    2305          connection options <em class="bcp14">MUST</em> be removed or replaced before the message can be forwarded downstream by a proxy or gateway. This mechanism also allows the
    2306          sender to indicate which HTTP header fields used in the message are only intended for the immediate recipient ("hop-by-hop"),
    2307          as opposed to all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future
    2308          connection-specific extensions to be deployed in HTTP without fear that they will be blindly forwarded by previously deployed
    2309          intermediaries.
    2310       </p>
    2311       <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p>
    2312       <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
    2313   <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    2314 </pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove
    2315          any header field(s) from the message with the same name as the connection-token, and then remove the Connection header field
    2316          itself or replace it with the sender's own connection options for the forwarded message.
    2317       </p>
    2318       <p id="rfc.section.8.1.p.5">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
    2319          in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    2320       </p>
    2321       <p id="rfc.section.8.1.p.6">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
    2322          field might not be needed if there are no parameters associated with that connection option. Recipients that trigger certain
    2323          connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-token rather than only the presence of the optional header field. In other words,
    2324          if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient <em class="bcp14">MUST</em> ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially
    2325          conformant.
    2326       </p>
    2327       <p id="rfc.section.8.1.p.7">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
    2328          that the new connection-token does not share the same name as an unrelated header field that might already be deployed. Defining
    2329          a new connection-token essentially reserves that potential field-name for carrying additional information related to the connection
    2330          option, since it would be unwise for senders to use that field-name for anything else.
    2331       </p>
    2332       <p id="rfc.section.8.1.p.8">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
    2333          of the response. For example,
    2334       </p>
    2335       <div id="rfc.figure.u.60"></div><pre class="text">  Connection: close
    2336 </pre><p id="rfc.section.8.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.1</a>) after the current request/response is complete.
    2337       </p>
    2338       <p id="rfc.section.8.1.p.11">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
    2339       </p>
    2340       <p id="rfc.section.8.1.p.12">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code.
    2341       </p>
    23422315      <div id="rfc.iref.u.5"></div>
    2343       <div id="rfc.iref.h.13"></div>
    2344       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
    2345       <p id="rfc.section.8.2.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
     2316      <div id="rfc.iref.h.14"></div>
     2317      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
     2318      <p id="rfc.section.6.5.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
    23462319         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    23472320      </p>
    2348       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.87"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>          = 1#<a href="#header.upgrade" class="smpl">protocol</a>
     2321      <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.93"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>          = 1#<a href="#header.upgrade" class="smpl">protocol</a>
    23492322
    23502323  <a href="#header.upgrade" class="smpl">protocol</a>         = <a href="#header.upgrade" class="smpl">protocol-name</a> ["/" <a href="#header.upgrade" class="smpl">protocol-version</a>]
    23512324  <a href="#header.upgrade" class="smpl">protocol-name</a>    = <a href="#rule.token.separators" class="smpl">token</a>
    23522325  <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    2353 </pre><p id="rfc.section.8.2.p.3">For example,</p>
    2354       <div id="rfc.figure.u.62"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    2355 </pre><p id="rfc.section.8.2.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
     2326</pre><p id="rfc.section.6.5.p.3">For example,</p>
     2327      <div id="rfc.figure.u.66"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     2328</pre><p id="rfc.section.6.5.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
    23562329         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    23572330         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
    … …  
    23602333         the server, possibly according to the nature of the request method or target resource).
    23612334      </p>
    2362       <p id="rfc.section.8.2.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
     2335      <p id="rfc.section.6.5.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
    23632336         Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    23642337         and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
    23652338         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field.
    23662339      </p>
    2367       <p id="rfc.section.8.2.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    2368       </p>
    2369       <p id="rfc.section.8.2.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
     2340      <p id="rfc.section.6.5.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
     2341      </p>
     2342      <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    23702343         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    23712344      </p>
    2372       <p id="rfc.section.8.2.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
     2345      <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
    23732346         to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
    23742347      </p>
    2375       <p id="rfc.section.8.2.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     2348      <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
    23762349         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
    23772350         below.
    23782351      </p>
    2379       <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
    2380       <p id="rfc.section.8.2.1.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade
     2352      <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
     2353      <p id="rfc.section.6.5.1.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade
    23812354         header field. Each registered protocol-name is associated with contact information and an optional set of specifications that
    23822355         details how the connection will be processed after it has been upgraded.
    23832356      </p>
    2384       <p id="rfc.section.8.2.1.p.2">Registrations require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules:
     2357      <p id="rfc.section.6.5.1.p.2">Registrations require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules:
    23852358      </p>
    23862359      <ol>
    … …  
    24002373         </li>
    24012374      </ol>
    2402       <div id="rfc.iref.v.1"></div>
    2403       <div id="rfc.iref.h.14"></div>
    2404       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    2405       <p id="rfc.section.8.3.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
    2406          on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
    2407          systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
    2408          of all senders along the request/response chain.
    2409       </p>
    2410       <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
    2411                           [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    2412   <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
    2413   <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
    2414   <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    2415 </pre><p id="rfc.section.8.3.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    2416          the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
    2417          so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    2418       </p>
    2419       <p id="rfc.section.8.3.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
    2420          number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    2421          be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
    2422       </p>
    2423       <p id="rfc.section.8.3.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    2424       </p>
    2425       <p id="rfc.section.8.3.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
    2426          fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    2427       </p>
    2428       <p id="rfc.section.8.3.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    2429          HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
    2430          server at www.example.com. The request received by www.example.com would then have the following Via header field:
    2431       </p>
    2432       <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    2433 </pre><p id="rfc.section.8.3.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    2434          the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    2435       </p>
    2436       <p id="rfc.section.8.3.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
    2437          For example,
    2438       </p>
    2439       <div id="rfc.figure.u.65"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    2440 </pre><p id="rfc.section.8.3.p.12">could be collapsed to</p>
    2441       <div id="rfc.figure.u.66"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    2442 </pre><p id="rfc.section.8.3.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    2443          by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    2444       </p>
    2445       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    2446       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    2447       <p id="rfc.section.9.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     2375      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     2376      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
     2377      <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    24482378      </p>
    24492379      <div id="rfc.table.1">
    … …  
    24632393                  <td class="left">http</td>
    24642394                  <td class="left">standard</td>
    2465                   <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;8.1</a>
     2395                  <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>
    24662396                  </td>
    24672397               </tr>
    … …  
    24702400                  <td class="left">http</td>
    24712401                  <td class="left">standard</td>
    2472                   <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">Section&nbsp;3.3.2</a>
     2402                  <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;3.3.2</a>
    24732403                  </td>
    24742404               </tr>
    … …  
    24772407                  <td class="left">http</td>
    24782408                  <td class="left">standard</td>
    2479                   <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a>
     2409                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;5.4</a>
    24802410                  </td>
    24812411               </tr>
    … …  
    24842414                  <td class="left">http</td>
    24852415                  <td class="left">standard</td>
    2486                   <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;4.4</a>
     2416                  <td class="left"> <a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;4.4</a>
    24872417                  </td>
    24882418               </tr>
    … …  
    24912421                  <td class="left">http</td>
    24922422                  <td class="left">standard</td>
    2493                   <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;4.5</a>
     2423                  <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;4.5</a>
    24942424                  </td>
    24952425               </tr>
    … …  
    24982428                  <td class="left">http</td>
    24992429                  <td class="left">standard</td>
    2500                   <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;3.3.1</a>
     2430                  <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;3.3.1</a>
    25012431                  </td>
    25022432               </tr>
    … …  
    25052435                  <td class="left">http</td>
    25062436                  <td class="left">standard</td>
    2507                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;8.2</a>
     2437                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;6.5</a>
    25082438                  </td>
    25092439               </tr>
    … …  
    25122442                  <td class="left">http</td>
    25132443                  <td class="left">standard</td>
    2514                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;8.3</a>
     2444                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;6.2</a>
    25152445                  </td>
    25162446               </tr>
    … …  
    25182448         </table>
    25192449      </div>
    2520       <p id="rfc.section.9.1.p.2">Furthermore, the header field name "Close" shall be registered as "reserved", as its use as HTTP header field would be in
    2521          conflict with the use of the "close" connection option for the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;8.1</a>).
    2522       </p>
    2523       <div id="rfc.table.u.2">
     2450      <p id="rfc.section.7.1.p.2">Furthermore, the header field name "Close" shall be registered as "reserved", as its use as HTTP header field would be in
     2451         conflict with the use of the "close" connection option for the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>).
     2452      </p>
     2453      <div id="rfc.table.u.1">
    25242454         <table class="tt full left" cellpadding="3" cellspacing="0">
    25252455            <thead>
    … …  
    25362466                  <td class="left">http</td>
    25372467                  <td class="left">reserved</td>
    2538                   <td class="left"> <a href="#header.field.registration" title="Header Field Registration">Section&nbsp;9.1</a>
     2468                  <td class="left"> <a href="#header.field.registration" title="Header Field Registration">Section&nbsp;7.1</a>
    25392469                  </td>
    25402470               </tr>
    … …  
    25422472         </table>
    25432473      </div>
    2544       <p id="rfc.section.9.1.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    2545       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2>
    2546       <p id="rfc.section.9.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.7.1</a> and <a href="#https.uri" title="https URI scheme">2.7.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
    2547       </p>
    2548       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
    2549       <p id="rfc.section.9.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following
     2474      <p id="rfc.section.7.1.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     2475      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2>
     2476      <p id="rfc.section.7.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.7.1</a> and <a href="#https.uri" title="https URI scheme">2.7.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
     2477      </p>
     2478      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
     2479      <p id="rfc.section.7.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following
    25502480         is to be registered with IANA (see <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>).
    25512481      </p>
    25522482      <div id="rfc.iref.m.3"></div>
    25532483      <div id="rfc.iref.m.4"></div>
    2554       <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a>&nbsp;<a id="internet.media.type.message.http" href="#internet.media.type.message.http">Internet Media Type message/http</a></h3>
    2555       <p id="rfc.section.9.3.1.p.1">The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions
     2484      <h3 id="rfc.section.7.3.1"><a href="#rfc.section.7.3.1">7.3.1</a>&nbsp;<a id="internet.media.type.message.http" href="#internet.media.type.message.http">Internet Media Type message/http</a></h3>
     2485      <p id="rfc.section.7.3.1.p.1">The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions
    25562486         for all "message" types regarding line length and encodings.
    25572487      </p>
    2558       <p id="rfc.section.9.3.1.p.2"> </p>
     2488      <p id="rfc.section.7.3.1.p.2"> </p>
    25592489      <dl>
    25602490         <dt>Type name:</dt>
    … …  
    25822512         <dd>none</dd>
    25832513         <dt>Published specification:</dt>
    2584          <dd>This specification (see <a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>).
     2514         <dd>This specification (see <a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>).
    25852515         </dd>
    25862516         <dt>Applications that use this media type:</dt>
    … …  
    26072537      <div id="rfc.iref.m.5"></div>
    26082538      <div id="rfc.iref.a.5"></div>
    2609       <h3 id="rfc.section.9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a>&nbsp;<a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3>
    2610       <p id="rfc.section.9.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p>
    2611       <p id="rfc.section.9.3.2.p.2"> </p>
     2539      <h3 id="rfc.section.7.3.2"><a href="#rfc.section.7.3.2">7.3.2</a>&nbsp;<a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3>
     2540      <p id="rfc.section.7.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p>
     2541      <p id="rfc.section.7.3.2.p.2"> </p>
    26122542      <dl>
    26132543         <dt>Type name:</dt>
    … …  
    26372567         <dd>none</dd>
    26382568         <dt>Published specification:</dt>
    2639          <dd>This specification (see <a href="#internet.media.type.application.http" title="Internet Media Type application/http">Section&nbsp;9.3.2</a>).
     2569         <dd>This specification (see <a href="#internet.media.type.application.http" title="Internet Media Type application/http">Section&nbsp;7.3.2</a>).
    26402570         </dd>
    26412571         <dt>Applications that use this media type:</dt>
    … …  
    26602590         <dd>IESG</dd>
    26612591      </dl>
    2662       <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2>
    2663       <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;4.3</a> of this document.
    2664       </p>
    2665       <p id="rfc.section.9.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
     2592      <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2>
     2593      <p id="rfc.section.7.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;4.3</a> of this document.
     2594      </p>
     2595      <p id="rfc.section.7.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
    26662596      </p>
    26672597      <div id="rfc.table.2">
    … …  
    27042634         </table>
    27052635      </div>
    2706       <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
    2707       <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.2.1</a> of this document.
    2708       </p>
    2709       <p id="rfc.section.9.5.p.2">The HTTP Upgrade Token Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
    2710       </p>
    2711       <div id="rfc.table.u.3">
     2636      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
     2637      <p id="rfc.section.7.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;6.5.1</a> of this document.
     2638      </p>
     2639      <p id="rfc.section.7.5.p.2">The HTTP Upgrade Token Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
     2640      </p>
     2641      <div id="rfc.table.u.2">
    27122642         <table class="tt full left" cellpadding="3" cellspacing="0">
    27132643            <thead>
    … …  
    27282658         </table>
    27292659      </div>
    2730       <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    2731       <p id="rfc.section.10.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
     2660      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     2661      <p id="rfc.section.8.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
    27322662         as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
    27332663         make some suggestions for reducing security risks.
    27342664      </p>
    2735       <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
    2736       <p id="rfc.section.10.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g., the user's name, location, mail address, passwords,
     2665      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
     2666      <p id="rfc.section.8.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g., the user's name, location, mail address, passwords,
    27372667         encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information. We very strongly recommend that a convenient interface
    27382668         be provided for the user to control dissemination of such information, and that designers and implementors be particularly
    … …  
    27402670         highly adverse publicity for the implementor's company.
    27412671      </p>
    2742       <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
    2743       <p id="rfc.section.10.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects
     2672      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
     2673      <p id="rfc.section.8.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects
    27442674         of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries.
    27452675         People using HTTP to provide data are responsible for ensuring that such material is not distributed without the permission
    27462676         of any individuals that are identifiable by the published results.
    27472677      </p>
    2748       <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
    2749       <p id="rfc.section.10.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
     2678      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
     2679      <p id="rfc.section.8.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
    27502680         If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft
    27512681         Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
    … …  
    27552685         bugs in such HTTP server implementations have turned into security risks.
    27562686      </p>
    2757       <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
    2758       <p id="rfc.section.10.4.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the
     2687      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
     2688      <p id="rfc.section.8.4.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the
    27592689         deliberate misassociation of IP addresses and DNS names not protected by DNSSec. Clients need to be cautious in assuming the
    27602690         validity of an IP number/DNS name association unless the response is protected by DNSSec (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>).
    27612691      </p>
    2762       <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2>
    2763       <p id="rfc.section.10.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise
     2692      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2>
     2693      <p id="rfc.section.8.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise
    27642694         of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related
    27652695         information, personal information about individual users and organizations, and proprietary information belonging to users
    … …  
    27672697         might be used in the commission of a wide range of potential attacks.
    27682698      </p>
    2769       <p id="rfc.section.10.5.p.2">Proxy operators need to protect the systems on which proxies run as they would protect any system that contains or transports
     2699      <p id="rfc.section.8.5.p.2">Proxy operators need to protect the systems on which proxies run as they would protect any system that contains or transports
    27702700         sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information,
    27712701         and/or information about organizations. Log information needs to be carefully guarded, and appropriate guidelines for use
    2772          need to be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;10.2</a>).
    2773       </p>
    2774       <p id="rfc.section.10.5.p.3">Proxy implementors need to consider the privacy and security implications of their design and coding decisions, and of the
     2702         need to be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;8.2</a>).
     2703      </p>
     2704      <p id="rfc.section.8.5.p.3">Proxy implementors need to consider the privacy and security implications of their design and coding decisions, and of the
    27752705         configuration options they provide to proxy operators (especially the default configuration).
    27762706      </p>
    2777       <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no more trustworthy than the people who run them; HTTP itself cannot solve
     2707      <p id="rfc.section.8.5.p.4">Users of a proxy need to be aware that proxies are no more trustworthy than the people who run them; HTTP itself cannot solve
    27782708         this problem.
    27792709      </p>
    2780       <p id="rfc.section.10.5.p.5">The judicious use of cryptography, when appropriate, might suffice to protect against a broad range of security and privacy
     2710      <p id="rfc.section.8.5.p.5">The judicious use of cryptography, when appropriate, might suffice to protect against a broad range of security and privacy
    27812711         attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
    27822712      </p>
    2783       <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></h2>
    2784       <p id="rfc.section.10.6.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform
     2713      <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></h2>
     2714      <p id="rfc.section.8.6.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform
    27852715         a Denial of Service against implementations that accept fields with unlimited lengths.
    27862716      </p>
    2787       <p id="rfc.section.10.6.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
     2717      <p id="rfc.section.8.6.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
    27882718         that most implementations will choose substantially higher limits.
    27892719      </p>
    2790       <p id="rfc.section.10.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    2791       </p>
    2792       <p id="rfc.section.10.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
    2793       </p>
    2794       <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a>&nbsp;<a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>
    2795       <p id="rfc.section.10.7.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
    2796       <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2797       <p id="rfc.section.11.p.1">This document revision builds on the work that went into <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a> and its predecessors. See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for detailed acknowledgements.
    2798       </p>
    2799       <p id="rfc.section.11.p.2">Since 1999, many contributors have helped by reporting bugs, asking smart questions, drafting and reviewing text, and discussing
     2720      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2721      </p>
     2722      <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
     2723      </p>
     2724      <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>
     2725      <p id="rfc.section.8.7.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
     2726      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     2727      <p id="rfc.section.9.p.1">This document revision builds on the work that went into <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a> and its predecessors. See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for detailed acknowledgements.
     2728      </p>
     2729      <p id="rfc.section.9.p.2">Since 1999, many contributors have helped by reporting bugs, asking smart questions, drafting and reviewing text, and discussing
    28002730         open issues:
    28012731      </p>
    2802       <p id="rfc.section.11.p.3">Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov,
     2732      <p id="rfc.section.9.p.3">Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov,
    28032733         Alexey Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, Anne van Kesteren,
    28042734         Anthony Bryan, Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Niven-Jenkins, Bil Corry, Bill
    … …  
    28282758         Yogesh Bang, Yutaka Oiwa, Zed A. Shaw, and Zhong Yu.
    28292759      </p>
    2830       <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References
     2760      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
    28312761      </h1>
    2832       <h2 id="rfc.references.1"><a href="#rfc.section.12.1" id="rfc.section.12.1">12.1</a> Normative References
     2762      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    28332763      </h2>
    28342764      <table>                     
    … …  
    28872817         </tr>
    28882818      </table>
    2889       <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References
     2819      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
    28902820      </h2>
    28912821      <table>                                                 
    … …  
    30562986      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30572987      <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3>
    3058       <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>) are among the most important changes defined by HTTP/1.1.
     2988      <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;5.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>) are among the most important changes defined by HTTP/1.1.
    30592989      </p>
    30602990      <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism
    … …  
    31113041      </p>
    31123042      <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent.
    3113          Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.1.4</a>)
    3114       </p>
    3115       <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain cirumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section&nbsp;6.2</a>)
    3116       </p>
    3117       <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;8</a>)
    3118       </p>
    3119       <p id="rfc.section.A.2.p.14">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section&nbsp;8.1</a>)
    3120       </p>
    3121       <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.2</a>)
     3043         Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.3.3</a>)
     3044      </p>
     3045      <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain cirumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section&nbsp;6.4</a>)
     3046      </p>
     3047      <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value.</p>
     3048      <p id="rfc.section.A.2.p.14">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;6.1</a>)
     3049      </p>
     3050      <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.5</a>)
    31223051      </p>
    31233052      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="changes.from.rfc.2817" href="#changes.from.rfc.2817">Changes from RFC 2817</a></h2>
    3124       <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.2.1</a>)
     3053      <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;6.5.1</a>)
    31253054      </p>
    31263055      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    36543583                  <li>absolute-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">5.3</a></li>
    36553584                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li>
    3656                   <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>9.3.2</b></a></li>
     3585                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>7.3.2</b></a></li>
    36573586                  <li>asterisk-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.3</a></li>
    36583587                  <li>authority-form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">5.3</a></li>
    … …  
    36793608                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    36803609                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3681                   <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.4</a>, <a href="#rfc.xref.header.connection.5">6.1.2</a>, <a href="#rfc.xref.header.connection.6">6.1.3</a>, <a href="#rfc.xref.header.connection.7">6.1.3.1</a>, <a href="#rfc.xref.header.connection.8">8</a>, <a href="#rfc.iref.c.13"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.2</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
    3682                   <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">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
     3610                  <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.4</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>
     3611                  <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>
    36833612               </ul>
    36843613            </li>
    … …  
    37123641                        <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>4.1</b></a></li>
    37133642                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.4</b></a></li>
    3714                         <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.1</b></a></li>
    3715                         <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.1</b></a></li>
     3643                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>6.1</b></a></li>
     3644                        <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>6.1</b></a></li>
    37163645                        <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>3.3.2</b></a></li>
    37173646                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    … …  
    37463675                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    37473676                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    3748                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>8.3</b></a></li>
    3749                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>8.3</b></a></li>
    3750                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>8.3</b></a></li>
     3677                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>6.2</b></a></li>
     3678                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>6.2</b></a></li>
     3679                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>6.2</b></a></li>
    37513680                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.4</b></a></li>
    37523681                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>4.1</b></a></li>
    … …  
    37583687                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>4.4.1</b></a></li>
    37593688                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.2</b></a></li>
    3760                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>8.3</b></a></li>
    3761                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.3</b></a></li>
     3689                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>6.2</b></a></li>
     3690                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>6.2</b></a></li>
    37623691                        <li><tt>request-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>3.1.1</b></a></li>
    37633692                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.3</b></a></li>
    … …  
    37803709                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>4</b></a></li>
    37813710                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    3782                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>8.2</b></a></li>
     3711                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.5</b></a></li>
    37833712                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    37843713                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    37853714                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>4</b></a></li>
    37863715                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3787                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.3</b></a></li>
     3716                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>6.2</b></a></li>
    37883717                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.4</b></a></li>
    37893718                     </ul>
    … …  
    37963725                  <li>Header Fields&nbsp;&nbsp;
    37973726                     <ul>
    3798                         <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.4</a>, <a href="#rfc.xref.header.connection.5">6.1.2</a>, <a href="#rfc.xref.header.connection.6">6.1.3</a>, <a href="#rfc.xref.header.connection.7">6.1.3.1</a>, <a href="#rfc.xref.header.connection.8">8</a>, <a href="#rfc.iref.h.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.2</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
    3799                         <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">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
    3800                         <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">8</a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
    3801                         <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.h.8"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
    3802                         <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
    3803                         <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">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    3804                         <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.2</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    3805                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.3</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
     3727                        <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.4</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>
     3728                        <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>
     3729                        <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>
     3730                        <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.h.8"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">7.1</a></li>
     3731                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>
     3732                        <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></li>
     3733                        <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>
     3734                        <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>
    38063735                     </ul>
    38073736                  </li>
    38083737                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    38093738                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3810                   <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">8</a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3739                  <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>
    38113740                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    38123741                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
    … …  
    38173746                  <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.3</b></a></li>
    38183747                  <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.3</b></a></li>
    3819                   <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>12.1</b></a></li>
     3748                  <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>
    38203749               </ul>
    38213750            </li>
    38223751            <li><a id="rfc.index.K" href="#rfc.index.K"><b>K</b></a><ul>
    3823                   <li><em>Kri2001</em>&nbsp;&nbsp;<a href="#rfc.xref.Kri2001.1">3.2</a>, <a href="#Kri2001"><b>12.2</b></a></li>
     3752                  <li><em>Kri2001</em>&nbsp;&nbsp;<a href="#rfc.xref.Kri2001.1">3.2</a>, <a href="#Kri2001"><b>10.2</b></a></li>
    38243753               </ul>
    38253754            </li>
    … …  
    38273756                  <li>Media Type&nbsp;&nbsp;
    38283757                     <ul>
    3829                         <li>application/http&nbsp;&nbsp;<a href="#rfc.iref.m.5"><b>9.3.2</b></a></li>
    3830                         <li>message/http&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>9.3.1</b></a></li>
     3758                        <li>application/http&nbsp;&nbsp;<a href="#rfc.iref.m.5"><b>7.3.2</b></a></li>
     3759                        <li>message/http&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>7.3.1</b></a></li>
    38313760                     </ul>
    38323761                  </li>
    38333762                  <li>message&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>2.1</b></a></li>
    3834                   <li>message/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>9.3.1</b></a></li>
     3763                  <li>message/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>7.3.1</b></a></li>
    38353764                  <li>method&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>3.1.1</b></a></li>
    38363765               </ul>
    38373766            </li>
    38383767            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul>
    3839                   <li><em>Nie1997</em>&nbsp;&nbsp;<a href="#rfc.xref.Nie1997.1">6.1.1</a>, <a href="#Nie1997"><b>12.2</b></a></li>
     3768                  <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>
    38403769                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.3</b></a></li>
    38413770               </ul>
    … …  
    38483777            </li>
    38493778            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3850                   <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
    3851                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.3</a>, <a href="#rfc.xref.Part2.11">5.6</a>, <a href="#rfc.xref.Part2.12">6.1.2.2</a>, <a href="#rfc.xref.Part2.13">6.1.5</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a>, <a href="#rfc.xref.Part2.17">6.2.3</a>, <a href="#rfc.xref.Part2.18">8.2</a>, <a href="#rfc.xref.Part2.19">10.6</a>, <a href="#rfc.xref.Part2.20">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     3779                  <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>
     3780                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.3</a>, <a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.12">6.3.2.2</a>, <a href="#rfc.xref.Part2.13">6.3.4</a>, <a href="#rfc.xref.Part2.14">6.4.3</a>, <a href="#rfc.xref.Part2.15">6.4.3</a>, <a href="#rfc.xref.Part2.16">6.4.3</a>, <a href="#rfc.xref.Part2.17">6.4.3</a>, <a href="#rfc.xref.Part2.18">6.5</a>, <a href="#rfc.xref.Part2.19">8.6</a>, <a href="#rfc.xref.Part2.20">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    38523781                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1</a></li>
    38533782                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    38543783                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a></li>
    3855                         <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.1.2.2</a>, <a href="#rfc.xref.Part2.13">6.1.5</a></li>
     3784                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.3.2.2</a>, <a href="#rfc.xref.Part2.13">6.3.4</a></li>
    38563785                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">5.3</a></li>
    38573786                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">5.3</a></li>
    3858                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">5.6</a>, <a href="#rfc.xref.Part2.17">6.2.3</a></li>
    3859                         <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.2.3</a></li>
     3787                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.17">6.4.3</a></li>
     3788                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.4.3</a></li>
    38603789                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
    3861                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">8.2</a></li>
    3862                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">10.6</a></li>
    3863                         <li><em>Section 7.4.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.19">10.6</a></li>
     3790                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.5</a></li>
     3791                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">8.6</a></li>
     3792                        <li><em>Section 7.4.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.19">8.6</a></li>
    38643793                        <li><em>Section 10.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
    3865                         <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">6.2.3</a></li>
     3794                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">6.4.3</a>, <a href="#rfc.xref.Part2.16">6.4.3</a></li>
    38663795                     </ul>
    38673796                  </li>
    3868                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3</a>, <a href="#rfc.xref.Part3.4">4.4.1</a>, <a href="#rfc.xref.Part3.5">6.1.3.2</a>, <a href="#Part3"><b>12.1</b></a><ul>
     3797                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3</a>, <a href="#rfc.xref.Part3.4">4.4.1</a>, <a href="#rfc.xref.Part3.5">5.6.2</a>, <a href="#Part3"><b>10.1</b></a><ul>
    38693798                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3</a></li>
    38703799                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">4.4.1</a></li>
    … …  
    38723801                     </ul>
    38733802                  </li>
    3874                   <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">6.1.3.2</a>, <a href="#rfc.xref.Part6.7">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
     3803                  <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">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
    38753804                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
    38763805                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
    3877                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.7">8.1</a></li>
    3878                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.6">6.1.3.2</a></li>
     3806                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a></li>
     3807                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.6">5.6.2</a></li>
    38793808                     </ul>
    38803809                  </li>
    … …  
    38893818                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.1</b></a></li>
    38903819                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.3</b></a></li>
    3891                   <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>12.2</b></a></li>
    3892                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>12.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li>
    3893                   <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>
    3894                   <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
    3895                   <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
    3896                   <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
     3820                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>10.2</b></a></li>
     3821                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li>
     3822                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7.4</a>, <a href="#RFC1950"><b>10.1</b></a></li>
     3823                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.4</a>, <a href="#RFC1951"><b>10.1</b></a></li>
     3824                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">7.4</a>, <a href="#RFC1952"><b>10.1</b></a></li>
     3825                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>10.2</b></a><ul>
    38973826                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">3.3.1</a></li>
    38983827                     </ul>
    38993828                  </li>
    3900                   <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>12.2</b></a></li>
    3901                   <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">6.1.3</a>, <a href="#rfc.xref.RFC2068.4">6.2.3</a>, <a href="#RFC2068"><b>12.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul>
    3902                         <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.1.3</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li>
     3829                  <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>
     3830                  <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">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.4.3</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul>
     3831                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.3.2.1</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li>
    39033832                     </ul>
    39043833                  </li>
    3905                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    3906                   <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">§</a>, <a href="#rfc.xref.RFC2145.2">1</a>, <a href="#RFC2145"><b>12.2</b></a></li>
    3907                   <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">11</a>, <a href="#rfc.xref.RFC2616.5">11</a>, <a href="#RFC2616"><b>12.2</b></a>, <a href="#rfc.xref.RFC2616.6">C.1</a><ul>
    3908                         <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">11</a></li>
     3834                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li>
     3835                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">§</a>, <a href="#rfc.xref.RFC2145.2">1</a>, <a href="#RFC2145"><b>10.2</b></a></li>
     3836                  <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>
     3837                        <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">9</a></li>
    39093838                     </ul>
    39103839                  </li>
    3911                   <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">9.5</a>, <a href="#RFC2817"><b>12.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul>
    3912                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.2">9.5</a></li>
     3840                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">7.5</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul>
     3841                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.2">7.5</a></li>
    39133842                     </ul>
    39143843                  </li>
    3915                   <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>12.2</b></a></li>
    3916                   <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>12.2</b></a></li>
    3917                   <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li>
    3918                   <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li>
    3919                   <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>12.1</b></a><ul>
     3844                  <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>
     3845                  <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>10.2</b></a></li>
     3846                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>10.2</b></a></li>
     3847                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">7.1</a>, <a href="#RFC3864"><b>10.2</b></a></li>
     3848                  <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>
    39203849                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a></li>
    39213850                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
    … …  
    39323861                     </ul>
    39333862                  </li>
    3934                   <li><em>RFC4033</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4033.1">10.4</a>, <a href="#RFC4033"><b>12.2</b></a></li>
    3935                   <li><em>RFC4288</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4288.1">9.3</a>, <a href="#RFC4288"><b>12.2</b></a></li>
    3936                   <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li>
    3937                   <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li>
    3938                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
    3939                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a></li>
     3863                  <li><em>RFC4033</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4033.1">8.4</a>, <a href="#RFC4033"><b>10.2</b></a></li>
     3864                  <li><em>RFC4288</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4288.1">7.3</a>, <a href="#RFC4288"><b>10.2</b></a></li>
     3865                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">7.2</a>, <a href="#RFC4395"><b>10.2</b></a></li>
     3866                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li>
     3867                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">6.5.1</a>, <a href="#RFC5226"><b>10.2</b></a><ul>
     3868                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">6.5.1</a></li>
    39403869                     </ul>
    39413870                  </li>
    3942                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.2.5</a>, <a href="#RFC5234"><b>12.1</b></a><ul>
     3871                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.2.5</a>, <a href="#RFC5234"><b>10.1</b></a><ul>
    39433872                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">1.2</a></li>
    39443873                     </ul>
    39453874                  </li>
    3946                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8.3</a>, <a href="#RFC5322"><b>12.2</b></a><ul>
    3947                         <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">8.3</a></li>
     3875                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">6.2</a>, <a href="#RFC5322"><b>10.2</b></a><ul>
     3876                        <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">6.2</a></li>
    39483877                     </ul>
    39493878                  </li>
    3950                   <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>12.2</b></a></li>
     3879                  <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>
    39513880               </ul>
    39523881            </li>
    … …  
    39543883                  <li>sender&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>2.1</b></a></li>
    39553884                  <li>server&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>2.1</b></a></li>
    3956                   <li><em>Spe</em>&nbsp;&nbsp;<a href="#rfc.xref.Spe.1">6.1.1</a>, <a href="#Spe"><b>12.2</b></a></li>
     3885                  <li><em>Spe</em>&nbsp;&nbsp;<a href="#rfc.xref.Spe.1">6.3.1</a>, <a href="#Spe"><b>10.2</b></a></li>
    39573886                  <li>spider&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>2.1</b></a></li>
    39583887               </ul>
    … …  
    39613890                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.1</b></a></li>
    39623891                  <li>target URI&nbsp;&nbsp;<a href="#rfc.iref.t.8"><b>5.1</b></a></li>
    3963                   <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.t.5"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
    3964                   <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li>
    3965                   <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
    3966                   <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">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
     3892                  <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.t.5"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">7.1</a></li>
     3893                  <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">6.3.1</a>, <a href="#Tou1998"><b>10.2</b></a></li>
     3894                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>
     3895                  <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></li>
    39673896                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
    39683897                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>
    … …  
    39713900            </li>
    39723901            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3973                   <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.2</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
     3902                  <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>
    39743903                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    39753904                  <li>URI scheme&nbsp;&nbsp;
    … …  
    39793908                     </ul>
    39803909                  </li>
    3981                   <li><em>USASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.2</a>, <a href="#USASCII"><b>12.1</b></a></li>
     3910                  <li><em>USASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.2</a>, <a href="#USASCII"><b>10.1</b></a></li>
    39823911                  <li>user agent&nbsp;&nbsp;<a href="#rfc.iref.u.1"><b>2.1</b></a></li>
    39833912               </ul>
    39843913            </li>
    39853914            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3986                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.3</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
     3915                  <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>
    39873916               </ul>
    39883917            </li>
Note: See TracChangeset for help on using the changeset viewer.