Ignore:
Timestamp:
Nov 21, 2008, 9:39:20 AM (11 years ago)
Author:
julian.reschke@…
Message:

reorganize ABNF introductions to match Part1 (related to #36)

File:
1 edited

Legend:

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

    r423 r424  
    737737      <div id="rule.CRLF">
    738738         <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
    739             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>.
     739            in <a href="p3-payload.html#media.types" title="Media Types">Section 2.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>.
    740740         </p>
    741741      </div>
     
    786786</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>
    787787      <p id="rfc.section.1.2.3.p.1">The ABNF rules below are defined in other parts:</p>
    788       <div id="rfc.figure.u.9"></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;
    789   <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;
    790 </pre><div id="rfc.figure.u.10"></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;
    791   <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;
    792   <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;
    793 </pre><div id="rfc.figure.u.11"></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;
    794   <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;
    795   <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;
     788      <div id="rfc.figure.u.9"></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 3</a>&gt;
     789  <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 5</a>&gt;
     790</pre><div id="rfc.figure.u.10"></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 5.1</a>&gt;
     791  <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 3.2</a>&gt;
     792  <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 3.1</a>&gt;
     793</pre><div id="rfc.figure.u.11"></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 15.4</a>&gt;
     794  <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 15.4</a>&gt;
     795  <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 15.6</a>&gt;
    796796</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP architecture</a></h1>
    797797      <p id="rfc.section.2.p.1">HTTP was created with a specific architecture in mind, the World Wide Web, and has evolved over time to support the scalability
     
    10521052      </p>
    10531053      <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
    1054          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>).
    1055       </p>
    1056       <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>).
     1054         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 2.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>).
     1055      </p>
     1056      <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 2.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>).
    10571057      </p>
    10581058      <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.
     
    12121212      <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>
    12131213      <p id="rfc.section.4.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    1214          in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length
     1214         in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length
    12151215         and a method that does not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented
    12161216         the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response.
     
    12731273         to the entity being transferred. These header fields apply only to the message being transmitted.
    12741274      </p>
    1275       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.71"></span>  <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a>            ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a>
     1275      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.71"></span>  <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a>            ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 15.2</a>
    12761276                 / <a href="#header.connection" class="smpl">Connection</a>               ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>
    12771277                 / <a href="#header.date" class="smpl">Date</a>                     ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a>
    1278                  / <a href="#abnf.dependencies" class="smpl">Pragma</a>                   ; <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>
     1278                 / <a href="#abnf.dependencies" class="smpl">Pragma</a>                   ; <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 15.4</a>
    12791279                 / <a href="#header.trailer" class="smpl">Trailer</a>                  ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.6</a>
    12801280                 / <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>        ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.7</a>
    12811281                 / <a href="#header.upgrade" class="smpl">Upgrade</a>                  ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.8</a>
    12821282                 / <a href="#header.via" class="smpl">Via</a>                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.9</a>
    1283                  / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>
     1283                 / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 15.6</a>
    12841284</pre><p id="rfc.section.4.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    12851285         or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize
     
    12921292      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.72"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;5.1</a>
    12931293                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1294                    / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.4"><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>
    1295                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.8"><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>
     1294                   / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.4"><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 3</a>
     1295                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.8"><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 3.1</a>
    12961296                  <a href="#core.rules" class="smpl">CRLF</a>
    12971297                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
     
    13241324</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.
    13251325      </p>
    1326       <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.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1326      <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 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13271327      </p>
    13281328      <p id="rfc.section.5.1.2.p.9">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the
     
    13571357      </dl>
    13581358      <p id="rfc.section.5.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (Request-target too Long) status if the received
    1359          request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1359         request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13601360      </p>
    13611361      <p id="rfc.section.5.1.2.p.19">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs.
     
    13861386      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#response" class="smpl">Response</a>      = <a href="#status-line" class="smpl">Status-Line</a>               ; <a href="#status-line" title="Status-Line">Section&nbsp;6.1</a>
    13871387                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1388                    / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.7"><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>
    1389                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.9"><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>
     1388                   / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.7"><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 5</a>
     1389                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.9"><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 3.1</a>
    13901390                  <a href="#core.rules" class="smpl">CRLF</a>
    13911391                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
     
    13981398</pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    13991399      <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
    1400          are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
     1400         are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
    14011401         out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
    14021402         client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
     
    14681468      <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    14691469      </p>
    1470       <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     1470      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    14711471         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request.
    14721472      </p>
     
    14931493      </p>
    14941494      <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    1495          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     1495         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    14961496         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    14971497      </p>
     
    15111511      </p>
    15121512      <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>
    1513       <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     1513      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    15141514         to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
    15151515         be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
     
    15181518      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    15191519      <ul>
    1520          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    1521          </li>
    1522          <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     1520         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     1521         </li>
     1522         <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    15231523         </li>
    15241524      </ul>
     
    15641564         <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
    15651565            an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding
    1566             of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1566            of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    15671567         </li>
    15681568      </ul>
     
    17361736         <li>
    17371737            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    1738                is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")
     1738               is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 2.4</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")
    17391739            </p>
    17401740         </li>
     
    25172517      </p>
    25182518      <dl class="empty">
    2519          <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).
     2519         <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).
    25202520         </dd>
    25212521      </dl>
     
    25242524      <dl class="empty">
    25252525         <dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of
    2526             entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     2526            entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 3</a> of <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    25272527         </dd>
    25282528      </dl>
     
    25852585      </p>
    25862586      <dl class="empty">
    2587          <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.15"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.
     2587         <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.15"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.
    25882588         </dd>
    25892589      </dl>
     
    26262626      <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    26272627      <div id="rfc.figure.u.64"></div> <pre class="inline">BWS = OWS
    2628 Cache-Control = &lt;Cache-Control, defined in [Part6], Section 16.4&gt;
     2628Cache-Control = &lt;Cache-Control, defined in [Part6], Section 15.4&gt;
    26292629Chunked-Body = *chunk last-chunk trailer-part CRLF
    26302630Connection = "Connection:" OWS Connection-v
     
    26442644Method = token
    26452645OWS = *( [ obs-fold ] WSP )
    2646 Pragma = &lt;Pragma, defined in [Part6], Section 16.4&gt;
     2646Pragma = &lt;Pragma, defined in [Part6], Section 15.4&gt;
    26472647RWS = 1*( [ obs-fold ] WSP )
    26482648Reason-Phrase = *( WSP / VCHAR / obs-text )
     
    26692669 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
    26702670 ] )
    2671 Warning = &lt;Warning, defined in [Part6], Section 16.6&gt;
     2671Warning = &lt;Warning, defined in [Part6], Section 15.6&gt;
    26722672absolute-URI = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;
    2673 accept-params = &lt;accept-params, defined in [Part3], Section 6.1&gt;
     2673accept-params = &lt;accept-params, defined in [Part3], Section 5.1&gt;
    26742674asctime-date = wkday SP date3 SP time SP 4DIGIT
    26752675attribute = token
     
    26872687date2 = 2DIGIT "-" month "-" 2DIGIT
    26882688date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
    2689 entity-body = &lt;entity-body, defined in [Part3], Section 4.2&gt;
    2690 entity-header = &lt;entity-header, defined in [Part3], Section 4.1&gt;
     2689entity-body = &lt;entity-body, defined in [Part3], Section 3.2&gt;
     2690entity-header = &lt;entity-header, defined in [Part3], Section 3.1&gt;
    26912691field-content = *( WSP / VCHAR / obs-text )
    26922692field-name = token
     
    27322732received-protocol = [ protocol-name "/" ] protocol-version
    27332733relative-part = &lt;relative-part, defined in [RFC3986], Section 4.2&gt;
    2734 request-header = &lt;request-header, defined in [Part2], Section 4&gt;
     2734request-header = &lt;request-header, defined in [Part2], Section 3&gt;
    27352735request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
    27362736 / authority
    2737 response-header = &lt;response-header, defined in [Part2], Section 6&gt;
     2737response-header = &lt;response-header, defined in [Part2], Section 5&gt;
    27382738rfc1123-date = wkday "," SP date1 SP time SP GMT
    27392739rfc850-date = weekday "," SP date2 SP time SP GMT
     
    31713171                  <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>
    31723172                  <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">4.3</a>, <a class="iref" href="#rfc.xref.Part2.4">5</a>, <a class="iref" href="#rfc.xref.Part2.5">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a>, <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</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="#Part2"><b>12.1</b></a><ul class="ind">
    3173                         <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">4.3</a></li>
    3174                         <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">5</a></li>
    3175                         <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.7">6</a></li>
    3176                         <li class="indline1"><em>Section 8.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a></li>
    3177                         <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">5.1.2</a></li>
    3178                         <li class="indline1"><em>Section 9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li>
    3179                         <li class="indline1"><em>Section 9.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>
    3180                         <li class="indline1"><em>Section 9.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li>
    3181                         <li class="indline1"><em>Section 9.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li>
    3182                         <li class="indline1"><em>Section 10.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
     3173                        <li class="indline1"><em>Section 2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">4.3</a></li>
     3174                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">5</a></li>
     3175                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a></li>
     3176                        <li class="indline1"><em>Section 7.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a></li>
     3177                        <li class="indline1"><em>Section 7.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">5.1.2</a></li>
     3178                        <li class="indline1"><em>Section 8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li>
     3179                        <li class="indline1"><em>Section 8.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>
     3180                        <li class="indline1"><em>Section 8.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li>
     3181                        <li class="indline1"><em>Section 8.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li>
     3182                        <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
    31833183                     </ul>
    31843184                  </li>
    31853185                  <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">5</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.11">A</a>, <a class="iref" href="#rfc.xref.Part3.12">B.3</a>, <a class="iref" href="#rfc.xref.Part3.13">C</a>, <a class="iref" href="#rfc.xref.Part3.14">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a><ul class="ind">
    3186                         <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>
    3187                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li>
    3188                         <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">8.5</a></li>
    3189                         <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">5</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a></li>
    3190                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.14">C</a></li>
    3191                         <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.3</a></li>
    3192                         <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.13">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a></li>
    3193                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li>
     3186                        <li class="indline1"><em>Section 2.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>
     3187                        <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li>
     3188                        <li class="indline1"><em>Section 2.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">8.5</a></li>
     3189                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">5</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a></li>
     3190                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.14">C</a></li>
     3191                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.3</a></li>
     3192                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.13">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a></li>
     3193                        <li class="indline1"><em>Section 5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li>
    31943194                        <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
    31953195                     </ul>
     
    31983198                  <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">B.3</a>, <a class="iref" href="#rfc.xref.Part6.9">C</a><ul class="ind">
    31993199                        <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">C</a></li>
    3200                         <li class="indline1"><em>Section 16.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">4.5</a></li>
    3201                         <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>
    3202                         <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>
     3200                        <li class="indline1"><em>Section 15.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">4.5</a></li>
     3201                        <li class="indline1"><em>Section 15.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>
     3202                        <li class="indline1"><em>Section 15.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>
    32033203                     </ul>
    32043204                  </li>
Note: See TracChangeset for help on using the changeset viewer.