Ignore:
Timestamp:
Mar 13, 2011, 10:07:18 PM (9 years ago)
Author:
fielding@…
Message:

modernize the version history notes in the appendix and
remove redundant restated requirements that don't belong
in appendices.

File:
1 edited

Legend:

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

    r1177 r1178  
    395395      <link rel="Chapter" href="#rfc.section.13" title="13 References">
    396396      <link rel="Appendix" title="A Tolerant Applications" href="#rfc.section.A">
    397       <link rel="Appendix" title="B Compatibility with Previous Versions" href="#rfc.section.B">
     397      <link rel="Appendix" title="B HTTP Version History" href="#rfc.section.B">
    398398      <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C">
    399399      <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D">
     
    685685         <li><a href="#rfc.authors">Authors' Addresses</a></li>
    686686         <li>A.&nbsp;&nbsp;&nbsp;<a href="#tolerant.applications">Tolerant Applications</a></li>
    687          <li>B.&nbsp;&nbsp;&nbsp;<a href="#compatibility">Compatibility with Previous Versions</a><ul>
     687         <li>B.&nbsp;&nbsp;&nbsp;<a href="#compatibility">HTTP Version History</a><ul>
    688688               <li>B.1&nbsp;&nbsp;&nbsp;<a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul>
    689                      <li>B.1.1&nbsp;&nbsp;&nbsp;<a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></li>
     689                     <li>B.1.1&nbsp;&nbsp;&nbsp;<a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></li>
     690                     <li>B.1.2&nbsp;&nbsp;&nbsp;<a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li>
    690691                  </ul>
    691692               </li>
    692                <li>B.2&nbsp;&nbsp;&nbsp;<a href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Persistent Connections</a></li>
    693                <li>B.3&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
     693               <li>B.2&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
    694694            </ul>
    695695         </li>
     
    11951195         stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF.
    11961196      </p>
    1197       <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations generate an extra CRLF after a POST request as a lame workaround for some early server
     1197      <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations send an extra CRLF after a POST request as a lame workaround for some early server
    11981198         applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then
    11991199         the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length.
     
    14831483         field.
    14841484      </p>
    1485       <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix&nbsp;B.1.1</a> for other requirements on Host support in HTTP/1.1.)
     1485      <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix&nbsp;B.1.1</a> for other requirements on Host support in HTTP/1.1.)
    14861486      </p>
    14871487      <p id="rfc.section.4.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or
     
    18661866         for the connection.
    18671867      </p>
    1868       <p id="rfc.section.7.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="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a> for more information on backward compatibility with HTTP/1.0 clients.
     1868      <p id="rfc.section.7.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;B.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    18691869      </p>
    18701870      <p id="rfc.section.7.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>.
     
    22122212         message that contains more than one Host header field or a Host header field with an invalid field-value.
    22132213      </p>
    2214       <p id="rfc.section.9.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.
     2214      <p id="rfc.section.9.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">B.1.1</a> for other requirements relating to Host.
    22152215      </p>
    22162216      <div id="rfc.iref.t.5"></div>
     
    30013001         </li>
    30023002      </ul>
    3003       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
     3003      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="compatibility" href="#compatibility">HTTP Version History</a></h1>
    30043004      <p id="rfc.section.B.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred
    30053005         to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single request method (GET)
     
    30153015      </p>
    30163016      <p id="rfc.section.B.p.3">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately
    3017          designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification,
    3018          we would expect general-purpose HTTP/1.1 servers to:
    3019       </p>
    3020       <ul>
    3021          <li>understand any valid request in the format of HTTP/1.0 and 1.1;</li>
    3022          <li>respond appropriately with a message in the same major version used by the client.</li>
    3023       </ul>
    3024       <p id="rfc.section.B.p.4">And we would expect HTTP/1.1 clients to: </p>
    3025       <ul>
    3026          <li>understand any valid response in the format of HTTP/1.0 or 1.1.</li>
    3027       </ul>
    3028       <p id="rfc.section.B.p.5">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the
    3029          server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described
    3030          in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     3017         designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand
     3018         any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood
     3019         (or safely ignored) by HTTP/1.0 clients. Likewise, would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response.
     3020      </p>
     3021      <p id="rfc.section.B.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts
     3022         (selection of resource by inspection of the Host header field). Any server that implements name-based virtual hosts ought
     3023         to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests
     3024         wherein a buggy client failed to properly encode linear whitespace found in a URI reference and placed in the request-target.
    30313025      </p>
    30323026      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
    30333027      <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    3034       <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.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">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3>
    3035       <p id="rfc.section.B.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;9.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;4.1.2</a>) are among the most important changes defined by this specification.
     3028      <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.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>
     3029      <p id="rfc.section.B.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;9.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;4.1.2</a>) are among the most important changes defined by HTTP/1.1.
    30363030      </p>
    30373031      <p id="rfc.section.B.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
    3038          for distinguishing the intended server of a request than the IP address to which that request was directed. The changes outlined
    3039          above will allow the Internet, once older HTTP clients are no longer common, to support multiple Web sites from a single IP
    3040          address, greatly simplifying large operational Web servers, where allocation of many IP addresses to a single host has created
    3041          serious problems. The Internet will also be able to recover the IP addresses that have been allocated for the sole purpose
    3042          of allowing special-purpose domain names to be used. Given the rate of growth of the Web, and the number of servers already
    3043          deployed, it is extremely important that all implementations of HTTP (including updates to existing HTTP/1.0 applications)
    3044          correctly implement these requirements:
    3045       </p>
    3046       <ul>
    3047          <li>Both clients and servers <em class="bcp14">MUST</em> support the Host header field.
    3048          </li>
    3049          <li>A client that sends an HTTP/1.1 request <em class="bcp14">MUST</em> send a Host header field.
    3050          </li>
    3051          <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host header field.
    3052          </li>
    3053          <li>Servers <em class="bcp14">MUST</em> accept absolute URIs.
    3054          </li>
    3055       </ul>
    3056       <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;<a id="compatibility.with.http.1.0.persistent.connections" href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Persistent Connections</a></h2>
    3057       <p id="rfc.section.B.2.p.1">Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.0
     3032         for distinguishing the intended server of a request than the IP address to which that request was directed. The Host header
     3033         field was introduced during the development of HTTP/1.1 and, though it was quickly implemented by most HTTP/1.0 browsers,
     3034         additional requirements were placed on all HTTP/1.1 requests in order to ensure complete adoption. At the time of this writing,
     3035         most HTTP-based services are dependent upon the Host header field for targeting requests.
     3036      </p>
     3037      <h3 id="rfc.section.B.1.2"><a href="#rfc.section.B.1.2">B.1.2</a>&nbsp;<a id="compatibility.with.http.1.0.persistent.connections" href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></h3>
     3038      <p id="rfc.section.B.1.2.p.1">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the
     3039         server after sending the response. However, some implementations implement the Keep-Alive version of persistent connections
     3040         described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     3041      </p>
     3042      <p id="rfc.section.B.1.2.p.2">Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.0
    30583043         clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0
    30593044         experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify
     
    30633048         from using Keep-Alive when talking to proxies.
    30643049      </p>
    3065       <p id="rfc.section.B.2.p.2">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable.
     3050      <p id="rfc.section.B.1.2.p.3">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable.
    30663051         Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when
    30673052         talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce
    30683053         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;9.1</a>.
    30693054      </p>
    3070       <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header field) is documented
    3071          in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    3072       </p>
    3073       <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    3074       <p id="rfc.section.B.3.p.1">Empty list elements in list productions have been deprecated. (<a href="#notation.abnf" title="ABNF Extension: #rule">Section&nbsp;1.2.1</a>)
    3075       </p>
    3076       <p id="rfc.section.B.3.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically
     3055      <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
     3056      <p id="rfc.section.B.2.p.1">Empty list elements in list productions have been deprecated. (<a href="#notation.abnf" title="ABNF Extension: #rule">Section&nbsp;1.2.1</a>)
     3057      </p>
     3058      <p id="rfc.section.B.2.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically
    30773059         pointed out in the ABNF. The NUL octet is no longer allowed in comment and quoted-string text. The quoted-pair rule no longer
    30783060         allows escaping control characters other than HTAB. Non-ASCII content in header fields and reason phrase has been obsoleted
    30793061         and made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>)
    30803062      </p>
    3081       <p id="rfc.section.B.3.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a>)
    3082       </p>
    3083       <p id="rfc.section.B.3.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
    3084       </p>
    3085       <p id="rfc.section.B.3.p.5">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
    3086       </p>
    3087       <p id="rfc.section.B.3.p.6">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">6.2</a>)
    3088       </p>
    3089       <p id="rfc.section.B.3.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
     3063      <p id="rfc.section.B.2.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.5</a>)
     3064      </p>
     3065      <p id="rfc.section.B.2.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
     3066      </p>
     3067      <p id="rfc.section.B.2.p.5">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
     3068      </p>
     3069      <p id="rfc.section.B.2.p.6">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">6.2</a>)
     3070      </p>
     3071      <p id="rfc.section.B.2.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
    30903072         form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>)
    30913073      </p>
    3092       <p id="rfc.section.B.3.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore
     3074      <p id="rfc.section.B.2.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore
    30933075         disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>)
    30943076      </p>
    3095       <p id="rfc.section.B.3.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;7.1.4</a>)
    3096       </p>
    3097       <p id="rfc.section.B.3.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;9.1</a>)
    3098       </p>
    3099       <p id="rfc.section.B.3.p.11">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;9.8</a>)
     3077      <p id="rfc.section.B.2.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;7.1.4</a>)
     3078      </p>
     3079      <p id="rfc.section.B.2.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;9.1</a>)
     3080      </p>
     3081      <p id="rfc.section.B.2.p.11">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;9.8</a>)
    31003082      </p>
    31013083      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
     
    36363618                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">6.2.2.1</a></li>
    36373619                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3638                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.2</a>, <a href="#rfc.xref.header.connection.11">B.3</a></li>
     3620                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.1.2</a>, <a href="#rfc.xref.header.connection.11">B.2</a></li>
    36393621                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>
    36403622               </ul>
     
    37793761                  <li>Header Fields&nbsp;&nbsp;
    37803762                     <ul>
    3781                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.2</a>, <a href="#rfc.xref.header.connection.11">B.3</a></li>
     3763                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.1.2</a>, <a href="#rfc.xref.header.connection.11">B.2</a></li>
    37823764                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li>
    37833765                        <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li>
     
    37863768                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">3.4</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>
    37873769                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>
    3788                         <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.3</a></li>
     3770                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li>
    37893771                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">3.4</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>
    37903772                     </ul>
     
    38793861                  </li>
    38803862                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li>
    3881                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">2.5</a>, <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.3">7.2.3</a>, <a href="#rfc.xref.RFC2068.4">12</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">B</a>, <a href="#rfc.xref.RFC2068.9">B.2</a><ul>
    3882                         <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B</a>, <a href="#rfc.xref.RFC2068.9">B.2</a></li>
     3863                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">2.5</a>, <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.3">7.2.3</a>, <a href="#rfc.xref.RFC2068.4">12</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a><ul>
     3864                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a></li>
    38833865                     </ul>
    38843866                  </li>
     
    38863868                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">1</a>, <a href="#RFC2145"><b>13.2</b></a></li>
    38873869                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.5</a>, <a href="#rfc.xref.RFC2616.3">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.4">D.1</a></li>
    3888                   <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">B.3</a><ul>
     3870                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">B.2</a><ul>
    38893871                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.5</a></li>
    38903872                     </ul>
     
    39453927            </li>
    39463928            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3947                   <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.3</a></li>
     3929                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li>
    39483930                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    39493931                  <li>URI scheme&nbsp;&nbsp;
Note: See TracChangeset for help on using the changeset viewer.