Changeset 1583


Ignore:
Timestamp:
Mar 11, 2012, 8:57:38 PM (8 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.

Location:
draft-ietf-httpbis/latest
Files:
2 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>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1582 r1583  
    426426   protocol version (<xref target="request.line"/>),
    427427   followed by MIME-like header fields containing
    428    request modifiers, client information, and payload metadata
     428   request modifiers, client information, and representation metadata
    429429   (<xref target="header.fields"/>),
    430430   an empty line to indicate the end of the header section, and finally
     
    439439   reason phrase (<xref target="status.line"/>),
    440440   possibly followed by MIME-like header fields containing server
    441    information, resource metadata, and payload metadata
     441   information, resource metadata, and representation metadata
    442442   (<xref target="header.fields"/>),
    443443   an empty line to indicate the end of the header section, and finally
     
    23552355<section title="Request Target" anchor="request-target">
    23562356<t>
    2357    Once an inbound connection is obtained (<xref target="connections"/>),
     2357   Once an inbound connection is obtained
     2358   (<xref target="connection.management"/>),
    23582359   the client sends an HTTP request message (<xref target="http.message"/>)
    23592360   with a request-target derived from the target URI.
     
    24092410   if possible, or make the same request on the client's behalf to either
    24102411   the next inbound proxy server or directly to the origin server indicated
    2411    by the request-target.
    2412    In order to avoid request loops, a proxy that forwards requests to other
    2413    proxies &MUST; be able to recognize and exclude all of its own server
    2414    names, including any aliases, local variations, or literal IP addresses.
     2412   by the request-target.  Requirements on such "forwarding" of messages are
     2413   defined in <xref target="intermediary.forwarding"/>.
    24152414</t>
    24162415<t>
     
    24672466</postamble>
    24682467</figure>
    2469 <t>
    2470    If a proxy receives a request-target with a host name that is not a
    2471    fully qualified domain name, it &MAY; add its domain to the host name
    2472    it received when forwarding the request.  A proxy &MUST-NOT; change the
    2473    host name if it is a fully qualified domain name.
    2474 </t>
    2475 <t>
    2476    A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
    2477    parts of the received request-target when forwarding it to the next inbound
    2478    server, except as noted above to replace an empty path with "/" or "*".
    2479 </t>
    24802468</section>
    24812469
     
    26312619</section>
    26322620
     2621<section title="Intermediary Forwarding" anchor="intermediary.forwarding">
     2622<t>
     2623   As described in <xref target="intermediaries"/>, intermediaries can serve
     2624   a variety of roles in the processing of HTTP requests and responses.
     2625   Some intermediaries are used to improve performance or availability.
     2626   Others are used for access control or to filter content.
     2627   Since an HTTP stream has characteristics similar to a pipe-and-filter
     2628   architecture, there are no inherent limits to the extent an intermediary
     2629   can enhance (or interfere) with either direction of the stream.
     2630</t>
     2631<t>
     2632   In order to avoid request loops, a proxy that forwards requests to other
     2633   proxies &MUST; be able to recognize and exclude all of its own server
     2634   names, including any aliases, local variations, or literal IP addresses.
     2635</t>
     2636<t>
     2637   If a proxy receives a request-target with a host name that is not a
     2638   fully qualified domain name, it &MAY; add its domain to the host name
     2639   it received when forwarding the request.  A proxy &MUST-NOT; change the
     2640   host name if it is a fully qualified domain name.
     2641</t>
     2642<t>
     2643   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
     2644   parts of the received request-target when forwarding it to the next inbound
     2645   server, except as noted above to replace an empty path with "/" or "*".
     2646</t>
     2647<t>
     2648   Intermediaries that forward a message &MUST; implement the
     2649   Connection header field as specified in <xref target="header.connection"/>.
     2650</t>
     2651
     2652<section title="End-to-end and Hop-by-hop Header Fields" anchor="end-to-end.and.hop-by-hop.header-fields">
     2653<!--<t>
     2654  <cref anchor="TODO-end-to-end" source="jre">
     2655    Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.1"/>.
     2656    See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
     2657  </cref>
     2658</t>-->
     2659<t>
     2660   For the purpose of defining the behavior of caches and non-caching
     2661   proxies, we divide HTTP header fields into two categories:
     2662  <list style="symbols">
     2663      <t>End-to-end header fields, which are  transmitted to the ultimate
     2664        recipient of a request or response. End-to-end header fields in
     2665        responses &MUST; be stored as part of a cache entry and &MUST; be
     2666        transmitted in any response formed from a cache entry.</t>
     2667
     2668      <t>Hop-by-hop header fields, which are meaningful only for a single
     2669        transport-level connection, and are not stored by caches or
     2670        forwarded by proxies.</t>
     2671  </list>
     2672</t>
     2673<t>
     2674   The following HTTP/1.1 header fields are hop-by-hop header fields:
     2675  <list style="symbols">
     2676      <t>Connection</t>
     2677      <t>Keep-Alive</t>
     2678      <t>Proxy-Authenticate</t>
     2679      <t>Proxy-Authorization</t>
     2680      <t>TE</t>
     2681      <t>Trailer</t>
     2682      <t>Transfer-Encoding</t>
     2683      <t>Upgrade</t>
     2684  </list>
     2685</t>
     2686<t>
     2687   All other header fields defined by HTTP/1.1 are end-to-end header fields.
     2688</t>
     2689<t>
     2690   Other hop-by-hop header fields &MUST; be listed in a Connection header field
     2691   (<xref target="header.connection"/>).
     2692</t>
     2693</section>
     2694
     2695<section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields">
     2696<!--<t>
     2697  <cref anchor="TODO-non-mod-headers" source="jre">
     2698    Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.2"/>.
     2699    See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
     2700  </cref>
     2701</t>-->
     2702<t>
     2703   Some features of HTTP/1.1, such as Digest Authentication, depend on the
     2704   value of certain end-to-end header fields. A non-transforming proxy &SHOULD-NOT;
     2705   modify an end-to-end header field unless the definition of that header field requires
     2706   or specifically allows that.
     2707</t>
     2708<t>
     2709   A non-transforming proxy &MUST-NOT; modify any of the following fields in a
     2710   request or response, and it &MUST-NOT; add any of these fields if not
     2711   already present:
     2712  <list style="symbols">
     2713    <t>Allow</t>
     2714    <t>Content-Location</t>
     2715    <t>Content-MD5</t>
     2716    <t>ETag</t>
     2717    <t>Last-Modified</t>
     2718    <t>Server</t>
     2719  </list>
     2720</t>
     2721<t>
     2722   A non-transforming proxy &MUST-NOT; modify any of the following fields in a
     2723   response:
     2724  <list style="symbols">
     2725    <t>Expires</t>
     2726  </list>
     2727</t>
     2728<t>
     2729   but it &MAY; add any of these fields if not already present. If an
     2730   Expires header field is added, it &MUST; be given a field-value identical to
     2731   that of the Date header field in that response.
     2732</t>
     2733<t>
     2734   A proxy &MUST-NOT; modify or add any of the following fields in a
     2735   message that contains the no-transform cache-control directive, or in
     2736   any request:
     2737  <list style="symbols">
     2738    <t>Content-Encoding</t>
     2739    <t>Content-Range</t>
     2740    <t>Content-Type</t>
     2741  </list>
     2742</t>
     2743<t>
     2744   A transforming proxy &MAY; modify or add these fields to a message
     2745   that does not include no-transform, but if it does so, it &MUST; add a
     2746   Warning 214 (Transformation applied) if one does not already appear
     2747   in the message (see &header-warning;).
     2748</t>
     2749<x:note>
     2750  <t>
     2751    <x:h>Warning:</x:h> Unnecessary modification of end-to-end header fields might
     2752    cause authentication failures if stronger authentication
     2753    mechanisms are introduced in later versions of HTTP. Such
     2754    authentication mechanisms &MAY; rely on the values of header fields
     2755    not listed here.
     2756  </t>
     2757</x:note>
     2758<t>
     2759   A non-transforming proxy &MUST; preserve the message payload (&payload;),
     2760   though it &MAY; change the message body through application or removal
     2761   of a transfer-coding (<xref target="transfer.codings"/>).
     2762</t>
     2763</section>
     2764
     2765</section>
     2766
    26332767<section title="Associating a Response to a Request" anchor="associating.response.to.request">
    26342768<t>
     
    26512785</section>
    26522786
    2653 <section title="Connections" anchor="connections">
     2787<section title="Connection Management" anchor="connection.management">
     2788
     2789<section title="Connection" anchor="header.connection">
     2790  <iref primary="true" item="Connection header field" x:for-anchor=""/>
     2791  <iref primary="true" item="Header Fields" subitem="Connection" x:for-anchor=""/>
     2792  <x:anchor-alias value="Connection"/>
     2793  <x:anchor-alias value="connection-token"/>
     2794<t>
     2795   The "Connection" header field allows the sender to specify
     2796   options that are desired only for that particular connection.
     2797   Such connection options &MUST; be removed or replaced before the
     2798   message can be forwarded downstream by a proxy or gateway.
     2799   This mechanism also allows the sender to indicate which HTTP
     2800   header fields used in the message are only intended for the
     2801   immediate recipient ("hop-by-hop"), as opposed to all recipients
     2802   on the chain ("end-to-end"), enabling the message to be
     2803   self-descriptive and allowing future connection-specific extensions
     2804   to be deployed in HTTP without fear that they will be blindly
     2805   forwarded by previously deployed intermediaries.
     2806</t>
     2807<t>
     2808   The Connection header field's value has the following grammar:
     2809</t>
     2810<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="connection-token"/>
     2811  <x:ref>Connection</x:ref>       = 1#<x:ref>connection-token</x:ref>
     2812  <x:ref>connection-token</x:ref> = <x:ref>token</x:ref>
     2813</artwork></figure>
     2814<t>
     2815   A proxy or gateway &MUST; parse a received Connection
     2816   header field before a message is forwarded and, for each
     2817   connection-token in this field, remove any header field(s) from
     2818   the message with the same name as the connection-token, and then
     2819   remove the Connection header field itself or replace it with the
     2820   sender's own connection options for the forwarded message.
     2821</t>
     2822<t>
     2823   A sender &MUST-NOT; include field-names in the Connection header
     2824   field-value for fields that are defined as expressing constraints
     2825   for all recipients in the request or response chain, such as the
     2826   Cache-Control header field (&header-cache-control;).
     2827</t>
     2828<t>
     2829   The connection options do not have to correspond to a header field
     2830   present in the message, since a connection-specific header field
     2831   might not be needed if there are no parameters associated with that
     2832   connection option.  Recipients that trigger certain connection
     2833   behavior based on the presence of connection options &MUST; do so
     2834   based on the presence of the connection-token rather than only the
     2835   presence of the optional header field.  In other words, if the
     2836   connection option is received as a header field but not indicated
     2837   within the Connection field-value, then the recipient &MUST; ignore
     2838   the connection-specific header field because it has likely been
     2839   forwarded by an intermediary that is only partially conformant.
     2840</t>
     2841<t>
     2842   When defining new connection options, specifications ought to
     2843   carefully consider existing deployed header fields and ensure
     2844   that the new connection-token does not share the same name as
     2845   an unrelated header field that might already be deployed.
     2846   Defining a new connection-token essentially reserves that potential
     2847   field-name for carrying additional information related to the
     2848   connection option, since it would be unwise for senders to use
     2849   that field-name for anything else.
     2850</t>
     2851<t>
     2852   HTTP/1.1 defines the "close" connection option for the sender to
     2853   signal that the connection will be closed after completion of the
     2854   response. For example,
     2855</t>
     2856<figure><artwork type="example">
     2857  Connection: close
     2858</artwork></figure>
     2859<t>
     2860   in either the request or the response header fields indicates that
     2861   the connection &SHOULD-NOT;  be considered "persistent" (<xref target="persistent.connections"/>)
     2862   after the current request/response is complete.
     2863</t>
     2864<t>
     2865   An HTTP/1.1 client that does not support persistent connections &MUST;
     2866   include the "close" connection option in every request message.
     2867</t>
     2868<t>
     2869   An HTTP/1.1 server that does not support persistent connections &MUST;
     2870   include the "close" connection option in every response message that
     2871   does not have a 1xx (Informational) status code.
     2872</t>
     2873</section>
     2874
     2875<section title="Via" anchor="header.via">
     2876  <iref primary="true" item="Via header field" x:for-anchor=""/>
     2877  <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/>
     2878  <x:anchor-alias value="pseudonym"/>
     2879  <x:anchor-alias value="received-by"/>
     2880  <x:anchor-alias value="received-protocol"/>
     2881  <x:anchor-alias value="Via"/>
     2882<t>
     2883   The "Via" header field &MUST; be sent by a proxy or gateway to
     2884   indicate the intermediate protocols and recipients between the user
     2885   agent and the server on requests, and between the origin server and
     2886   the client on responses. It is analogous to the "Received" field
     2887   used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>)
     2888   and is intended to be used for tracking message forwards,
     2889   avoiding request loops, and identifying the protocol capabilities of
     2890   all senders along the request/response chain.
     2891</t>
     2892<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/>
     2893  <x:ref>Via</x:ref>               = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref>
     2894                          [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
     2895  <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
     2896  <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
     2897  <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
     2898</artwork></figure>
     2899<t>
     2900   The received-protocol indicates the protocol version of the message
     2901   received by the server or client along each segment of the
     2902   request/response chain. The received-protocol version is appended to
     2903   the Via field value when the message is forwarded so that information
     2904   about the protocol capabilities of upstream applications remains
     2905   visible to all recipients.
     2906</t>
     2907<t>
     2908   The protocol-name is excluded if and only if it would be "HTTP". The
     2909   received-by field is normally the host and optional port number of a
     2910   recipient server or client that subsequently forwarded the message.
     2911   However, if the real host is considered to be sensitive information,
     2912   it &MAY; be replaced by a pseudonym. If the port is not given, it &MAY;
     2913   be assumed to be the default port of the received-protocol.
     2914</t>
     2915<t>
     2916   Multiple Via field values represent each proxy or gateway that has
     2917   forwarded the message. Each recipient &MUST; append its information
     2918   such that the end result is ordered according to the sequence of
     2919   forwarding applications.
     2920</t>
     2921<t>
     2922   Comments &MAY; be used in the Via header field to identify the software
     2923   of each recipient, analogous to the User-Agent and Server header fields.
     2924   However, all comments in the Via field are optional and &MAY; be removed
     2925   by any recipient prior to forwarding the message.
     2926</t>
     2927<t>
     2928   For example, a request message could be sent from an HTTP/1.0 user
     2929   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
     2930   forward the request to a public proxy at p.example.net, which completes
     2931   the request by forwarding it to the origin server at www.example.com.
     2932   The request received by www.example.com would then have the following
     2933   Via header field:
     2934</t>
     2935<figure><artwork type="example">
     2936  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2937</artwork></figure>
     2938<t>
     2939   A proxy or gateway used as a portal through a network firewall
     2940   &SHOULD-NOT; forward the names and ports of hosts within the firewall
     2941   region unless it is explicitly enabled to do so. If not enabled, the
     2942   received-by host of any host behind the firewall &SHOULD; be replaced
     2943   by an appropriate pseudonym for that host.
     2944</t>
     2945<t>
     2946   For organizations that have strong privacy requirements for hiding
     2947   internal structures, a proxy or gateway &MAY; combine an ordered
     2948   subsequence of Via header field entries with identical received-protocol
     2949   values into a single such entry. For example,
     2950</t>
     2951<figure><artwork type="example">
     2952  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2953</artwork></figure>
     2954<t>
     2955  could be collapsed to
     2956</t>
     2957<figure><artwork type="example">
     2958  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2959</artwork></figure>
     2960<t>
     2961   Senders &SHOULD-NOT; combine multiple entries unless they are all
     2962   under the same organizational control and the hosts have already been
     2963   replaced by pseudonyms. Senders &MUST-NOT; combine entries which
     2964   have different received-protocol values.
     2965</t>
     2966</section>
    26542967
    26552968<section title="Persistent Connections" anchor="persistent.connections">
     
    27513064</t>
    27523065<t>
     3066   Each persistent connection applies to only one transport link.
     3067</t>
     3068<t>
     3069   A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
     3070   with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>
     3071   for information and discussion of the problems with the Keep-Alive header field
     3072   implemented by many HTTP/1.0 clients).
     3073</t>
     3074<t>
    27533075   In order to remain persistent, all messages on the connection &MUST;
    27543076   have a self-defined message length (i.e., one not defined by closure
     
    27823104</t>
    27833105</section>
    2784 </section>
    2785 
    2786 <section title="Proxy Servers" anchor="persistent.proxy">
    2787 <t>
    2788    It is especially important that proxies correctly implement the
    2789    properties of the Connection header field as specified in <xref target="header.connection"/>.
    2790 </t>
    2791 <t>
    2792    The proxy server &MUST; signal persistent connections separately with
    2793    its clients and the origin servers (or other proxy servers) that it
    2794    connects to. Each persistent connection applies to only one transport
    2795    link.
    2796 </t>
    2797 <t>
    2798    A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
    2799    with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>
    2800    for information and discussion of the problems with the Keep-Alive header field
    2801    implemented by many HTTP/1.0 clients).
    2802 </t>
    2803 
    2804 <section title="End-to-end and Hop-by-hop Header Fields" anchor="end-to-end.and.hop-by-hop.header-fields">
    2805 <!--<t>
    2806   <cref anchor="TODO-end-to-end" source="jre">
    2807     Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.1"/>.
    2808     See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
    2809   </cref>
    2810 </t>-->
    2811 <t>
    2812    For the purpose of defining the behavior of caches and non-caching
    2813    proxies, we divide HTTP header fields into two categories:
    2814   <list style="symbols">
    2815       <t>End-to-end header fields, which are  transmitted to the ultimate
    2816         recipient of a request or response. End-to-end header fields in
    2817         responses &MUST; be stored as part of a cache entry and &MUST; be
    2818         transmitted in any response formed from a cache entry.</t>
    2819 
    2820       <t>Hop-by-hop header fields, which are meaningful only for a single
    2821         transport-level connection, and are not stored by caches or
    2822         forwarded by proxies.</t>
    2823   </list>
    2824 </t>
    2825 <t>
    2826    The following HTTP/1.1 header fields are hop-by-hop header fields:
    2827   <list style="symbols">
    2828       <t>Connection</t>
    2829       <t>Keep-Alive</t>
    2830       <t>Proxy-Authenticate</t>
    2831       <t>Proxy-Authorization</t>
    2832       <t>TE</t>
    2833       <t>Trailer</t>
    2834       <t>Transfer-Encoding</t>
    2835       <t>Upgrade</t>
    2836   </list>
    2837 </t>
    2838 <t>
    2839    All other header fields defined by HTTP/1.1 are end-to-end header fields.
    2840 </t>
    2841 <t>
    2842    Other hop-by-hop header fields &MUST; be listed in a Connection header field
    2843    (<xref target="header.connection"/>).
    2844 </t>
    2845 </section>
    2846 
    2847 <section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields">
    2848 <!--<t>
    2849   <cref anchor="TODO-non-mod-headers" source="jre">
    2850     Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.2"/>.
    2851     See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
    2852   </cref>
    2853 </t>-->
    2854 <t>
    2855    Some features of HTTP/1.1, such as Digest Authentication, depend on the
    2856    value of certain end-to-end header fields. A non-transforming proxy &SHOULD-NOT;
    2857    modify an end-to-end header field unless the definition of that header field requires
    2858    or specifically allows that.
    2859 </t>
    2860 <t>
    2861    A non-transforming proxy &MUST-NOT; modify any of the following fields in a
    2862    request or response, and it &MUST-NOT; add any of these fields if not
    2863    already present:
    2864   <list style="symbols">
    2865     <t>Allow</t>
    2866     <t>Content-Location</t>
    2867     <t>Content-MD5</t>
    2868     <t>ETag</t>
    2869     <t>Last-Modified</t>
    2870     <t>Server</t>
    2871   </list>
    2872 </t>
    2873 <t>
    2874    A non-transforming proxy &MUST-NOT; modify any of the following fields in a
    2875    response:
    2876   <list style="symbols">
    2877     <t>Expires</t>
    2878   </list>
    2879 </t>
    2880 <t>
    2881    but it &MAY; add any of these fields if not already present. If an
    2882    Expires header field is added, it &MUST; be given a field-value identical to
    2883    that of the Date header field in that response.
    2884 </t>
    2885 <t>
    2886    A proxy &MUST-NOT; modify or add any of the following fields in a
    2887    message that contains the no-transform cache-control directive, or in
    2888    any request:
    2889   <list style="symbols">
    2890     <t>Content-Encoding</t>
    2891     <t>Content-Range</t>
    2892     <t>Content-Type</t>
    2893   </list>
    2894 </t>
    2895 <t>
    2896    A transforming proxy &MAY; modify or add these fields to a message
    2897    that does not include no-transform, but if it does so, it &MUST; add a
    2898    Warning 214 (Transformation applied) if one does not already appear
    2899    in the message (see &header-warning;).
    2900 </t>
    2901 <x:note>
    2902   <t>
    2903     <x:h>Warning:</x:h> Unnecessary modification of end-to-end header fields might
    2904     cause authentication failures if stronger authentication
    2905     mechanisms are introduced in later versions of HTTP. Such
    2906     authentication mechanisms &MAY; rely on the values of header fields
    2907     not listed here.
    2908   </t>
    2909 </x:note>
    2910 <t>
    2911    A non-transforming proxy &MUST; preserve the message payload (&payload;),
    2912    though it &MAY; change the message body through application or removal
    2913    of a transfer-coding (<xref target="transfer.codings"/>).
    2914 </t>
    2915 </section>
    2916 
    29173106</section>
    29183107
     
    29823171</t>
    29833172</section>
    2984 
    29853173</section>
    29863174
     
    31323320</section>
    31333321
    3134 </section>
    3135 </section>
    3136 
    3137 
    3138 <section title="Miscellaneous notes that might disappear" anchor="misc">
    3139 <section title="Scheme aliases considered harmful" anchor="scheme.aliases">
    3140 <t>
    3141    <cref anchor="TBD-aliases-harmful">describe why aliases like webcal are harmful.</cref>
    3142 </t>
    3143 </section>
    3144 
    3145 <section title="Use of HTTP for proxy communication" anchor="http.proxy">
    3146 <t>
    3147    <cref anchor="TBD-proxy-other">Configured to use HTTP to proxy HTTP or other protocols.</cref>
    3148 </t>
    3149 </section>
    3150 
    3151 <section title="Interception of HTTP for access control" anchor="http.intercept">
    3152 <t>
    3153    <cref anchor="TBD-intercept">Interception of HTTP traffic for initiating access control.</cref>
    3154 </t>
    3155 </section>
    3156 
    3157 <section title="Use of HTTP by other protocols" anchor="http.others">
    3158 <t>
    3159    <cref anchor="TBD-profiles">Profiles of HTTP defined by other protocol.
    3160    Extensions of HTTP like WebDAV.</cref>
    3161 </t>
    3162 
    3163 </section>
    3164 <section title="Use of HTTP by media type specification" anchor="http.media">
    3165 <t>
    3166    <cref anchor="TBD-hypertext">Instructions on composing HTTP requests via hypertext formats.</cref>
    3167 </t>
    3168 </section>
    3169 </section>
    3170 
    3171 <section title="Header Field Definitions" anchor="header.field.definitions">
    3172 <t>
    3173    This section defines the syntax and semantics of HTTP header fields
    3174    related to message origination, framing, and routing.
    3175 </t>
    3176 <texttable align="left">
    3177   <ttcol>Header Field Name</ttcol>
    3178   <ttcol>Defined in...</ttcol>
    3179  
    3180   <c>Connection</c> <c><xref target="header.connection"/></c>
    3181   <c>Content-Length</c> <c><xref target="header.content-length"/></c>
    3182   <c>Host</c> <c><xref target="header.host"/></c>
    3183   <c>TE</c> <c><xref target="header.te"/></c>
    3184   <c>Trailer</c> <c><xref target="header.trailer"/></c>
    3185   <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c>
    3186   <c>Upgrade</c> <c><xref target="header.upgrade"/></c>
    3187   <c>Via</c> <c><xref target="header.via"/></c>
    3188 </texttable>
    3189 
    3190 <section title="Connection" anchor="header.connection">
    3191   <iref primary="true" item="Connection header field" x:for-anchor=""/>
    3192   <iref primary="true" item="Header Fields" subitem="Connection" x:for-anchor=""/>
    3193   <x:anchor-alias value="Connection"/>
    3194   <x:anchor-alias value="connection-token"/>
    3195 <t>
    3196    The "Connection" header field allows the sender to specify
    3197    options that are desired only for that particular connection.
    3198    Such connection options &MUST; be removed or replaced before the
    3199    message can be forwarded downstream by a proxy or gateway.
    3200    This mechanism also allows the sender to indicate which HTTP
    3201    header fields used in the message are only intended for the
    3202    immediate recipient ("hop-by-hop"), as opposed to all recipients
    3203    on the chain ("end-to-end"), enabling the message to be
    3204    self-descriptive and allowing future connection-specific extensions
    3205    to be deployed in HTTP without fear that they will be blindly
    3206    forwarded by previously deployed intermediaries.
    3207 </t>
    3208 <t>
    3209    The Connection header field's value has the following grammar:
    3210 </t>
    3211 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="connection-token"/>
    3212   <x:ref>Connection</x:ref>       = 1#<x:ref>connection-token</x:ref>
    3213   <x:ref>connection-token</x:ref> = <x:ref>token</x:ref>
    3214 </artwork></figure>
    3215 <t>
    3216    A proxy or gateway &MUST; parse a received Connection
    3217    header field before a message is forwarded and, for each
    3218    connection-token in this field, remove any header field(s) from
    3219    the message with the same name as the connection-token, and then
    3220    remove the Connection header field itself or replace it with the
    3221    sender's own connection options for the forwarded message.
    3222 </t>
    3223 <t>
    3224    A sender &MUST-NOT; include field-names in the Connection header
    3225    field-value for fields that are defined as expressing constraints
    3226    for all recipients in the request or response chain, such as the
    3227    Cache-Control header field (&header-cache-control;).
    3228 </t>
    3229 <t>
    3230    The connection options do not have to correspond to a header field
    3231    present in the message, since a connection-specific header field
    3232    might not be needed if there are no parameters associated with that
    3233    connection option.  Recipients that trigger certain connection
    3234    behavior based on the presence of connection options &MUST; do so
    3235    based on the presence of the connection-token rather than only the
    3236    presence of the optional header field.  In other words, if the
    3237    connection option is received as a header field but not indicated
    3238    within the Connection field-value, then the recipient &MUST; ignore
    3239    the connection-specific header field because it has likely been
    3240    forwarded by an intermediary that is only partially conformant.
    3241 </t>
    3242 <t>
    3243    When defining new connection options, specifications ought to
    3244    carefully consider existing deployed header fields and ensure
    3245    that the new connection-token does not share the same name as
    3246    an unrelated header field that might already be deployed.
    3247    Defining a new connection-token essentially reserves that potential
    3248    field-name for carrying additional information related to the
    3249    connection option, since it would be unwise for senders to use
    3250    that field-name for anything else.
    3251 </t>
    3252 <t>
    3253    HTTP/1.1 defines the "close" connection option for the sender to
    3254    signal that the connection will be closed after completion of the
    3255    response. For example,
    3256 </t>
    3257 <figure><artwork type="example">
    3258   Connection: close
    3259 </artwork></figure>
    3260 <t>
    3261    in either the request or the response header fields indicates that
    3262    the connection &SHOULD-NOT;  be considered "persistent" (<xref target="persistent.connections"/>)
    3263    after the current request/response is complete.
    3264 </t>
    3265 <t>
    3266    An HTTP/1.1 client that does not support persistent connections &MUST;
    3267    include the "close" connection option in every request message.
    3268 </t>
    3269 <t>
    3270    An HTTP/1.1 server that does not support persistent connections &MUST;
    3271    include the "close" connection option in every response message that
    3272    does not have a 1xx (Informational) status code.
    3273 </t>
    32743322</section>
    32753323
     
    33803428</t>
    33813429</section>
    3382 
    3383 
    3384 </section>
    3385 
    3386 <section title="Via" anchor="header.via">
    3387   <iref primary="true" item="Via header field" x:for-anchor=""/>
    3388   <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/>
    3389   <x:anchor-alias value="pseudonym"/>
    3390   <x:anchor-alias value="received-by"/>
    3391   <x:anchor-alias value="received-protocol"/>
    3392   <x:anchor-alias value="Via"/>
    3393 <t>
    3394    The "Via" header field &MUST; be sent by a proxy or gateway to
    3395    indicate the intermediate protocols and recipients between the user
    3396    agent and the server on requests, and between the origin server and
    3397    the client on responses. It is analogous to the "Received" field
    3398    used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>)
    3399    and is intended to be used for tracking message forwards,
    3400    avoiding request loops, and identifying the protocol capabilities of
    3401    all senders along the request/response chain.
    3402 </t>
    3403 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/>
    3404   <x:ref>Via</x:ref>               = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref>
    3405                           [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
    3406   <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
    3407   <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
    3408   <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
    3409 </artwork></figure>
    3410 <t>
    3411    The received-protocol indicates the protocol version of the message
    3412    received by the server or client along each segment of the
    3413    request/response chain. The received-protocol version is appended to
    3414    the Via field value when the message is forwarded so that information
    3415    about the protocol capabilities of upstream applications remains
    3416    visible to all recipients.
    3417 </t>
    3418 <t>
    3419    The protocol-name is excluded if and only if it would be "HTTP". The
    3420    received-by field is normally the host and optional port number of a
    3421    recipient server or client that subsequently forwarded the message.
    3422    However, if the real host is considered to be sensitive information,
    3423    it &MAY; be replaced by a pseudonym. If the port is not given, it &MAY;
    3424    be assumed to be the default port of the received-protocol.
    3425 </t>
    3426 <t>
    3427    Multiple Via field values represent each proxy or gateway that has
    3428    forwarded the message. Each recipient &MUST; append its information
    3429    such that the end result is ordered according to the sequence of
    3430    forwarding applications.
    3431 </t>
    3432 <t>
    3433    Comments &MAY; be used in the Via header field to identify the software
    3434    of each recipient, analogous to the User-Agent and Server header fields.
    3435    However, all comments in the Via field are optional and &MAY; be removed
    3436    by any recipient prior to forwarding the message.
    3437 </t>
    3438 <t>
    3439    For example, a request message could be sent from an HTTP/1.0 user
    3440    agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
    3441    forward the request to a public proxy at p.example.net, which completes
    3442    the request by forwarding it to the origin server at www.example.com.
    3443    The request received by www.example.com would then have the following
    3444    Via header field:
    3445 </t>
    3446 <figure><artwork type="example">
    3447   Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    3448 </artwork></figure>
    3449 <t>
    3450    A proxy or gateway used as a portal through a network firewall
    3451    &SHOULD-NOT; forward the names and ports of hosts within the firewall
    3452    region unless it is explicitly enabled to do so. If not enabled, the
    3453    received-by host of any host behind the firewall &SHOULD; be replaced
    3454    by an appropriate pseudonym for that host.
    3455 </t>
    3456 <t>
    3457    For organizations that have strong privacy requirements for hiding
    3458    internal structures, a proxy or gateway &MAY; combine an ordered
    3459    subsequence of Via header field entries with identical received-protocol
    3460    values into a single such entry. For example,
    3461 </t>
    3462 <figure><artwork type="example">
    3463   Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    3464 </artwork></figure>
    3465 <t>
    3466   could be collapsed to
    3467 </t>
    3468 <figure><artwork type="example">
    3469   Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    3470 </artwork></figure>
    3471 <t>
    3472    Senders &SHOULD-NOT; combine multiple entries unless they are all
    3473    under the same organizational control and the hosts have already been
    3474    replaced by pseudonyms. Senders &MUST-NOT; combine entries which
    3475    have different received-protocol values.
    3476 </t>
    34773430</section>
    34783431
     
    50615014<t>
    50625015  Change ABNF productions for header fields to only define the field value.
    5063   (<xref target="header.field.definitions"/>)
    50645016</t>
    50655017<t>
Note: See TracChangeset for help on using the changeset viewer.