Ignore:
Timestamp:
08/12/12 08:20:18 (8 years ago)
Author:
fielding@…
Message:

update generated abnf and html; done for the night

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2035 r2044  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 10, 2013";
     451       content: "Expires June 11, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-07">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-08">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">December 7, 2012</td>
     522               <td class="right">December 8, 2012</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: June 10, 2013</td>
     525               <td class="left">Expires: June 11, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on June 10, 2013.</p>
     553      <p>This Internet-Draft will expire on June 11, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    638638               <li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a><ul>
    639639                     <li><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
    640                      <li><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#message.transformation">Transformation</a></li>
     640                     <li><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#message.transformations">Transformations</a></li>
    641641                  </ul>
    642642               </li>
    … …  
    660660               <li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    661661               <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li>
    662                <li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registrations</a><ul>
     662               <li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul>
    663663                     <li><a href="#rfc.section.7.3.1">7.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li>
    664664                     <li><a href="#rfc.section.7.3.2">7.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li>
    … …  
    666666               </li>
    667667               <li><a href="#rfc.section.7.4">7.4</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
    668                <li><a href="#rfc.section.7.5">7.5</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Transfer Coding Registrations</a></li>
     668               <li><a href="#rfc.section.7.5">7.5</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Transfer Coding Registration</a></li>
    669669               <li><a href="#rfc.section.7.6">7.6</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
    670670               <li><a href="#rfc.section.7.7">7.7</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
    … …  
    10101010      <div id="rfc.iref.r.5"></div>
    10111011      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    1012       <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resource" title="Resource">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
     1012      <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
    10131013      </p>
    10141014      <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",
    … …  
    10781078      </p>
    10791079      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    1080 </pre><p id="rfc.section.2.7.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP
    1081          or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    1082       </p>
    1083       <p id="rfc.section.2.7.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
     1080</pre><p id="rfc.section.2.7.2.p.4">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
    10841081         indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered
    10851082         to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the
    10861083         Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains.
    10871084      </p>
    1088       <p id="rfc.section.2.7.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.2"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
     1085      <p id="rfc.section.2.7.2.p.5">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.2"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
    10891086      </p>
    10901087      <h3 id="rfc.section.2.7.3"><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">http and https URI Normalization and Comparison</a></h3>
    … …  
    10921089         the algorithm defined in <a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-6">Section 6</a>, using the defaults described above for each scheme.
    10931090      </p>
    1094       <p id="rfc.section.2.7.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty
    1095          path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme
    1096          and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.
    1097          Characters other than those in the "reserved" set are equivalent to their percent-encoded octets (see <a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>): the normal form is to not encode them.
     1091      <p id="rfc.section.2.7.3.p.2">If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. When not being used
     1092         in absolute form as the request target of an OPTIONS request, an empty path component is equivalent to an absolute path of
     1093         "/", so the normal form is to provide a path of "/" instead. The scheme and host are case-insensitive and normally provided
     1094         in lowercase; all other components are compared in a case-sensitive manner. Characters other than those in the "reserved"
     1095         set are equivalent to their percent-encoded octets (see <a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>): the normal form is to not encode them.
    10981096      </p>
    10991097      <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p>
    … …  
    12601258</pre><h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="field.parsing" href="#field.parsing">Field Parsing</a></h3>
    12611259      <p id="rfc.section.3.2.4.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace
    1262          have led to security vulnerabilities in request routing and response handling. Any received request message that contains
    1263          whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream.
     1260         have led to security vulnerabilities in request routing and response handling. A server <em class="bcp14">MUST</em> reject any received request message that contains whitespace between a header field-name and colon with a response code of <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>. A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream.
    12641261      </p>
    12651262      <p id="rfc.section.3.2.4.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading
    … …  
    12691266      <p id="rfc.section.3.2.4.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
    12701267         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    1271          (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the
    1272          message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets
     1268         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>). Senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the
     1269         message is intended for packaging within the message/http media type. Recipients <em class="bcp14">MUST</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets
    12731270         (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream.
    12741271      </p>
    … …  
    14561453         </li>
    14571454         <li>
    1458             <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the message body length in octets. If the actual number of octets sent in the message is less
    1459                than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in
    1460                the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection
    1461                and the connection has been closed by the server.
     1455            <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient
     1456               times out before the indicated number of octets are received, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and close the connection.
    14621457            </p>
    14631458         </li>
    … …  
    14851480         specific user configuration or by remembering the version of a prior received response.
    14861481      </p>
     1482      <p id="rfc.section.3.3.3.p.7">If the final response to the last request on a connection has been completely received and there remains additional data to
     1483         read, a user agent <em class="bcp14">MAY</em> discard the remaining data or attempt to determine if that data belongs as part of the prior response body, which might be
     1484         the case if the prior message's Content-Length value is incorrect. A client <em class="bcp14">MUST NOT</em> process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning.
     1485      </p>
    14871486      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2>
    14881487      <p id="rfc.section.3.4.p.1">A server that receives an incomplete request message, usually due to a canceled request or a triggered time-out exception, <em class="bcp14">MAY</em> send an error response prior to closing the connection.
    14891488      </p>
    14901489      <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding
    1491          a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     1490         a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    14921491      </p>
    14931492      <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header block (before the empty line is received) and the status code might rely
    … …  
    16871686         semantics and, if so, where that request is to be directed.
    16881687      </p>
    1689       <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), then the request is usually directed to the cache first.
     1688      <p id="rfc.section.5.2.p.2">If the client has a response cache and the request semantics can be satisfied by a cache (<a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), then the request is usually directed to the cache first.
    16901689      </p>
    16911690      <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy
    … …  
    18831882         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    18841883      </p>
    1885       <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a id="message.transformation" href="#message.transformation">Transformation</a></h3>
    1886       <p id="rfc.section.5.7.2.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
    1887       </p>
    1888       <p id="rfc.section.5.7.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
     1884      <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a id="message.transformations" href="#message.transformations">Transformations</a></h3>
     1885      <p id="rfc.section.5.7.2.p.1">Some intermediaries include features for transforming messages and their payloads. A transforming proxy might, for example,
     1886         convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational
     1887         problems might occur when these transformations are applied to payloads intended for critical applications, such as medical
     1888         imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the
     1889         payload received is identical to the original.
     1890      </p>
     1891      <p id="rfc.section.5.7.2.p.2">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
     1892      </p>
     1893      <p id="rfc.section.5.7.2.p.3">A proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
    18891894         except as noted above to replace an empty path with "/" or "*".
    18901895      </p>
    1891       <p id="rfc.section.5.7.2.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    1892       </p>
    1893       <p id="rfc.section.5.7.2.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
    1894          selected representation.
    1895       </p>
    1896       <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
    1897       </p>
    1898       <ul>
    1899          <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    1900          </li>
    1901          <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    1902          </li>
    1903          <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)
    1904          </li>
    1905          <li><a href="p4-conditional.html#header.etag" class="smpl">ETag</a> (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>)
    1906          </li>
    1907          <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>)
    1908          </li>
    1909          <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    1910          </li>
    1911       </ul>
    1912       <p id="rfc.section.5.7.2.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field.
    1913       </p>
    1914       <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive:
    1915       </p>
    1916       <ul>
    1917          <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    1918          </li>
    1919          <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>)
    1920          </li>
    1921          <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    1922          </li>
    1923       </ul>
    1924       <p id="rfc.section.5.7.2.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    1925       </p>
    1926       <div class="note" id="rfc.section.5.7.2.p.9">
    1927          <p> <b>Warning:</b> Unnecessary modification of header fields might cause authentication failures if stronger authentication mechanisms are introduced
    1928             in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
    1929          </p>
    1930       </div>
     1896      <p id="rfc.section.5.7.2.p.4">A proxy <em class="bcp14">MUST NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
     1897         selected representation. A proxy <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     1898      </p>
     1899      <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A transforming proxy <em class="bcp14">MUST</em> preserve the payload of a message that contains the no-transform cache-control directive.
     1900      </p>
     1901      <p id="rfc.section.5.7.2.p.6">A transforming proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain the no-transform cache-control directive; if the payload is transformed,
     1902         the transforming proxy <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) header field if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     1903      </p>
    19311904      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connection.management" href="#connection.management">Connection Management</a></h1>
    19321905      <p id="rfc.section.6.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable
    … …  
    19491922         avoid confusing downstream recipients, a proxy or gateway <em class="bcp14">MUST</em> remove or replace any received connection options before forwarding the message.
    19501923      </p>
    1951       <p id="rfc.section.6.1.p.2">When a header field is used to supply control information for or about the current connection, the sender <em class="bcp14">SHOULD</em> list the corresponding field-name within the "Connection" header field. A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove
     1924      <p id="rfc.section.6.1.p.2">When a header field aside from Connection is used to supply control information for or about the current connection, the sender <em class="bcp14">MUST</em> list the corresponding field-name within the "Connection" header field. A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove
    19521925         any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field
    19531926         itself (or replace it with the intermediary's own connection options for the forwarded message).
    … …  
    19631936</pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p>
    19641937      <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
    1965          in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     1938         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    19661939      </p>
    19671940      <p id="rfc.section.6.1.p.8">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
    … …  
    19811954      </p>
    19821955      <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
    1983 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section&nbsp;6.6</a>).
     1956</pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">MUST</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section&nbsp;6.6</a>).
    19841957      </p>
    19851958      <p id="rfc.section.6.1.p.13">A client that does not support <a href="#persistent.connections" class="smpl">persistent connections</a>  <em class="bcp14">MUST</em> send the "close" connection option in every request message.
    … …  
    20221995      <p id="rfc.section.6.3.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    20231996      </p>
    2024       <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     1997      <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    20251998         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    20261999      </p>
    … …  
    20282001      <p id="rfc.section.6.3.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover
    20292002         from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence
    2030          is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding
     2003         is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding
    20312004         of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails.
    20322005      </p>
    … …  
    21212094      </p>
    21222095      <p id="rfc.section.6.7.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used
    2123          to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2096         to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    21242097      </p>
    21252098      <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    … …  
    22592232         </table>
    22602233      </div>
    2261       <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
     2234      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registration</a></h2>
    22622235      <p id="rfc.section.7.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following
    22632236         is to be registered with IANA (see <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>).
    … …  
    23822355         <li>Pointer to specification text</li>
    23832356      </ul>
    2384       <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2357      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    23852358      </p>
    23862359      <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. Use of program names for the identification of encoding
    … …  
    23892362      <p id="rfc.section.7.4.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    23902363      </p>
    2391       <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registrations</a></h2>
     2364      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registration</a></h2>
    23922365      <p id="rfc.section.7.5.p.1">The HTTP Transfer Coding Registry shall be updated with the registrations below:</p>
    23932366      <div id="rfc.table.2">
    … …  
    25372510         that most implementations will choose substantially higher limits.
    25382511      </p>
    2539       <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2512      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    25402513      </p>
    25412514      <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
    … …  
    25582531      </p>
    25592532      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2560       <p id="rfc.section.9.p.1">This edition of HTTP/1.1 builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.4">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari
     2533      <p id="rfc.section.9.p.1">This edition of HTTP/1.1 builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.4">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.3">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari
    25612534         Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, and Paul J. Leach. Mark Nottingham
    25622535         oversaw this effort as working group chair.
    … …  
    25972570         A. Shaw, and Zhong Yu.
    25982571      </p>
    2599       <p id="rfc.section.9.p.4">See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions.
     2572      <p id="rfc.section.9.p.4">See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions.
    26002573      </p>
    26012574      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
    … …  
    32653238            </li>
    32663239            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3267                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">5.7.2</a>, <a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a>, <a href="#rfc.xref.Part2.30">6.7</a>, <a href="#rfc.xref.Part2.31">7.4</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#rfc.xref.Part2.33">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3240                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.7</a>, <a href="#rfc.xref.Part2.26">7.4</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#rfc.xref.Part2.28">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    32683241                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    3269                         <li><em>Section 3.1.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">5.7.2</a></li>
    3270                         <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.31">7.4</a></li>
    3271                         <li><em>Section 3.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.7.2</a></li>
    3272                         <li><em>Section 3.1.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.7.2</a></li>
     3242                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.26">7.4</a></li>
    32733243                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.7.2</a></li>
    32743244                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3275                         <li><em>Section 5.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a></li>
     3245                        <li><em>Section 5.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a></li>
    32763246                        <li><em>Section 5.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li>
    32773247                        <li><em>Section 5.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li>
    … …  
    32813251                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.6</a></li>
    32823252                        <li><em>Section 7.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    3283                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">6.7</a></li>
    3284                         <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.33">8.6</a></li>
    3285                         <li><em>Section 7.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.32">8.6</a></li>
     3253                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.7</a></li>
     3254                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">8.6</a></li>
     3255                        <li><em>Section 7.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.6</a></li>
    32863256                        <li><em>Section 8.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    32873257                        <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.2</a></li>
    3288                         <li><em>Section 8.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.7.2</a></li>
    3289                         <li><em>Section 8.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.7.2</a></li>
    32903258                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
    32913259                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    32923260                     </ul>
    32933261                  </li>
    3294                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.7.2</a>, <a href="#rfc.xref.Part4.5">5.7.2</a>, <a href="#Part4"><b>10.1</b></a><ul>
    3295                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.7.2</a></li>
    3296                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.7.2</a></li>
     3262                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul>
    32973263                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li>
    32983264                     </ul>
    32993265                  </li>
    3300                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.7.2</a>, <a href="#Part5"><b>10.1</b></a><ul>
    3301                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">5.7.2</a></li>
    3302                      </ul>
    3303                   </li>
    3304                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.7.2</a>, <a href="#rfc.xref.Part6.8">5.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
     3266                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#Part5"><b>10.1</b></a></li>
     3267                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
    33053268                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.4</a></li>
    3306                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">3.4</a></li>
    3307                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li>
    3308                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.7">5.7.2</a></li>
    3309                         <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.8">5.7.2</a></li>
     3269                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
     3270                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.7">6.1</a></li>
     3271                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.6">5.7.2</a></li>
    33103272                     </ul>
    33113273                  </li>
    … …  
    33373299                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li>
    33383300                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">1</a>, <a href="#rfc.xref.RFC2145.2">9</a>, <a href="#RFC2145"><b>10.2</b></a></li>
    3339                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">5.7.2</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a><ul>
    3340                         <li><em>Section 14.15</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.3">5.7.2</a></li>
    3341                         <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">9</a></li>
     3301                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">9</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#RFC2616"><b>10.2</b></a><ul>
     3302                        <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.4">9</a></li>
    33423303                     </ul>
    33433304                  </li>
Note: See TracChangeset for help on using the changeset viewer.