Ignore:
Timestamp:
11/11/08 01:31:37 (14 years ago)
Author:
fielding@…
Message:

generate HTML

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r337 r342  
    365365      <link rel="Index" href="#rfc.index">
    366366      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    367       <link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2">
     367      <link rel="Chapter" title="2 When to use HTTP" href="#rfc.section.2">
    368368      <link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3">
    369369      <link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4">
    … …  
    516516      <ul class="toc">
    517517         <li class="tocline0">1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul class="toc">
    518                <li class="tocline1">1.1&nbsp;&nbsp;&nbsp;<a href="#intro.purpose">Purpose</a></li>
    519                <li class="tocline1">1.2&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
    520                <li class="tocline1">1.3&nbsp;&nbsp;&nbsp;<a href="#intro.overall.operation">Overall Operation</a></li>
    521             </ul>
    522          </li>
    523          <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#notation">Notational Conventions and Generic Grammar</a><ul class="toc">
    524                <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#notation.abnf">Augmented BNF</a><ul class="toc">
    525                      <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.1.1">#rule</a></li>
    526                      <li class="tocline1">2.1.2&nbsp;&nbsp;&nbsp;<a href="#implied.LWS">implied *LWS</a></li>
     518               <li class="tocline1">1.1&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     519               <li class="tocline1">1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul class="toc">
     520                     <li class="tocline1">1.2.1&nbsp;&nbsp;&nbsp;<a href="#notation.abnf">Augmented BNF</a><ul class="toc">
     521                           <li class="tocline1">1.2.1.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.2.1.1">#rule</a></li>
     522                           <li class="tocline1">1.2.1.2&nbsp;&nbsp;&nbsp;<a href="#implied.LWS">implied *LWS</a></li>
     523                        </ul>
     524                     </li>
     525                     <li class="tocline1">1.2.2&nbsp;&nbsp;&nbsp;<a href="#basic.rules">Basic Rules</a></li>
     526                     <li class="tocline1">1.2.3&nbsp;&nbsp;&nbsp;<a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>
    527527                  </ul>
    528528               </li>
    529                <li class="tocline1">2.2&nbsp;&nbsp;&nbsp;<a href="#basic.rules">Basic Rules</a></li>
    530                <li class="tocline1">2.3&nbsp;&nbsp;&nbsp;<a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>
     529            </ul>
     530         </li>
     531         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#when">When to use HTTP</a><ul class="toc">
     532               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul class="toc">
     533                     <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
     534                     <li class="tocline1">2.1.2&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">URI Comparison</a></li>
     535                  </ul>
     536               </li>
     537               <li class="tocline1">2.2&nbsp;&nbsp;&nbsp;<a href="#intro.overall.operation">Overall Operation</a></li>
    531538            </ul>
    532539         </li>
    533540         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#protocol.parameters">Protocol Parameters</a><ul class="toc">
    534541               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#http.version">HTTP Version</a></li>
    535                <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul class="toc">
    536                      <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#general.syntax">General Syntax</a></li>
    537                      <li class="tocline1">3.2.2&nbsp;&nbsp;&nbsp;<a href="#http.url">http URL</a></li>
    538                      <li class="tocline1">3.2.3&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">URI Comparison</a></li>
     542               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#date.time.formats">Date/Time Formats</a><ul class="toc">
     543                     <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#full.date">Full Date</a></li>
    539544                  </ul>
    540545               </li>
    541                <li class="tocline1">3.3&nbsp;&nbsp;&nbsp;<a href="#date.time.formats">Date/Time Formats</a><ul class="toc">
    542                      <li class="tocline1">3.3.1&nbsp;&nbsp;&nbsp;<a href="#full.date">Full Date</a></li>
     546               <li class="tocline1">3.3&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul class="toc">
     547                     <li class="tocline1">3.3.1&nbsp;&nbsp;&nbsp;<a href="#chunked.transfer.encoding">Chunked Transfer Coding</a></li>
    543548                  </ul>
    544549               </li>
    545                <li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul class="toc">
    546                      <li class="tocline1">3.4.1&nbsp;&nbsp;&nbsp;<a href="#chunked.transfer.encoding">Chunked Transfer Coding</a></li>
    547                   </ul>
    548                </li>
    549                <li class="tocline1">3.5&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
     550               <li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
    550551            </ul>
    551552         </li>
    … …  
    662663      </ul>
    663664      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    664       <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information
    665          systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, commonly
    666          referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet with only a single method and no
    667          metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metadata about the data
    668          transferred and modifiers on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration
    669          the effects of hierarchical proxies, caching, the need for persistent connections, or name-based virtual hosts. In addition,
    670          the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" necessitated a protocol version change
    671          in order for two communicating applications to determine each other's true capabilities.
    672       </p>
    673       <p id="rfc.section.1.p.2">This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1", obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations
    674          and adding only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating
    675          with a party advertising compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1 related to overall network operation,
    676          message framing, interaction with transport protocols, and URI schemes.
    677       </p>
    678       <p id="rfc.section.1.p.3">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    679          errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections will
    680          be organized according to the typical process of deciding when to use HTTP (URI schemes), overall network operation, connection
    681          management, message framing, and generic message parsing. The current mess reflects how widely dispersed these topics and
    682          associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    683       </p>
    684       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.purpose" href="#intro.purpose">Purpose</a></h2>
    685       <p id="rfc.section.1.1.p.1">Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation.
    686          HTTP allows an open-ended set of methods and headers that indicate the purpose of a request <a href="#RFC2324" id="rfc.xref.RFC2324.1"><cite title="Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)">[RFC2324]</cite></a>. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) <a href="#RFC1630" id="rfc.xref.RFC1630.1"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</cite></a>, as a location (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.1"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> or name (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.1"><cite title="Functional Requirements for Uniform Resource Names">[RFC1737]</cite></a>, for indicating the resource to which a method is to be applied. Messages are passed in a format similar to that used by
    687          Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> as defined by the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>.
    688       </p>
    689       <p id="rfc.section.1.1.p.2">HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems,
    690          including those supported by the SMTP <a href="#RFC2821" id="rfc.xref.RFC2821.1"><cite title="Simple Mail Transfer Protocol">[RFC2821]</cite></a>, NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.
    691       </p>
    692       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
    693       <p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     665      <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and
     666         MIME-like message payloads for flexible interaction with network-based hypermedia information systems. HTTP relies upon the
     667         Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate resource targets for interaction and to identify other resources. Messages are passed in a format similar to that
     668         used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
     669      </p>
     670      <p id="rfc.section.1.p.2">HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems,
     671         such as USENET news services via NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, file services via FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a>. HTTP proxies and gateways provide access to alternative information services by translating their diverse protocols into
     672         a hypermedia format that can be viewed and manipulated by clients in the same way as HTTP services.
     673      </p>
     674      <p id="rfc.section.1.p.3">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 defines how clients determine when to use HTTP, the URI schemes specific to HTTP-based resources, overall network
     675         operation with transport protocol connection management, and HTTP message framing. Our goal is to define all of the mechanisms
     676         necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements
     677         for an HTTP message relay or generic message parser.
     678      </p>
     679      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     680      <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    694681         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    695682      </p>
    696       <p id="rfc.section.1.2.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant."
    697       </p>
    698       <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2>
    699       <p id="rfc.section.1.3.p.1">HTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol
    700          version, followed by a MIME-like message containing request modifiers, client information, and possible body content over
    701          a connection with a server. The server responds with a status line, including the message's protocol version and a success
    702          or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body
    703          content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    704       </p>
    705       <p id="rfc.section.1.3.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin
    706          server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin
    707          server (O).
    708       </p>
    709       <div id="rfc.figure.u.1"></div><pre class="drawing">       request chain ------------------------&gt;
    710     UA -------------------v------------------- O
    711        &lt;----------------------- response chain
    712 </pre><p id="rfc.section.1.3.p.4">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three
    713          common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its
    714          absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by
    715          the URI. A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests
    716          to the underlying server's protocol. A tunnel acts as a relay point between two connections without changing the messages;
    717          tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary
    718          cannot understand the contents of the messages.
    719       </p>
    720       <div id="rfc.figure.u.2"></div><pre class="drawing">       request chain --------------------------------------&gt;
    721     UA -----v----- A -----v----- B -----v----- C -----v----- O
    722        &lt;------------------------------------- response chain
    723 </pre><p id="rfc.section.1.3.p.6">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
    724          message that travels the whole chain will pass through four separate connections. This distinction is important because some
    725          HTTP communication options may apply only to the connection with the nearest, non-tunnel neighbor, only to the end-points
    726          of the chain, or to all connections along the chain. Although the diagram is linear, each participant may be engaged in multiple,
    727          simultaneous communications. For example, B may be receiving requests from many clients other than A, and/or forwarding requests
    728          to servers other than C, at the same time that it is handling A's request.
    729       </p>
    730       <p id="rfc.section.1.3.p.7">Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect
    731          of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response
    732          applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from
    733          O (via C) for a request which has not been cached by UA or A.
    734       </p>
    735       <div id="rfc.figure.u.3"></div><pre class="drawing">          request chain ----------&gt;
    736        UA -----v----- A -----v----- B - - - - - - C - - - - - - O
    737           &lt;--------- response chain
    738 </pre><p id="rfc.section.1.3.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache
    739          behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching" title="Introduction">Section 1</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    740       </p>
    741       <p id="rfc.section.1.3.p.10">In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with
    742          or deployed across the World Wide Web. These systems include national hierarchies of proxy caches to save transoceanic bandwidth,
    743          systems that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so
    744          on. HTTP systems are used in corporate intranets over high-bandwidth links, and for access via PDAs with low-power radio links
    745          and intermittent connectivity. The goal of HTTP/1.1 is to support the wide diversity of configurations already deployed while
    746          introducing protocol constructs that meet the needs of those who build web applications that require high reliability and,
    747          failing that, at least reliable indications of failure.
    748       </p>
    749       <p id="rfc.section.1.3.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (&lt;<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>&gt;), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,
    750          or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the
    751          mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside
    752          the scope of this specification.
    753       </p>
    754       <p id="rfc.section.1.3.p.12">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may
    755          be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>).
    756       </p>
    757       <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1>
    758       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h2>
    759       <p id="rfc.section.2.1.p.1">All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (ABNF) based
    760          on that defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The extensions to ABNF
    761          used in this specification are described below.
    762       </p>
    763       <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;#rule
    764       </h3>
    765       <p id="rfc.section.2.1.1.p.1">A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at
    766          least &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas (",") and <em class="bcp14">OPTIONAL</em> linear white space (LWS). This makes the usual form of lists very easy; a rule such as
    767       </p>
    768       <div id="rfc.figure.u.4"></div><pre class="text"> ( *<a href="#rule.LWS" class="smpl">LWS</a> element *( *<a href="#rule.LWS" class="smpl">LWS</a> "," *<a href="#rule.LWS" class="smpl">LWS</a> element ))</pre><p id="rfc.section.2.1.1.p.2">can be shown as </p>
    769       <div id="rfc.figure.u.5"></div><pre class="text"> 1#element</pre><p id="rfc.section.2.1.1.p.3">Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is,
    770          "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required,
    771          at least one non-null element <em class="bcp14">MUST</em> be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at
    772          least one; and "1#2element" allows one or two.
    773       </p>
    774       <div id="rfc.iref.i.1"></div>
    775       <h3 id="rfc.section.2.1.2"><a href="#rfc.section.2.1.2">2.1.2</a>&nbsp;<a id="implied.LWS" href="#implied.LWS">implied *LWS</a></h3>
    776       <p id="rfc.section.2.1.2.p.1">The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included
    777          between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation
    778          of a field. At least one delimiter (LWS and/or separators) <em class="bcp14">MUST</em> exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single
    779          token.
    780       </p>
    781       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="basic.rules" href="#basic.rules">Basic Rules</a></h2>
     683      <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant."
     684      </p>
     685      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     686      <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, including its core ABNF syntax rules: ALPHA (letters), CR (carriage return), DIGIT (decimal digits), DQUOTE (double quote),
     687         HEXDIG (hexadecimal digits), LF (line feed), and SP (space).
     688      </p>
    782689      <div id="core.rules">
    783          <p id="rfc.section.2.2.p.1">                    The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character
     690         <p id="rfc.section.1.2.p.2">                    The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character
    784691            set is defined by ANSI X3.4-1986 <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>.
    785692         </p>
    786693      </div>
    787       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#core.rules" class="smpl">OCTET</a>          = %x00-FF
     694      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#core.rules" class="smpl">OCTET</a>          = %x00-FF
    788695                   ; any 8-bit sequence of data
    789696  <a href="#core.rules" class="smpl">CHAR</a>           = %x01-7F
    … …  
    805712  <a href="#core.rules" class="smpl">DQUOTE</a>         = %x22
    806713                   ; US-ASCII double-quote mark (34)
    807 </pre><div id="rule.CRLF">
    808          <p id="rfc.section.2.2.p.3">  HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described
     714</pre><h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;<a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h3>
     715      <p id="rfc.section.1.2.1.p.1">All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (ABNF) based
     716         on that defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The extensions to ABNF
     717         used in this specification are described below.
     718      </p>
     719      <h4 id="rfc.section.1.2.1.1"><a href="#rfc.section.1.2.1.1">1.2.1.1</a>&nbsp;#rule
     720      </h4>
     721      <p id="rfc.section.1.2.1.1.p.1">A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at
     722         least &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas (",") and <em class="bcp14">OPTIONAL</em> linear white space (LWS). This makes the usual form of lists very easy; a rule such as
     723      </p>
     724      <div id="rfc.figure.u.2"></div><pre class="text"> ( *<a href="#rule.LWS" class="smpl">LWS</a> element *( *<a href="#rule.LWS" class="smpl">LWS</a> "," *<a href="#rule.LWS" class="smpl">LWS</a> element ))</pre><p id="rfc.section.1.2.1.1.p.2">can be shown as </p>
     725      <div id="rfc.figure.u.3"></div><pre class="text"> 1#element</pre><p id="rfc.section.1.2.1.1.p.3">Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is,
     726         "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required,
     727         at least one non-null element <em class="bcp14">MUST</em> be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at
     728         least one; and "1#2element" allows one or two.
     729      </p>
     730      <div id="rfc.iref.i.1"></div>
     731      <h4 id="rfc.section.1.2.1.2"><a href="#rfc.section.1.2.1.2">1.2.1.2</a>&nbsp;<a id="implied.LWS" href="#implied.LWS">implied *LWS</a></h4>
     732      <p id="rfc.section.1.2.1.2.p.1">The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included
     733         between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation
     734         of a field. At least one delimiter (LWS and/or separators) <em class="bcp14">MUST</em> exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single
     735         token.
     736      </p>
     737      <h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a>&nbsp;<a id="basic.rules" href="#basic.rules">Basic Rules</a></h3>
     738      <div id="rule.CRLF">
     739         <p id="rfc.section.1.2.2.p.1">  HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described
    809740            in <a href="p3-payload.html#media.types" title="Media Types">Section 3.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    810741         </p>
    811742      </div>
    812       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.11"></span>  <a href="#rule.CRLF" class="smpl">CRLF</a>           = <a href="#core.rules" class="smpl">CR</a> LF
     743      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.11"></span>  <a href="#rule.CRLF" class="smpl">CRLF</a>           = <a href="#core.rules" class="smpl">CR</a> LF
    813744</pre><div id="rule.LWS">
    814          <p id="rfc.section.2.2.p.5">  HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal
     745         <p id="rfc.section.1.2.2.p.3">  HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal
    815746            tab. All linear white space, including folding, has the same semantics as SP. A recipient <em class="bcp14">MAY</em> replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
    816747         </p>
    817748      </div>
    818       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.12"></span>  <a href="#rule.LWS" class="smpl">LWS</a>            = [<a href="#rule.CRLF" class="smpl">CRLF</a>] 1*( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
     749      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.12"></span>  <a href="#rule.LWS" class="smpl">LWS</a>            = [<a href="#rule.CRLF" class="smpl">CRLF</a>] 1*( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
    819750</pre><div id="rule.TEXT">
    820          <p id="rfc.section.2.2.p.7">  The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message
     751         <p id="rfc.section.1.2.2.p.5">  The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message
    821752            parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> only when encoded according to the rules of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
    822753         </p>
    823754      </div>
    824       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.13"></span>  <a href="#rule.TEXT" class="smpl">TEXT</a>           = %x20-7E / %x80-FF / <a href="#rule.LWS" class="smpl">LWS</a>
     755      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.13"></span>  <a href="#rule.TEXT" class="smpl">TEXT</a>           = %x20-7E / %x80-FF / <a href="#rule.LWS" class="smpl">LWS</a>
    825756                 ; any <a href="#core.rules" class="smpl">OCTET</a> except <a href="#core.rules" class="smpl">CTL</a>s, but including <a href="#rule.LWS" class="smpl">LWS</a>
    826 </pre><p id="rfc.section.2.2.p.9">A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS
     757</pre><p id="rfc.section.1.2.2.p.7">A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS
    827758         will be replaced with a single SP before interpretation of the TEXT value.
    828759      </p>
    829760      <div id="rule.HEXDIG">
    830          <p id="rfc.section.2.2.p.10">  Hexadecimal numeric characters are used in several protocol elements.</p>
     761         <p id="rfc.section.1.2.2.p.8">  Hexadecimal numeric characters are used in several protocol elements.</p>
    831762      </div>
    832       <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.14"></span>  <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>         = "A" / "B" / "C" / "D" / "E" / "F"
     763      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.14"></span>  <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>         = "A" / "B" / "C" / "D" / "E" / "F"
    833764                 / "a" / "b" / "c" / "d" / "e" / "f" / <a href="#core.rules" class="smpl">DIGIT</a>
    834765</pre><div id="rule.token.separators">
    835          <p id="rfc.section.2.2.p.12">      Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>).
     766         <p id="rfc.section.1.2.2.p.10">      Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>).
    836767         </p>
    837768      </div>
    838       <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#rule.token.separators" class="smpl">separators</a>     = "(" / ")" / "&lt;" / "&gt;" / "@"
     769      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#rule.token.separators" class="smpl">separators</a>     = "(" / ")" / "&lt;" / "&gt;" / "@"
    839770                 / "," / ";" / ":" / "\" / <a href="#core.rules" class="smpl">DQUOTE</a>
    840771                 / "/" / "[" / "]" / "?" / "="
    … …  
    848779  <a href="#rule.token.separators" class="smpl">token</a>          = 1*<a href="#rule.token.separators" class="smpl">tchar</a>
    849780</pre><div id="rule.comment">
    850          <p id="rfc.section.2.2.p.14">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
     781         <p id="rfc.section.1.2.2.p.12">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
    851782            in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part
    852783            of the field value.
    853784         </p>
    854785      </div>
    855       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
     786      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
    856787  <a href="#rule.comment" class="smpl">ctext</a>          = &lt;any <a href="#rule.TEXT" class="smpl">TEXT</a> excluding "(" and ")"&gt;
    857788</pre><div id="rule.quoted-string">
    858          <p id="rfc.section.2.2.p.16">    A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
     789         <p id="rfc.section.1.2.2.p.14">    A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
    859790      </div>
    860       <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#rule.quoted-string" class="smpl">quoted-string</a>  = ( <a href="#core.rules" class="smpl">DQUOTE</a> *(<a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> )
     791      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#rule.quoted-string" class="smpl">quoted-string</a>  = ( <a href="#core.rules" class="smpl">DQUOTE</a> *(<a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> )
    861792  <a href="#rule.quoted-string" class="smpl">qdtext</a>         = &lt;any <a href="#rule.TEXT" class="smpl">TEXT</a> excluding <a href="#core.rules" class="smpl">DQUOTE</a> and "\"&gt;
    862793</pre><div id="rule.quoted-pair">
    863          <p id="rfc.section.2.2.p.18">    The backslash character ("\") <em class="bcp14">MAY</em> be used as a single-character quoting mechanism only within quoted-string and comment constructs.
     794         <p id="rfc.section.1.2.2.p.16">    The backslash character ("\") <em class="bcp14">MAY</em> be used as a single-character quoting mechanism only within quoted-string and comment constructs.
    864795         </p>
    865796      </div>
    866       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-text</a>    = %x01-09 /
     797      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-text</a>    = %x01-09 /
    867798                   %x0B-0C /
    868799                   %x0E-FF ; Characters excluding NUL, <a href="#core.rules" class="smpl">CR</a> and <a href="#core.rules" class="smpl">LF</a>
    869800  <a href="#rule.quoted-pair" class="smpl">quoted-pair</a>    = "\" <a href="#rule.quoted-pair" class="smpl">quoted-text</a>
    870 </pre><h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h2>
    871       <p id="rfc.section.2.3.p.1">The ABNF rules below are defined in other parts:</p>
    872       <div id="rfc.figure.u.15"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">request-header</a>  = &lt;request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>&gt;
     801</pre><h3 id="rfc.section.1.2.3"><a href="#rfc.section.1.2.3">1.2.3</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
     802      <p id="rfc.section.1.2.3.p.1">The ABNF rules below are defined in other parts:</p>
     803      <div id="rfc.figure.u.12"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">request-header</a>  = &lt;request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>&gt;
    873804  <a href="#abnf.dependencies" class="smpl">response-header</a> = &lt;response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a>&gt;
    874 </pre><div id="rfc.figure.u.16"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">accept-params</a>   = &lt;accept-params, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>&gt;
     805</pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">accept-params</a>   = &lt;accept-params, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>&gt;
    875806  <a href="#abnf.dependencies" class="smpl">entity-body</a>     = &lt;entity-body, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.body" title="Entity Body">Section 4.2</a>&gt;
    876807  <a href="#abnf.dependencies" class="smpl">entity-header</a>   = &lt;entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>&gt;
    877 </pre><div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Cache-Control</a>   = &lt;Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>&gt;
    878   <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>&gt;
    879   <a href="#abnf.dependencies" class="smpl">Warning</a>         = &lt;Warning, defined in <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>&gt;
    880 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
     808</pre><div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Cache-Control</a>   = &lt;Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>&gt;
     809  <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>&gt;
     810  <a href="#abnf.dependencies" class="smpl">Warning</a>         = &lt;Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>&gt;
     811</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="when" href="#when">When to use HTTP</a></h1>
     812      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
     813      <p id="rfc.section.2.1.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used in HTTP to indicate the target of a request and to identify additional resources related to that resource, the request,
     814         or the response. Each protocol element in HTTP that allows a URI reference will indicate in its ABNF whether the element allows
     815         only a URI in absolute form, any relative reference, or some limited subset of the URI-reference grammar. Unless otherwise
     816         indicated, relative URI references are to be parsed relative to the URI corresponding to the request target (the base URI).
     817      </p>
     818      <p id="rfc.section.2.1.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port", "host", "path-abempty",
     819         "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>:
     820      </p>
     821      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#uri" class="smpl">absolute-URI</a>   = &lt;absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>&gt;
     822  <a href="#uri" class="smpl">authority</a>     = &lt;authority, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2">Section 3.2</a>&gt;
     823  <a href="#uri" class="smpl">fragment</a>      = &lt;fragment, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>&gt;
     824  <a href="#uri" class="smpl">path-abempty</a>  = &lt;path-abempty, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>&gt;
     825  <a href="#uri" class="smpl">path-absolute</a> = &lt;path-absolute, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.8"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>&gt;
     826  <a href="#uri" class="smpl">port</a>          = &lt;port, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.3">Section 3.2.3</a>&gt;
     827  <a href="#uri" class="smpl">query</a>         = &lt;query, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.4">Section 3.4</a>&gt;
     828  <a href="#uri" class="smpl">uri-host</a>      = &lt;host, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.11"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>&gt;
     829</pre><p id="rfc.section.2.1.p.4">HTTP does not place an a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     830      </p>
     831      <p id="rfc.section.2.1.p.5"> </p>
     832      <dl class="empty">
     833         <dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations
     834            might not properly support these lengths.
     835         </dd>
     836      </dl>
     837      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3>
     838      <div id="rfc.iref.h.1"></div>
     839      <div id="rfc.iref.u.1"></div>
     840      <p id="rfc.section.2.1.1.p.1">The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the syntax and semantics
     841         for identifiers using the http or https URI schemes.
     842      </p>
     843      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     844</pre><p id="rfc.section.2.1.1.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server
     845         listening for TCP connections on that port of that host, and the Request-URI for the resource is path-absolute (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
     846      </p>
     847      <dl class="empty">
     848         <dd> <span id="rfc.iref.h.2"></span>  <span id="rfc.iref.u.2"></span>  <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
     849         </dd>
     850      </dl>
     851      <h3 id="rfc.section.2.1.2"><a href="#rfc.section.2.1.2">2.1.2</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
     852      <p id="rfc.section.2.1.2.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
     853      </p>
     854      <ul>
     855         <li>A port that is empty or not given is equivalent to the default port for that URI-reference;</li>
     856         <li>Comparisons of host names <em class="bcp14">MUST</em> be case-insensitive;
     857         </li>
     858         <li>Comparisons of scheme names <em class="bcp14">MUST</em> be case-insensitive;
     859         </li>
     860         <li>An empty path-absolute is equivalent to an path-absolute of "/".</li>
     861      </ul>
     862      <p id="rfc.section.2.1.2.p.2">Characters other than those in the "reserved" set (see <a href="#RFC3986" id="rfc.xref.RFC3986.12"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.2">Section 2.2</a>) are equivalent to their ""%" <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>  <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>" encoding.
     863      </p>
     864      <p id="rfc.section.2.1.2.p.3">For example, the following three URIs are equivalent:</p>
     865      <div id="rfc.figure.u.17"></div><pre class="text">   http://example.com:80/~smith/home.html
     866   http://EXAMPLE.com/%7Esmith/home.html
     867   http://EXAMPLE.com:/%7esmith/home.html
     868</pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2>
     869      <p id="rfc.section.2.2.p.1">HTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol
     870         version, followed by a MIME-like message containing request modifiers, client information, and possible body content over
     871         a connection with a server. The server responds with a status line, including the message's protocol version and a success
     872         or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body
     873         content.
     874      </p>
     875      <p id="rfc.section.2.2.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin
     876         server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin
     877         server (O).
     878      </p>
     879      <div id="rfc.figure.u.18"></div><pre class="drawing">       request chain ------------------------&gt;
     880    UA -------------------v------------------- O
     881       &lt;----------------------- response chain
     882</pre><p id="rfc.section.2.2.p.4">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three
     883         common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its
     884         absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by
     885         the URI. A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests
     886         to the underlying server's protocol. A tunnel acts as a relay point between two connections without changing the messages;
     887         tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary
     888         cannot understand the contents of the messages.
     889      </p>
     890      <div id="rfc.figure.u.19"></div><pre class="drawing">       request chain --------------------------------------&gt;
     891    UA -----v----- A -----v----- B -----v----- C -----v----- O
     892       &lt;------------------------------------- response chain
     893</pre><p id="rfc.section.2.2.p.6">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
     894         message that travels the whole chain will pass through four separate connections. This distinction is important because some
     895         HTTP communication options may apply only to the connection with the nearest, non-tunnel neighbor, only to the end-points
     896         of the chain, or to all connections along the chain. Although the diagram is linear, each participant may be engaged in multiple,
     897         simultaneous communications. For example, B may be receiving requests from many clients other than A, and/or forwarding requests
     898         to servers other than C, at the same time that it is handling A's request.
     899      </p>
     900      <p id="rfc.section.2.2.p.7">Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect
     901         of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response
     902         applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from
     903         O (via C) for a request which has not been cached by UA or A.
     904      </p>
     905      <div id="rfc.figure.u.20"></div><pre class="drawing">          request chain ----------&gt;
     906       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
     907          &lt;--------- response chain
     908</pre><p id="rfc.section.2.2.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache
     909         behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching" title="Introduction">Section 1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     910      </p>
     911      <p id="rfc.section.2.2.p.10">In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with
     912         or deployed across the World Wide Web. These systems include national hierarchies of proxy caches to save transoceanic bandwidth,
     913         systems that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so
     914         on. HTTP systems are used in corporate intranets over high-bandwidth links, and for access via PDAs with low-power radio links
     915         and intermittent connectivity. The goal of HTTP/1.1 is to support the wide diversity of configurations already deployed while
     916         introducing protocol constructs that meet the needs of those who build web applications that require high reliability and,
     917         failing that, at least reliable indications of failure.
     918      </p>
     919      <p id="rfc.section.2.2.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (&lt;<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>&gt;), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,
     920         or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the
     921         mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside
     922         the scope of this specification.
     923      </p>
     924      <p id="rfc.section.2.2.p.12">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may
     925         be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>).
     926      </p>
     927      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    881928      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="http.version" href="#http.version">HTTP Version</a></h2>
    882929      <p id="rfc.section.3.1.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended
    … …  
    889936      </p>
    890937      <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>
    891       <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>
     938      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>
    892939  <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive
    893940</pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3.
    … …  
    910957         </dd>
    911958      </dl>
    912       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    913       <p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[RFC1737]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location,
    914          or any other characteristic--a resource.
    915       </p>
    916       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="general.syntax" href="#general.syntax">General Syntax</a></h3>
    917       <p id="rfc.section.3.2.1.p.1">URIs in HTTP can be represented in absolute form or relative to some known base URI <a href="#RFC1808" id="rfc.xref.RFC1808.1"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>, depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with
    918          a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers
    919          (URI): Generic Syntax and Semantics," <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port", "host",
    920          "abs_path", "query", and "authority" from that specification:
    921       </p>
    922       <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span>  <a href="#general.syntax" class="smpl">absoluteURI</a>   = &lt;absoluteURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3">Section 3</a>&gt;
    923   <a href="#general.syntax" class="smpl">authority</a>     = &lt;authority, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.3"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2">Section 3.2</a>&gt;
    924   <a href="#general.syntax" class="smpl">fragment</a>      = &lt;fragment, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.4"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-4.1">Section 4.1</a>&gt;
    925   <a href="#general.syntax" class="smpl">path-absolute</a> = &lt;abs_path, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.5"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3">Section 3</a>&gt;
    926   <a href="#general.syntax" class="smpl">port</a>          = &lt;port, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.6"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2.2">Section 3.2.2</a>&gt;
    927   <a href="#general.syntax" class="smpl">query</a>         = &lt;query, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.7"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.4">Section 3.4</a>&gt;
    928   <a href="#general.syntax" class="smpl">relativeURI</a>   = &lt;relativeURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.8"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-5">Section 5</a>&gt;
    929   <a href="#general.syntax" class="smpl">uri-host</a>      = &lt;host, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.9"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2.2">Section 3.2.2</a>&gt;
    930 </pre><p id="rfc.section.3.2.1.p.3">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    931       </p>
    932       <p id="rfc.section.3.2.1.p.4"> </p>
    933       <dl class="empty">
    934          <dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations
    935             might not properly support these lengths.
    936          </dd>
    937       </dl>
    938       <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="http.url" href="#http.url">http URL</a></h3>
    939       <div id="rfc.iref.h.1"></div>
    940       <div id="rfc.iref.u.1"></div>
    941       <p id="rfc.section.3.2.2.p.1">The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax
    942          and semantics for http URLs.
    943       </p>
    944       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#http.url" class="smpl">http-URL</a> = "http:" "//" <a href="#general.syntax" class="smpl">uri-host</a> [ ":" <a href="#general.syntax" class="smpl">port</a> ]
    945              [ <a href="#general.syntax" class="smpl">path-absolute</a> [ "?" <a href="#general.syntax" class="smpl">query</a> ]]
    946 </pre><p id="rfc.section.3.2.2.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server
    947          listening for TCP connections on that port of that host, and the Request-URI for the resource is path-absolute (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    948       </p>
    949       <dl class="empty">
    950          <dd> <span id="rfc.iref.h.2"></span>  <span id="rfc.iref.u.2"></span>  <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
    951          </dd>
    952       </dl>
    953       <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
    954       <p id="rfc.section.3.2.3.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
    955       </p>
    956       <ul>
    957          <li>A port that is empty or not given is equivalent to the default port for that URI-reference;</li>
    958          <li>Comparisons of host names <em class="bcp14">MUST</em> be case-insensitive;
    959          </li>
    960          <li>Comparisons of scheme names <em class="bcp14">MUST</em> be case-insensitive;
    961          </li>
    962          <li>An empty path-absolute is equivalent to an path-absolute of "/".</li>
    963       </ul>
    964       <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see <a href="#RFC2396" id="rfc.xref.RFC2396.10"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-2.2">Section 2.2</a>) are equivalent to their ""%" <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>  <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>" encoding.
    965       </p>
    966       <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p>
    967       <div id="rfc.figure.u.21"></div><pre class="text">   http://example.com:80/~smith/home.html
    968    http://EXAMPLE.com/%7Esmith/home.html
    969    http://EXAMPLE.com:/%7esmith/home.html
    970 </pre><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2>
    971       <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="full.date" href="#full.date">Full Date</a></h3>
    972       <p id="rfc.section.3.3.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p>
     959      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2>
     960      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="full.date" href="#full.date">Full Date</a></h3>
     961      <p id="rfc.section.3.2.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p>
    973962      <div id="rfc.figure.u.22"></div><pre class="text">   Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
    974963   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    975964   Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    976 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers
     965</pre><p id="rfc.section.3.2.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers
    977966         that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for further information.
    978967      </p>
    … …  
    982971         </dd>
    983972      </dl>
    984       <p id="rfc.section.3.3.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated
     973      <p id="rfc.section.3.2.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated
    985974         Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
    986975         time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional LWS beyond that specifically included as SP in the grammar.
    … …  
    10371026  s-Nov = %x4E.6F.76 ; "Nov", case-sensitive
    10381027  s-Dec = %x44.65.63 ; "Dec", case-sensitive
    1039 </pre><p id="rfc.section.3.3.1.p.7"> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers
     1028</pre><p id="rfc.section.3.2.1.p.7"> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers
    10401029         are not required to use these formats for user presentation, request logging, etc.
    10411030      </p>
    1042       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
    1043       <p id="rfc.section.3.4.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to
     1031      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
     1032      <p id="rfc.section.3.3.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to
    10441033         an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding
    10451034         is a property of the message, not of the original entity.
    … …  
    10481037  <a href="#transfer.codings" class="smpl">transfer-extension</a>      = <a href="#rule.token.separators" class="smpl">token</a> *( ";" <a href="#transfer.codings" class="smpl">parameter</a> )
    10491038</pre><div id="rule.parameter">
    1050          <p id="rfc.section.3.4.p.3">      Parameters are in the form of attribute/value pairs.</p>
     1039         <p id="rfc.section.3.3.p.3">      Parameters are in the form of attribute/value pairs.</p>
    10511040      </div>
    10521041      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span>  <a href="#transfer.codings" class="smpl">parameter</a>               = <a href="#rule.parameter" class="smpl">attribute</a> "=" <a href="#rule.parameter" class="smpl">value</a>
    10531042  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
    10541043  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>
    1055 </pre><p id="rfc.section.3.4.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;8.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;8.7</a>).
    1056       </p>
    1057       <p id="rfc.section.3.4.p.6">Whenever a transfer-coding is applied to a message-body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding
     1044</pre><p id="rfc.section.3.3.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;8.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;8.7</a>).
     1045      </p>
     1046      <p id="rfc.section.3.3.p.6">Whenever a transfer-coding is applied to a message-body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding
    10581047         is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message
    10591048         (<a href="#message.length" title="Message Length">Section&nbsp;4.4</a>).
    10601049      </p>
    1061       <p id="rfc.section.3.4.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has
     1050      <p id="rfc.section.3.3.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has
    10621051         a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty
    10631052         in determining the exact body length (<a href="#message.length" title="Message Length">Section&nbsp;4.4</a>), or the desire to encrypt data over a shared transport.
    10641053      </p>
    1065       <p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry
    1066          contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    1067       </p>
    1068       <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    1069       </p>
    1070       <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
    1071       </p>
    1072       <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="chunked.transfer.encoding" href="#chunked.transfer.encoding">Chunked Transfer Coding</a></h3>
    1073       <p id="rfc.section.3.4.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
     1054      <p id="rfc.section.3.3.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry
     1055         contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.3.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     1056      </p>
     1057      <p id="rfc.section.3.3.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     1058      </p>
     1059      <p id="rfc.section.3.3.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
     1060      </p>
     1061      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="chunked.transfer.encoding" href="#chunked.transfer.encoding">Chunked Transfer Coding</a></h3>
     1062      <p id="rfc.section.3.3.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
    10741063         indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information
    10751064         necessary for the recipient to verify that it has received the full message.
    … …  
    10901079  <a href="#chunked.transfer.encoding" class="smpl">chunk-data</a>     = 1*<a href="#core.rules" class="smpl">OCTET</a> ; a sequence of chunk-size octets
    10911080  <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a>   = *(<a href="#abnf.dependencies" class="smpl">entity-header</a> <a href="#rule.CRLF" class="smpl">CRLF</a>)
    1092 </pre><p id="rfc.section.3.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
     1081</pre><p id="rfc.section.3.3.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
    10931082         by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
    10941083      </p>
    1095       <p id="rfc.section.3.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
     1084      <p id="rfc.section.3.3.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
    10961085         can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;8.6</a>).
    10971086      </p>
    1098       <p id="rfc.section.3.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
     1087      <p id="rfc.section.3.3.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
    10991088      </p>
    11001089      <ol>
    … …  
    11071096         </li>
    11081097      </ol>
    1109       <p id="rfc.section.3.4.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
     1098      <p id="rfc.section.3.3.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
    11101099         forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly
    11111100         infinite buffer on the proxy.
    11121101      </p>
    1113       <p id="rfc.section.3.4.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
     1102      <p id="rfc.section.3.3.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
    11141103      <div id="rfc.figure.u.27"></div><pre class="text">    length := 0
    11151104    read chunk-size, chunk-extension (if any) and CRLF
    … …  
    11271116    Content-Length := length
    11281117    Remove "chunked" from Transfer-Encoding
    1129 </pre><p id="rfc.section.3.4.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding, and <em class="bcp14">MUST</em> ignore chunk-extension extensions they do not understand.
    1130       </p>
    1131       <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
    1132       <p id="rfc.section.3.5.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
     1118</pre><p id="rfc.section.3.3.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding, and <em class="bcp14">MUST</em> ignore chunk-extension extensions they do not understand.
     1119      </p>
     1120      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
     1121      <p id="rfc.section.3.4.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
    11331122         using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white
    11341123         space. By convention, the products are listed in order of their significance for identifying the application.
    … …  
    11361125      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
    11371126  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    1138 </pre><p id="rfc.section.3.5.p.3">Examples:</p>
     1127</pre><p id="rfc.section.3.4.p.3">Examples:</p>
    11391128      <div id="rfc.figure.u.29"></div><pre class="text">    User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    11401129    Server: Apache/0.8.4
    1141 </pre><p id="rfc.section.3.5.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
     1130</pre><p id="rfc.section.3.4.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
    11421131      </p>
    11431132      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="http.message" href="#http.message">HTTP Message</a></h1>
    … …  
    12011190               / &lt;entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>&gt;
    12021191</pre><p id="rfc.section.4.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding
    1203          is a property of the message, not of the entity, and thus <em class="bcp14">MAY</em> be added or removed by any application along the request/response chain. (However, <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a> places restrictions on when certain transfer-codings may be used.)
     1192         is a property of the message, not of the entity, and thus <em class="bcp14">MAY</em> be added or removed by any application along the request/response chain. (However, <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a> places restrictions on when certain transfer-codings may be used.)
    12041193      </p>
    12051194      <p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
    … …  
    12261215         </li>
    12271216         <li>
    1228             <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;8.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>) is used, the transfer-length is defined by the use of this transfer-coding. If a Transfer-Encoding header field is present
     1217            <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;8.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>) is used, the transfer-length is defined by the use of this transfer-coding. If a Transfer-Encoding header field is present
    12291218               and the "chunked" transfer-coding is not present, the transfer-length is defined by the sender closing the connection.
    12301219            </p>
    … …  
    12561245         to insist on receiving a valid Content-Length.
    12571246      </p>
    1258       <p id="rfc.section.4.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
     1247      <p id="rfc.section.4.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
    12591248      </p>
    12601249      <p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.
    … …  
    12981287      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    12991288</pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="request-uri" href="#request-uri">Request-URI</a></h3>
    1300       <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;3.2</a>) and identifies the resource upon which to apply the request.
     1289      <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.1</a>) and identifies the resource upon which to apply the request.
    13011290      </p>
    13021291      <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.75"></span>  <a href="#request-uri" class="smpl">Request-URI</a>    = "*"
    1303                  / <a href="#general.syntax" class="smpl">absoluteURI</a>
    1304                  / ( <a href="#general.syntax" class="smpl">path-absolute</a> [ "?" <a href="#general.syntax" class="smpl">query</a> ] )
    1305                  / <a href="#general.syntax" class="smpl">authority</a>
     1292                 / <a href="#uri" class="smpl">absolute-URI</a>
     1293                 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] )
     1294                 / <a href="#uri" class="smpl">authority</a>
    13061295</pre><p id="rfc.section.5.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does
    13071296         not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
    … …  
    13091298      </p>
    13101299      <div id="rfc.figure.u.39"></div><pre class="text">    OPTIONS * HTTP/1.1
    1311 </pre><p id="rfc.section.5.1.2.p.5">The absoluteURI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
    1312          and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request
     1300</pre><p id="rfc.section.5.1.2.p.5">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
     1301         and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
    13131302         loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example
    13141303         Request-Line would be:
    13151304      </p>
    13161305      <div id="rfc.figure.u.40"></div><pre class="text">    GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1317 </pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
     1306</pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    13181307      </p>
    13191308      <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13201309      </p>
    13211310      <p id="rfc.section.5.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute
    1322          path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#general.syntax" title="General Syntax">Section&nbsp;3.2.1</a>, path-absolute) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
     1311         path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>, path-absolute) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
    13231312         server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
    13241313      </p>
    … …  
    13281317         URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
    13291318      </p>
    1330       <p id="rfc.section.5.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="#general.syntax" title="General Syntax">Section&nbsp;3.2.1</a>. If the Request-URI is encoded using the "% <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>  <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>" encoding (<a href="#RFC2396" id="rfc.xref.RFC2396.11"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-2.4.1">Section 2.4.1</a>), the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.
     1319      <p id="rfc.section.5.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>. If the Request-URI is encoded using the "% <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>  <a href="#rule.HEXDIG" class="smpl">HEXDIG</a>" encoding (<a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.4">Section 2.4</a>), the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.
    13311320      </p>
    13321321      <p id="rfc.section.5.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received Request-URI when forwarding it to the next inbound server, except as noted
    … …  
    13481337      </p>
    13491338      <ol>
    1350          <li>If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
    1351          </li>
    1352          <li>If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host
     1339         <li>If Request-URI is an absolute-URI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
     1340         </li>
     1341         <li>If the Request-URI is not an absolute-URI, and the request includes a Host header field, the host is determined by the Host
    13531342            header field value.
    13541343         </li>
    … …  
    14851474      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    14861475      <p id="rfc.section.7.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 while it is transmitting the request. If the client sees an error status,
    1487          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;3.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, the client <em class="bcp14">MUST</em> close the connection.
     1476         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;3.3</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, the client <em class="bcp14">MUST</em> close the connection.
    14881477      </p>
    14891478      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.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>
    … …  
    16231612      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    16241613      <p id="rfc.section.8.3.p.1">The Date general-header field represents the date and time at which the message was originated, having the same semantics
    1625          as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
     1614         as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section&nbsp;3.2.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    16261615      </p>
    16271616      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#header.date" class="smpl">Date</a>  = "Date" ":" <a href="#full.date" class="smpl">HTTP-date</a>
    … …  
    16591648      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
    16601649      <p id="rfc.section.8.4.p.1">The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from
    1661          the original URI given by the user or referring resource (generally an HTTP URL, as described in <a href="#http.url" title="http URL">Section&nbsp;3.2.2</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or
     1650         the original URI given by the user or referring resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or
    16621651         gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on
    16631652         a single IP address.
    16641653      </p>
    1665       <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.85"></span>  <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#general.syntax" class="smpl">uri-host</a> [ ":" <a href="#general.syntax" class="smpl">port</a> ] ; <a href="#http.url" title="http URL">Section&nbsp;3.2.2</a>
     1654      <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.85"></span>  <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>
    16661655</pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
    16671656         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
    … …  
    16801669      <p id="rfc.section.8.5.p.1">The TE request-header field indicates what extension transfer-codings it is willing to accept in the response and whether
    16811670         or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers"
    1682          and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>).
     1671         and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>).
    16831672      </p>
    16841673      <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span>  <a href="#header.te" class="smpl">TE</a>        = "TE" ":" #( <a href="#header.te" class="smpl">t-codings</a> )
    16851674  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#abnf.dependencies" class="smpl">accept-params</a> ] )
    16861675</pre><p id="rfc.section.8.5.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    1687          as defined in <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
     1676         as defined in <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.3.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
    16881677      </p>
    16891678      <p id="rfc.section.8.5.p.4">Examples of its use are:</p>
    … …  
    17291718         to know which header fields to expect in the trailer.
    17301719      </p>
    1731       <p id="rfc.section.8.6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
     1720      <p id="rfc.section.8.6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.3.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
    17321721      </p>
    17331722      <p id="rfc.section.8.6.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
    … …  
    17461735      </p>
    17471736      <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.89"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>       = "Transfer-Encoding" ":" 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    1748 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>. An example is:
     1737</pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>. An example is:
    17491738      </p>
    17501739      <div id="rfc.figure.u.57"></div><pre class="text">  Transfer-Encoding: chunked
    … …  
    17931782  <a href="#header.via" class="smpl">protocol-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
    17941783  <a href="#header.via" class="smpl">protocol-version</a>  = <a href="#rule.token.separators" class="smpl">token</a>
    1795   <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#general.syntax" class="smpl">uri-host</a> [ ":" <a href="#general.syntax" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
     1784  <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>
    17961785  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    17971786</pre><p id="rfc.section.8.9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    … …  
    19081897      <p id="rfc.section.9.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    19091898      <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>
    1910       <p id="rfc.section.9.2.p.1">The entry for the "http" URI Scheme 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; should be updated to point to <a href="#http.url" title="http URL">Section&nbsp;3.2.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>).
     1899      <p id="rfc.section.9.2.p.1">The entry for the "http" URI Scheme 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; should be updated to point to <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</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>).
    19111900      </p>
    19121901      <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>
    … …  
    20922081      <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
    20932082      <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    2094       <p id="rfc.section.11.p.1">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and
    2095          Internet mail message formats.
    2096       </p>
    2097       <p id="rfc.section.11.p.2">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people
     2083      <p id="rfc.section.11.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people
    20982084         who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success
    20992085         of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks,
    … …  
    21012087         and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
    21022088      </p>
    2103       <p id="rfc.section.11.p.3">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already
     2089      <p id="rfc.section.11.p.2">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already
    21042090         mentioned, the following individuals have contributed to this specification:
    21052091      </p>
    2106       <p id="rfc.section.11.p.4">Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman
     2092      <p id="rfc.section.11.p.3">Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman
    21072093         Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann,
    21082094         Bob Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben
    … …  
    21122098         Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen.
    21132099      </p>
    2114       <p id="rfc.section.11.p.5">Thanks to the "cave men" of Palo Alto. You know who you are.</p>
    2115       <p id="rfc.section.11.p.6">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott
     2100      <p id="rfc.section.11.p.4">Thanks to the "cave men" of Palo Alto. You know who you are.</p>
     2101      <p id="rfc.section.11.p.5">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott
    21162102         Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the
    21172103         "MUST/MAY/SHOULD" audit.
    21182104      </p>
    2119       <p id="rfc.section.11.p.7">The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank
     2105      <p id="rfc.section.11.p.6">The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank
    21202106         them for the discovery of many of the problems that this document attempts to rectify.
     2107      </p>
     2108      <p id="rfc.section.11.p.7">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and
     2109         Internet mail message formats.
    21212110      </p>
    21222111      <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References
    … …  
    21682157         </tr>
    21692158         <tr>
    2170             <td class="reference"><b id="RFC2396">[RFC2396]</b></td>
    2171             <td class="top"><a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="Department of Information and Computer Science">Fielding, R.T.</a>, and <a title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.
     2159            <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
     2160            <td class="top"><a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="Day Software">Fielding, R.</a>, and <a title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, RFC&nbsp;3986, STD&nbsp;66, January&nbsp;2005.
    21722161            </td>
    21732162         </tr>
    … …  
    21842173      <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References
    21852174      </h2>
    2186       <table summary="Informative References">                                                           
     2175      <table summary="Informative References">                                               
    21872176         <tr>
    21882177            <td class="reference"><b id="Kri2001">[Kri2001]</b></td>
    … …  
    22172206         </tr>
    22182207         <tr>
    2219             <td class="reference"><b id="RFC1630">[RFC1630]</b></td>
    2220             <td class="top"><a title="CERN, World-Wide Web project">Berners-Lee, T.</a>, “<a href="http://tools.ietf.org/html/rfc1630">Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network
    2221                   as used in the World-Wide Web</a>”, RFC&nbsp;1630, June&nbsp;1994.
    2222             </td>
    2223          </tr>
    2224          <tr>
    2225             <td class="reference"><b id="RFC1737">[RFC1737]</b></td>
    2226             <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a title="MIT Laboratory for Computer Science">K. Sollins</a>, “<a href="http://tools.ietf.org/html/rfc1737">Functional Requirements for Uniform Resource Names</a>”, RFC&nbsp;1737, December&nbsp;1994.
    2227             </td>
    2228          </tr>
    2229          <tr>
    2230             <td class="reference"><b id="RFC1738">[RFC1738]</b></td>
    2231             <td class="top"><a title="CERN, World-Wide Web project">Berners-Lee, T.</a>, <a title="Xerox PARC">Masinter, L.</a>, and <a title="University of Minnesota, Computer and Information Services">M. McCahill</a>, “<a href="http://tools.ietf.org/html/rfc1738">Uniform Resource Locators (URL)</a>”, RFC&nbsp;1738, December&nbsp;1994.
    2232             </td>
    2233          </tr>
    2234          <tr>
    2235             <td class="reference"><b id="RFC1808">[RFC1808]</b></td>
    2236             <td class="top"><a title="University of California Irvine, Department of Information and Computer Science">Fielding, R.</a>, “<a href="http://tools.ietf.org/html/rfc1808">Relative Uniform Resource Locators</a>”, RFC&nbsp;1808, June&nbsp;1995.
    2237             </td>
    2238          </tr>
    2239          <tr>
    22402208            <td class="reference"><b id="RFC1900">[RFC1900]</b></td>
    22412209            <td class="top"><a title="CERN, Computing and Networks Division">Carpenter, B.</a> and <a title="cisco Systems">Y. Rekhter</a>, “<a href="http://tools.ietf.org/html/rfc1900">Renumbering Needs Work</a>”, RFC&nbsp;1900, February&nbsp;1996.
    … …  
    22632231         </tr>
    22642232         <tr>
    2265             <td class="reference"><b id="RFC2324">[RFC2324]</b></td>
    2266             <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="http://tools.ietf.org/html/rfc2324">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</a>”, RFC&nbsp;2324, April&nbsp;1998.
    2267             </td>
    2268          </tr>
    2269          <tr>
    22702233            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    22712234            <td class="top"><a title="University of California, Irvine">Fielding, R.</a>, <a title="W3C">Gettys, J.</a>, <a title="Compaq Computer Corporation">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a title="Xerox Corporation">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
    … …  
    22752238            <td class="reference"><b id="RFC2818">[RFC2818]</b></td>
    22762239            <td class="top"><a title="RTFM, Inc.">Rescorla, E.</a>, “<a href="http://tools.ietf.org/html/rfc2818">HTTP Over TLS</a>”, RFC&nbsp;2818, May&nbsp;2000.
    2277             </td>
    2278          </tr>
    2279          <tr>
    2280             <td class="reference"><b id="RFC2821">[RFC2821]</b></td>
    2281             <td class="top"><a title="AT&amp;T Laboratories">Klensin, J.</a>, “<a href="http://tools.ietf.org/html/rfc2821">Simple Mail Transfer Protocol</a>”, RFC&nbsp;2821, April&nbsp;2001.
    22822240            </td>
    22832241         </tr>
    … …  
    23802338      </ul>
    23812339      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h1>
    2382       <p id="rfc.section.B.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#full.date" title="Full Date">Section&nbsp;3.3.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
     2340      <p id="rfc.section.B.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#full.date" title="Full Date">Section&nbsp;3.2.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
    23832341      </p>
    23842342      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    2385       <p id="rfc.section.C.p.1">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately
     2343      <p id="rfc.section.C.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred
     2344         to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single method and no metadata.
     2345         HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, added a range of request methods and MIME-like messaging that could include metadata about the data transferred and modifiers
     2346         on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical
     2347         proxies, caching, the need for persistent connections, or name-based virtual hosts. The proliferation of incompletely-implemented
     2348         applications calling themselves "HTTP/1.0" further necessitated a protocol version change in order for two communicating applications
     2349         to determine each other's true capabilities.
     2350      </p>
     2351      <p id="rfc.section.C.p.2">HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding
     2352         only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a
     2353         party advertising compliance with HTTP/1.1.
     2354      </p>
     2355      <p id="rfc.section.C.p.3">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately
    23862356         designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification
    23872357         (1996), we would expect commercial HTTP/1.1 servers to:
    … …  
    23922362         <li>respond appropriately with a message in the same major version used by the client.</li>
    23932363      </ul>
    2394       <p id="rfc.section.C.p.2">And we would expect HTTP/1.1 clients to: </p>
     2364      <p id="rfc.section.C.p.4">And we would expect HTTP/1.1 clients to: </p>
    23952365      <ul>
    23962366         <li>recognize the format of the Status-Line for HTTP/1.0 and 1.1 responses;</li>
    23972367         <li>understand any valid response in the format of HTTP/0.9, 1.0, or 1.1.</li>
    23982368      </ul>
    2399       <p id="rfc.section.C.p.3">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the
     2369      <p id="rfc.section.C.p.5">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the
    24002370         server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described
    24012371         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.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    … …  
    24472417      <p id="rfc.section.C.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    24482418         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    2449          computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.4</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
     2419         computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
    24502420      </p>
    24512421      <p id="rfc.section.C.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0
    … …  
    24562426         codings), a new header field (TE) and enabling trailer headers in the future. Transfer encoding is a major performance benefit,
    24572427         so it was worth fixing <a href="#Nie1997" id="rfc.xref.Nie1997.2"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. TE also solves another, obscure, downward interoperability problem that could have occurred due to interactions between
    2458          authentication trailers, chunked encoding and HTTP/1.0 clients.(Section <a href="#transfer.codings" title="Transfer Codings">3.4</a>, <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">3.4.1</a>, and <a href="#header.te" id="rfc.xref.header.te.4" title="TE">8.5</a>)
     2428         authentication trailers, chunked encoding and HTTP/1.0 clients.(Section <a href="#transfer.codings" title="Transfer Codings">3.3</a>, <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">3.3.1</a>, and <a href="#header.te" id="rfc.xref.header.te.4" title="TE">8.5</a>)
    24592429      </p>
    24602430      <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    24612431      <p id="rfc.section.C.4.p.1">The CHAR rule does not allow the NUL character anymore (this affects the comment and quoted-string rules). Furthermore, the
    2462          quoted-pair rule does not allow escaping NUL, CR or LF anymore. (<a href="#basic.rules" title="Basic Rules">Section&nbsp;2.2</a>)
     2432         quoted-pair rule does not allow escaping NUL, CR or LF anymore. (<a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>)
    24632433      </p>
    24642434      <p id="rfc.section.C.4.p.2">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section&nbsp;3.1</a>)
    24652435      </p>
    2466       <p id="rfc.section.C.4.p.3">Remove reference to non-existant identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">3.4</a> and <a href="#message.length" title="Message Length">4.4</a>)
    2467       </p>
    2468       <p id="rfc.section.C.4.p.4">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a>)
    2469       </p>
    2470       <p id="rfc.section.C.4.p.5">Fix BNF to add query, as the abs_path production in <a href="http://tools.ietf.org/html/rfc2396#section-3">Section 3</a> of <a href="#RFC2396" id="rfc.xref.RFC2396.12"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> doesn't define it. (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>)
     2436      <p id="rfc.section.C.4.p.3">Remove reference to non-existant identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a> and <a href="#message.length" title="Message Length">4.4</a>)
     2437      </p>
     2438      <p id="rfc.section.C.4.p.4">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.3.1</a>)
     2439      </p>
     2440      <p id="rfc.section.C.4.p.5">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>)
    24712441      </p>
    24722442      <p id="rfc.section.C.4.p.6">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;8.1</a>)
    … …  
    24752445      <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a>&nbsp;Since RFC2616
    24762446      </h2>
    2477       <p id="rfc.section.D.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
     2447      <p id="rfc.section.D.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    24782448      </p>
    24792449      <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a>&nbsp;Since draft-ietf-httpbis-p1-messaging-00
    … …  
    25432513      <ul>
    25442514         <li>Get rid of duplicate BNF rule names ("host" -&gt; "uri-host", "trailer" -&gt; "trailer-part").</li>
    2545          <li>Avoid underscore character in rule names ("http_URL" -&gt; "http-URL", "abs_path" -&gt; "path-absolute").</li>
    2546          <li>Add rules for terms imported from URI spec ("absoluteURI", "authority", "path-absolute", "port", "query", "relativeURI", "host)
    2547             -- these will have to be updated when switching over to RFC3986.
     2515         <li>Avoid underscore character in rule names ("http_URL" -&gt; "http-URI", "abs_path" -&gt; "path-absolute").</li>
     2516         <li>Add rules for terms imported from URI spec ("absolute-URI", "authority", "path-abempty", "path-absolute", "uri-host", "port",
     2517            "query").
    25482518         </li>
    25492519         <li>Synchronize core rules with RFC5234 (this includes a change to CHAR which now excludes NUL).</li>
    … …  
    26342604      </p>
    26352605      <dl class="empty">
    2636          <dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or
     2606         <dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.1</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or
    26372607            vary in other ways.
    26382608         </dd>
    … …  
    28002770                  <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
    28012771                     <ul class="ind">
    2802                         <li class="indline1"><tt>absoluteURI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>3.2.1</b></a></li>
    2803                         <li class="indline1"><tt>ALPHA</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3"><b>2.2</b></a></li>
    2804                         <li class="indline1"><tt>asctime-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>3.3.1</b></a></li>
    2805                         <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.49"><b>3.4</b></a></li>
    2806                         <li class="indline1"><tt>authority</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>3.2.1</b></a></li>
    2807                         <li class="indline1"><tt>CHAR</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li>
    2808                         <li class="indline1"><tt>chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.52"><b>3.4.1</b></a></li>
    2809                         <li class="indline1"><tt>chunk-data</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.58"><b>3.4.1</b></a></li>
    2810                         <li class="indline1"><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.56"><b>3.4.1</b></a></li>
    2811                         <li class="indline1"><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.57"><b>3.4.1</b></a></li>
    2812                         <li class="indline1"><tt>chunk-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.55"><b>3.4.1</b></a></li>
    2813                         <li class="indline1"><tt>chunk-size</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.53"><b>3.4.1</b></a></li>
    2814                         <li class="indline1"><tt>Chunked-Body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.51"><b>3.4.1</b></a></li>
    2815                         <li class="indline1"><tt>comment</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>2.2</b></a></li>
     2772                        <li class="indline1"><tt>absolute-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>2.1</b></a></li>
     2773                        <li class="indline1"><tt>ALPHA</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3"><b>1.2</b></a></li>
     2774                        <li class="indline1"><tt>asctime-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>3.2.1</b></a></li>
     2775                        <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.49"><b>3.3</b></a></li>
     2776                        <li class="indline1"><tt>authority</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>2.1</b></a></li>
     2777                        <li class="indline1"><tt>CHAR</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>1.2</b></a></li>
     2778                        <li class="indline1"><tt>chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.52"><b>3.3.1</b></a></li>
     2779                        <li class="indline1"><tt>chunk-data</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.58"><b>3.3.1</b></a></li>
     2780                        <li class="indline1"><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.56"><b>3.3.1</b></a></li>
     2781                        <li class="indline1"><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.57"><b>3.3.1</b></a></li>
     2782                        <li class="indline1"><tt>chunk-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.55"><b>3.3.1</b></a></li>
     2783                        <li class="indline1"><tt>chunk-size</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.53"><b>3.3.1</b></a></li>
     2784                        <li class="indline1"><tt>Chunked-Body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.51"><b>3.3.1</b></a></li>
     2785                        <li class="indline1"><tt>comment</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>1.2.2</b></a></li>
    28162786                        <li class="indline1"><tt>Connection</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.81"><b>8.1</b></a></li>
    28172787                        <li class="indline1"><tt>connection-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.82"><b>8.1</b></a></li>
    28182788                        <li class="indline1"><tt>Content-Length</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.83"><b>8.2</b></a></li>
    2819                         <li class="indline1"><tt>CR</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>2.2</b></a></li>
    2820                         <li class="indline1"><tt>CRLF</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>2.2</b></a></li>
    2821                         <li class="indline1"><tt>ctext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>2.2</b></a></li>
    2822                         <li class="indline1"><tt>CTL</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>2.2</b></a></li>
     2789                        <li class="indline1"><tt>CR</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>1.2</b></a></li>
     2790                        <li class="indline1"><tt>CRLF</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>1.2.2</b></a></li>
     2791                        <li class="indline1"><tt>ctext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>1.2.2</b></a></li>
     2792                        <li class="indline1"><tt>CTL</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>1.2</b></a></li>
    28232793                        <li class="indline1"><tt>Date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.84"><b>8.3</b></a></li>
    2824                         <li class="indline1"><tt>date1</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>3.3.1</b></a></li>
    2825                         <li class="indline1"><tt>date2</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>3.3.1</b></a></li>
    2826                         <li class="indline1"><tt>date3</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>3.3.1</b></a></li>
    2827                         <li class="indline1"><tt>DIGIT</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>2.2</b></a></li>
    2828                         <li class="indline1"><tt>DQUOTE</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>2.2</b></a></li>
     2794                        <li class="indline1"><tt>date1</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>3.2.1</b></a></li>
     2795                        <li class="indline1"><tt>date2</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>3.2.1</b></a></li>
     2796                        <li class="indline1"><tt>date3</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>3.2.1</b></a></li>
     2797                        <li class="indline1"><tt>DIGIT</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>1.2</b></a></li>
     2798                        <li class="indline1"><tt>DQUOTE</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>1.2</b></a></li>
    28292799                        <li class="indline1"><tt>extension-code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.79"><b>6.1.1</b></a></li>
    28302800                        <li class="indline1"><tt>extension-method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.74"><b>5.1.1</b></a></li>
    … …  
    28342804                        <li class="indline1"><tt>general-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.70"><b>4.5</b></a></li>
    28352805                        <li class="indline1"><tt>generic-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.63"><b>4.1</b></a></li>
    2836                         <li class="indline1"><tt>HEXDIG</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>2.2</b></a></li>
     2806                        <li class="indline1"><tt>HEXDIG</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>1.2.2</b></a></li>
    28372807                        <li class="indline1"><tt>Host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.85"><b>8.4</b></a></li>
    2838                         <li class="indline1"><tt>HTAB</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>2.2</b></a></li>
    2839                         <li class="indline1"><tt>HTTP-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>3.3.1</b></a></li>
     2808                        <li class="indline1"><tt>HTAB</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>1.2</b></a></li>
     2809                        <li class="indline1"><tt>HTTP-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>3.2.1</b></a></li>
    28402810                        <li class="indline1"><tt>HTTP-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.62"><b>4.1</b></a></li>
    2841                         <li class="indline1"><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>3.1</b></a></li>
    2842                         <li class="indline1"><tt>http-URL</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>3.2.2</b></a></li>
    2843                         <li class="indline1"><tt>HTTP-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>3.1</b></a></li>
    2844                         <li class="indline1"><tt>last-chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.54"><b>3.4.1</b></a></li>
    2845                         <li class="indline1"><tt>LF</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>2.2</b></a></li>
    2846                         <li class="indline1"><tt>LWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>2.2</b></a></li>
     2811                        <li class="indline1"><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>3.1</b></a></li>
     2812                        <li class="indline1"><tt>http-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>2.1.1</b></a></li>
     2813                        <li class="indline1"><tt>HTTP-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>3.1</b></a></li>
     2814                        <li class="indline1"><tt>last-chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.54"><b>3.3.1</b></a></li>
     2815                        <li class="indline1"><tt>LF</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>1.2</b></a></li>
     2816                        <li class="indline1"><tt>LWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>1.2.2</b></a></li>
    28472817                        <li class="indline1"><tt>message-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.69"><b>4.3</b></a></li>
    28482818                        <li class="indline1"><tt>message-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.65"><b>4.2</b></a></li>
    28492819                        <li class="indline1"><tt>Method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.73"><b>5.1.1</b></a></li>
    2850                         <li class="indline1"><tt>month</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>3.3.1</b></a></li>
    2851                         <li class="indline1"><tt>obsolete-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>3.3.1</b></a></li>
    2852                         <li class="indline1"><tt>OCTET</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>2.2</b></a></li>
    2853                         <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.48"><b>3.4</b></a></li>
    2854                         <li class="indline1"><tt>path-absolute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>3.2.1</b></a></li>
    2855                         <li class="indline1"><tt>port</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>3.2.1</b></a></li>
    2856                         <li class="indline1"><tt>product</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.60"><b>3.5</b></a></li>
    2857                         <li class="indline1"><tt>product-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.61"><b>3.5</b></a></li>
     2820                        <li class="indline1"><tt>month</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>3.2.1</b></a></li>
     2821                        <li class="indline1"><tt>obsolete-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>3.2.1</b></a></li>
     2822                        <li class="indline1"><tt>OCTET</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>1.2</b></a></li>
     2823                        <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.48"><b>3.3</b></a></li>
     2824                        <li class="indline1"><tt>path-absolute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>2.1</b></a></li>
     2825                        <li class="indline1"><tt>port</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>2.1</b></a></li>
     2826                        <li class="indline1"><tt>product</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.60"><b>3.4</b></a></li>
     2827                        <li class="indline1"><tt>product-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.61"><b>3.4</b></a></li>
    28582828                        <li class="indline1"><tt>protocol-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.93"><b>8.9</b></a></li>
    28592829                        <li class="indline1"><tt>protocol-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.94"><b>8.9</b></a></li>
    28602830                        <li class="indline1"><tt>pseudonym</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.96"><b>8.9</b></a></li>
    2861                         <li class="indline1"><tt>qdtext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>2.2</b></a></li>
    2862                         <li class="indline1"><tt>query</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>3.2.1</b></a></li>
    2863                         <li class="indline1"><tt>quoted-pair</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>2.2</b></a></li>
    2864                         <li class="indline1"><tt>quoted-string</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>2.2</b></a></li>
    2865                         <li class="indline1"><tt>quoted-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>2.2</b></a></li>
     2831                        <li class="indline1"><tt>qdtext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>1.2.2</b></a></li>
     2832                        <li class="indline1"><tt>query</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>2.1</b></a></li>
     2833                        <li class="indline1"><tt>quoted-pair</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>1.2.2</b></a></li>
     2834                        <li class="indline1"><tt>quoted-string</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>1.2.2</b></a></li>
     2835                        <li class="indline1"><tt>quoted-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>1.2.2</b></a></li>
    28662836                        <li class="indline1"><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.80"><b>6.1.1</b></a></li>
    28672837                        <li class="indline1"><tt>received-by</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.95"><b>8.9</b></a></li>
    28682838                        <li class="indline1"><tt>received-protocol</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.92"><b>8.9</b></a></li>
    2869                         <li class="indline1"><tt>relativeURI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>3.2.1</b></a></li>
    28702839                        <li class="indline1"><tt>Request</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.71"><b>5</b></a></li>
    28712840                        <li class="indline1"><tt>Request-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.72"><b>5.1</b></a></li>
    28722841                        <li class="indline1"><tt>Request-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.75"><b>5.1.2</b></a></li>
    28732842                        <li class="indline1"><tt>Response</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.76"><b>6</b></a></li>
    2874                         <li class="indline1"><tt>rfc1123-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>3.3.1</b></a></li>
    2875                         <li class="indline1"><tt>rfc850-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>3.3.1</b></a></li>
    2876                         <li class="indline1"><tt>separators</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>2.2</b></a></li>
    2877                         <li class="indline1"><tt>SP</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>2.2</b></a></li>
     2843                        <li class="indline1"><tt>rfc1123-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>3.2.1</b></a></li>
     2844                        <li class="indline1"><tt>rfc850-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>3.2.1</b></a></li>
     2845                        <li class="indline1"><tt>separators</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>1.2.2</b></a></li>
     2846                        <li class="indline1"><tt>SP</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>1.2</b></a></li>
    28782847                        <li class="indline1"><tt>start-line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.64"><b>4.1</b></a></li>
    28792848                        <li class="indline1"><tt>Status-Code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.78"><b>6.1.1</b></a></li>
    28802849                        <li class="indline1"><tt>Status-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.77"><b>6.1</b></a></li>
    28812850                        <li class="indline1"><tt>t-codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.87"><b>8.5</b></a></li>
    2882                         <li class="indline1"><tt>tchar</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>2.2</b></a></li>
     2851                        <li class="indline1"><tt>tchar</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>1.2.2</b></a></li>
    28832852                        <li class="indline1"><tt>TE</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.86"><b>8.5</b></a></li>
    2884                         <li class="indline1"><tt>TEXT</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>2.2</b></a></li>
    2885                         <li class="indline1"><tt>time</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>3.3.1</b></a></li>
    2886                         <li class="indline1"><tt>token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>2.2</b></a></li>
     2853                        <li class="indline1"><tt>TEXT</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>1.2.2</b></a></li>
     2854                        <li class="indline1"><tt>time</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>3.2.1</b></a></li>
     2855                        <li class="indline1"><tt>token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>1.2.2</b></a></li>
    28872856                        <li class="indline1"><tt>Trailer</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.88"><b>8.6</b></a></li>
    2888                         <li class="indline1"><tt>trailer-part</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.59"><b>3.4.1</b></a></li>
    2889                         <li class="indline1"><tt>transfer-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.46"><b>3.4</b></a></li>
     2857                        <li class="indline1"><tt>trailer-part</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.59"><b>3.3.1</b></a></li>
     2858                        <li class="indline1"><tt>transfer-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.46"><b>3.3</b></a></li>
    28902859                        <li class="indline1"><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.89"><b>8.7</b></a></li>
    2891                         <li class="indline1"><tt>transfer-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.47"><b>3.4</b></a></li>
     2860                        <li class="indline1"><tt>transfer-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.47"><b>3.3</b></a></li>
    28922861                        <li class="indline1"><tt>Upgrade</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.90"><b>8.8</b></a></li>
    2893                         <li class="indline1"><tt>uri-host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>3.2.1</b></a></li>
    2894                         <li class="indline1"><tt>value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.50"><b>3.4</b></a></li>
     2862                        <li class="indline1"><tt>uri-host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>2.1</b></a></li>
     2863                        <li class="indline1"><tt>URI-reference</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>2.1</b></a></li>
     2864                        <li class="indline1"><tt>value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.50"><b>3.3</b></a></li>
    28952865                        <li class="indline1"><tt>Via</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.91"><b>8.9</b></a></li>
    2896                         <li class="indline1"><tt>weekday</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>3.3.1</b></a></li>
    2897                         <li class="indline1"><tt>wkday</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>3.3.1</b></a></li>
     2866                        <li class="indline1"><tt>weekday</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>3.2.1</b></a></li>
     2867                        <li class="indline1"><tt>wkday</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>3.2.1</b></a></li>
    28982868                     </ul>
    28992869                  </li>
    … …  
    29072877                        <li class="indline1">Date&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">4.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>8.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">9.1</a></li>
    29082878                        <li class="indline1">Host&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.7"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">C.1.1</a></li>
    2909                         <li class="indline1">TE&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">3.4</a>, <a class="iref" href="#rfc.xref.header.te.2">3.4.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.3">9.1</a>, <a class="iref" href="#rfc.xref.header.te.4">C.3</a></li>
    2910                         <li class="indline1">Trailer&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.4.1</a>, <a class="iref" href="#rfc.xref.header.trailer.2">4.5</a>, <a class="iref" href="#rfc.iref.h.9"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li>
    2911                         <li class="indline1">Transfer-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">4.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">4.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">4.5</a>, <a class="iref" href="#rfc.iref.h.10"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li>
     2879                        <li class="indline1">TE&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">3.3</a>, <a class="iref" href="#rfc.xref.header.te.2">3.3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.3">9.1</a>, <a class="iref" href="#rfc.xref.header.te.4">C.3</a></li>
     2880                        <li class="indline1">Trailer&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.3.1</a>, <a class="iref" href="#rfc.xref.header.trailer.2">4.5</a>, <a class="iref" href="#rfc.iref.h.9"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li>
     2881                        <li class="indline1">Transfer-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">4.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">4.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">4.5</a>, <a class="iref" href="#rfc.iref.h.10"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li>
    29122882                        <li class="indline1">Upgrade&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">4.5</a>, <a class="iref" href="#rfc.iref.h.11"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">9.1</a></li>
    29132883                        <li class="indline1">Via&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.via.1">4.5</a>, <a class="iref" href="#rfc.iref.h.12"><b>8.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">9.1</a></li>
    … …  
    29152885                  </li>
    29162886                  <li class="indline1">Host header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.6"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">C.1.1</a></li>
    2917                   <li class="indline1">http URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.1"><b>3.2.2</b></a></li>
    2918                   <li class="indline1">https URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.2">3.2.2</a></li>
     2887                  <li class="indline1">http URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.1"><b>2.1.1</b></a></li>
     2888                  <li class="indline1">https URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.2">2.1.1</a></li>
    29192889               </ul>
    29202890            </li>
    29212891            <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
    2922                   <li class="indline1">implied *LWS&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1"><b>2.1.2</b></a></li>
     2892                  <li class="indline1">implied *LWS&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1"><b>1.2.1.2</b></a></li>
    29232893                  <li class="indline1">inbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.2">E</a></li>
    2924                   <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">2.2</a>, <a class="iref" href="#ISO-8859-1"><b>12.1</b></a></li>
     2894                  <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">1.2.2</a>, <a class="iref" href="#ISO-8859-1"><b>12.1</b></a></li>
    29252895               </ul>
    29262896            </li>
    … …  
    29512921            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    29522922                  <li class="indline1"><em>Pad1995</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12.2</b></a></li>
    2953                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">3.2.1</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">4.3</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">
     2923                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">2.1</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">4.3</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">
    29542924                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">4.3</a></li>
    2955                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a></li>
    2956                         <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">2.3</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a></li>
     2925                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a></li>
     2926                        <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a></li>
    29572927                        <li class="indline1"><em>Section 8.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a></li>
    29582928                        <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">5.1.2</a></li>
    … …  
    29602930                        <li class="indline1"><em>Section 9.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
    29612931                        <li class="indline1"><em>Section 9.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.16">7.2.3</a></li>
    2962                         <li class="indline1"><em>Section 9.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">3.2.1</a></li>
     2932                        <li class="indline1"><em>Section 9.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">2.1</a></li>
    29632933                        <li class="indline1"><em>Section 10.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a></li>
    29642934                     </ul>
    29652935                  </li>
    2966                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.3</a>, <a class="iref" href="#rfc.xref.Part3.2">2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.12">A</a>, <a class="iref" href="#rfc.xref.Part3.13">C.3</a>, <a class="iref" href="#rfc.xref.Part3.14">E</a>, <a class="iref" href="#rfc.xref.Part3.15">E</a>, <a class="iref" href="#rfc.xref.Part3.16">E</a><ul class="ind">
    2967                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a></li>
    2968                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">2.2</a></li>
     2936                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.12">A</a>, <a class="iref" href="#rfc.xref.Part3.13">C.3</a>, <a class="iref" href="#rfc.xref.Part3.14">E</a>, <a class="iref" href="#rfc.xref.Part3.15">E</a>, <a class="iref" href="#rfc.xref.Part3.16">E</a><ul class="ind">
     2937                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a></li>
     2938                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li>
    29692939                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.5</a></li>
    2970                         <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li>
     2940                        <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li>
    29712941                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.14">E</a></li>
    2972                         <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">2.3</a></li>
     2942                        <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.3</a></li>
    29732943                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.15">E</a>, <a class="iref" href="#rfc.xref.Part3.16">E</a></li>
    2974                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">2.3</a></li>
    2975                         <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.3</a></li>
     2944                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li>
     2945                        <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
    29762946                     </ul>
    29772947                  </li>
    29782948                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#Part5"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">C.3</a></li>
    2979                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">C.3</a>, <a class="iref" href="#rfc.xref.Part6.9">E</a><ul class="ind">
    2980                         <li class="indline1"><em>Section 1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.9">E</a></li>
     2949                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.2</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">C.3</a>, <a class="iref" href="#rfc.xref.Part6.9">E</a><ul class="ind">
     2950                        <li class="indline1"><em>Section 1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">2.2</a>, <a class="iref" href="#rfc.xref.Part6.9">E</a></li>
    29812951                        <li class="indline1"><em>Section 16.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">4.5</a></li>
    2982                         <li class="indline1"><em>Section 16.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.2">2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a></li>
    2983                         <li class="indline1"><em>Section 16.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a></li>
     2952                        <li class="indline1"><em>Section 16.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a></li>
     2953                        <li class="indline1"><em>Section 16.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a></li>
    29842954                     </ul>
    29852955                  </li>
    … …  
    29922962                  <li class="indline1">resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.3">E</a></li>
    29932963                  <li class="indline1">response&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.2">E</a></li>
    2994                   <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">3.3.1</a>, <a class="iref" href="#RFC1123"><b>12.2</b></a></li>
     2964                  <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">3.2.1</a>, <a class="iref" href="#RFC1123"><b>12.2</b></a></li>
    29952965                  <li class="indline1"><em>RFC1305</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1305.1">8.3</a>, <a class="iref" href="#RFC1305"><b>12.2</b></a></li>
    2996                   <li class="indline1"><em>RFC1436</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1436.1">1.1</a>, <a class="iref" href="#RFC1436"><b>12.2</b></a></li>
    2997                   <li class="indline1"><em>RFC1630</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1630.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1630.2">3.2</a>, <a class="iref" href="#RFC1630"><b>12.2</b></a></li>
    2998                   <li class="indline1"><em>RFC1737</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1737.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1737.2">3.2</a>, <a class="iref" href="#RFC1737"><b>12.2</b></a></li>
    2999                   <li class="indline1"><em>RFC1738</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1738.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1738.2">3.2</a>, <a class="iref" href="#rfc.xref.RFC1738.3">3.2.1</a>, <a class="iref" href="#RFC1738"><b>12.2</b></a></li>
    3000                   <li class="indline1"><em>RFC1808</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1808.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC1808.2">3.2.1</a>, <a class="iref" href="#RFC1808"><b>12.2</b></a></li>
    3001                   <li class="indline1"><em>RFC1900</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1900.1">3.2.2</a>, <a class="iref" href="#rfc.xref.RFC1900.2">10.4</a>, <a class="iref" href="#RFC1900"><b>12.2</b></a></li>
    3002                   <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1945.1">1</a>, <a class="iref" href="#RFC1945"><b>12.2</b></a></li>
    3003                   <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2045.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.4</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.1</b></a></li>
    3004                   <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">2.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li>
     2966                  <li class="indline1"><em>RFC1436</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1436.1">1</a>, <a class="iref" href="#RFC1436"><b>12.2</b></a></li>
     2967                  <li class="indline1"><em>RFC1900</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1900.1">2.1.1</a>, <a class="iref" href="#rfc.xref.RFC1900.2">10.4</a>, <a class="iref" href="#RFC1900"><b>12.2</b></a></li>
     2968                  <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#RFC1945"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">C</a></li>
     2969                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.3</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.1</b></a></li>
     2970                  <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">1.2.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li>
    30052971                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.5">11</a>, <a class="iref" href="#RFC2068"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.6">C</a>, <a class="iref" href="#rfc.xref.RFC2068.7">C.2</a><ul class="ind">
    30062972                        <li class="indline1"><em>Section 19.7.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.6">C</a></li>
    … …  
    30082974                  </li>
    30092975                  <li class="indline1"><em>RFC2109</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2109.1">4.2</a>, <a class="iref" href="#RFC2109"><b>12.2</b></a></li>
    3010                   <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">C.3</a></li>
     2976                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">C.3</a></li>
    30112977                  <li class="indline1"><em>RFC2145</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2145.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2145.2">3.1</a>, <a class="iref" href="#RFC2145"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2145.3">C.3</a></li>
    3012                   <li class="indline1"><em>RFC2324</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2324.1">1.1</a>, <a class="iref" href="#RFC2324"><b>12.2</b></a></li>
    3013                   <li class="indline1"><em>RFC2396</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.2">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.3">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.4">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.5">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.6">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.7">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.8">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.9">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.10">3.2.3</a>, <a class="iref" href="#rfc.xref.RFC2396.11">5.1.2</a>, <a class="iref" href="#RFC2396"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.RFC2396.12">C.4</a><ul class="ind">
    3014                         <li class="indline1"><em>Section 2.4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.11">5.1.2</a></li>
    3015                         <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.10">3.2.3</a></li>
    3016                         <li class="indline1"><em>Section 3.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.6">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.9">3.2.1</a></li>
    3017                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.3">3.2.1</a></li>
    3018                         <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.7">3.2.1</a></li>
    3019                         <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.2">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.5">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.12">C.4</a></li>
    3020                         <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.4">3.2.1</a></li>
    3021                         <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.8">3.2.1</a></li>
     2978                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">11</a>, <a class="iref" href="#RFC2616"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">D.1</a></li>
     2979                  <li class="indline1"><em>RFC2818</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2818.1">2.1.1</a>, <a class="iref" href="#RFC2818"><b>12.2</b></a></li>
     2980                  <li class="indline1"><em>RFC2965</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2965.1">4.2</a>, <a class="iref" href="#RFC2965"><b>12.2</b></a></li>
     2981                  <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">9.1</a>, <a class="iref" href="#RFC3864"><b>12.2</b></a></li>
     2982                  <li class="indline1"><em>RFC3977</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3977.1">1</a>, <a class="iref" href="#RFC3977"><b>12.2</b></a></li>
     2983                  <li class="indline1"><em>RFC3986</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.13">5.1.2</a>, <a class="iref" href="#RFC3986"><b>12.1</b></a><ul class="ind">
     2984                        <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.12">2.1.2</a></li>
     2985                        <li class="indline1"><em>Section 2.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.13">5.1.2</a></li>
     2986                        <li class="indline1"><em>Section 3.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.9">2.1</a></li>
     2987                        <li class="indline1"><em>Section 3.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.11">2.1</a></li>
     2988                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.5">2.1</a></li>
     2989                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.7">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.1</a></li>
     2990                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.10">2.1</a></li>
     2991                        <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.6">2.1</a></li>
     2992                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.4">2.1</a></li>
    30222993                     </ul>
    30232994                  </li>
    3024                   <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#rfc.xref.RFC2616.3">11</a>, <a class="iref" href="#RFC2616"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.4">D.1</a></li>
    3025                   <li class="indline1"><em>RFC2818</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2818.1">3.2.2</a>, <a class="iref" href="#RFC2818"><b>12.2</b></a></li>
    3026                   <li class="indline1"><em>RFC2821</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2821.1">1.1</a>, <a class="iref" href="#RFC2821"><b>12.2</b></a></li>
    3027                   <li class="indline1"><em>RFC2965</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2965.1">4.2</a>, <a class="iref" href="#RFC2965"><b>12.2</b></a></li>
    3028                   <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">9.1</a>, <a class="iref" href="#RFC3864"><b>12.2</b></a></li>
    3029                   <li class="indline1"><em>RFC3977</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3977.1">1.1</a>, <a class="iref" href="#RFC3977"><b>12.2</b></a></li>
    30302995                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4288.1">9.3</a>, <a class="iref" href="#RFC4288"><b>12.2</b></a></li>
    30312996                  <li class="indline1"><em>RFC4395</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4395.1">9.2</a>, <a class="iref" href="#RFC4395"><b>12.2</b></a></li>
    3032                   <li class="indline1"><em>RFC5234</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">2.1</a>, <a class="iref" href="#rfc.xref.RFC5234.2">11</a>, <a class="iref" href="#RFC5234"><b>12.1</b></a></li>
    3033                   <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">4.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind">
     2997                  <li class="indline1"><em>RFC5234</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">1.2</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.2.1</a>, <a class="iref" href="#rfc.xref.RFC5234.3">11</a>, <a class="iref" href="#RFC5234"><b>12.1</b></a></li>
     2998                  <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.1">1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">4.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind">
    30342999                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.3">4.2</a></li>
    30353000                        <li class="indline1"><em>Section 3.6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5322.4">8.3</a></li>
    … …  
    30373002                     </ul>
    30383003                  </li>
    3039                   <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.1">3.3.1</a>, <a class="iref" href="#RFC822"><b>12.2</b></a></li>
    3040                   <li class="indline1"><em>RFC959</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC959.1">1.1</a>, <a class="iref" href="#RFC959"><b>12.2</b></a></li>
     3004                  <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.1">3.2.1</a>, <a class="iref" href="#RFC822"><b>12.2</b></a></li>
     3005                  <li class="indline1"><em>RFC959</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC959.1">1</a>, <a class="iref" href="#RFC959"><b>12.2</b></a></li>
    30413006               </ul>
    30423007            </li>
    … …  
    30473012            </li>
    30483013            <li class="indline0"><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul class="ind">
    3049                   <li class="indline1">TE header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">3.4</a>, <a class="iref" href="#rfc.xref.header.te.2">3.4.1</a>, <a class="iref" href="#rfc.iref.t.1"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.3">9.1</a>, <a class="iref" href="#rfc.xref.header.te.4">C.3</a></li>
     3014                  <li class="indline1">TE header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">3.3</a>, <a class="iref" href="#rfc.xref.header.te.2">3.3.1</a>, <a class="iref" href="#rfc.iref.t.1"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.3">9.1</a>, <a class="iref" href="#rfc.xref.header.te.4">C.3</a></li>
    30503015                  <li class="indline1"><em>Tou1998</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Tou1998.1">7.1.1</a>, <a class="iref" href="#Tou1998"><b>12.2</b></a></li>
    3051                   <li class="indline1">Trailer header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.4.1</a>, <a class="iref" href="#rfc.xref.header.trailer.2">4.5</a>, <a class="iref" href="#rfc.iref.t.2"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li>
    3052                   <li class="indline1">Transfer-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">4.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">4.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">4.5</a>, <a class="iref" href="#rfc.iref.t.3"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li>
     3016                  <li class="indline1">Trailer header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.3.1</a>, <a class="iref" href="#rfc.xref.header.trailer.2">4.5</a>, <a class="iref" href="#rfc.iref.t.2"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li>
     3017                  <li class="indline1">Transfer-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">4.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">4.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">4.5</a>, <a class="iref" href="#rfc.iref.t.3"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li>
    30533018                  <li class="indline1">tunnel&nbsp;&nbsp;<a class="iref" href="#rfc.iref.t.4">E</a></li>
    30543019               </ul>
    … …  
    30593024                  <li class="indline1">URI scheme&nbsp;&nbsp;
    30603025                     <ul class="ind">
    3061                         <li class="indline1">http&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.1"><b>3.2.2</b></a></li>
    3062                         <li class="indline1">https&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.2">3.2.2</a></li>
     3026                        <li class="indline1">http&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.1"><b>2.1.1</b></a></li>
     3027                        <li class="indline1">https&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.2">2.1.1</a></li>
    30633028                     </ul>
    30643029                  </li>
    3065                   <li class="indline1"><em>USASCII</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.USASCII.1">2.2</a>, <a class="iref" href="#USASCII"><b>12.1</b></a></li>
     3030                  <li class="indline1"><em>USASCII</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#USASCII"><b>12.1</b></a></li>
    30663031                  <li class="indline1">user agent&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.4">E</a></li>
    30673032               </ul>
    … …  
    30733038            </li>
    30743039            <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind">
    3075                   <li class="indline1"><em>WAIS</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.WAIS.1">1.1</a>, <a class="iref" href="#WAIS"><b>12.2</b></a></li>
     3040                  <li class="indline1"><em>WAIS</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.WAIS.1">1</a>, <a class="iref" href="#WAIS"><b>12.2</b></a></li>
    30763041               </ul>
    30773042            </li>
Note: See TracChangeset for help on using the changeset viewer.