Changeset 2580


Ignore:
Timestamp:
24/01/14 22:10:35 (6 years ago)
Author:
fielding@…
Message:

(design) Strengthen the requirements on MUST NOT send certain fields in a chunked trailer and define how a recipient is expected to process received trailer fields; Lower expectations that the fields will be processed by all recipients; addresses #551

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

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

    r2569 r2580  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 27, 2014";
     450       content: "Expires July 28, 2014";
    451451  }
    452452  @bottom-right {
    … …  
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2014-01-23">
     492      <meta name="dct.issued" scheme="ISO8601" content="2014-01-24">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    519519            <tr>
    520520               <td class="left">Intended status: Standards Track</td>
    521                <td class="right">January 23, 2014</td>
     521               <td class="right">January 24, 2014</td>
    522522            </tr>
    523523            <tr>
    524                <td class="left">Expires: July 27, 2014</td>
     524               <td class="left">Expires: July 28, 2014</td>
    525525               <td class="right"></td>
    526526            </tr>
    … …  
    551551            in progress”.
    552552         </p>
    553          <p>This Internet-Draft will expire on July 27, 2014.</p>
     553         <p>This Internet-Draft will expire on July 28, 2014.</p>
    554554      </div>
    555555      <div id="rfc.copyrightnotice">
    … …  
    16581658               message.
    16591659            </p>
    1660             <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span>  <a href="#chunked.encoding" class="smpl">chunked-body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     1660            <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span>  <a href="#chunked.encoding" class="smpl">chunked-body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
    16611661                   <a href="#chunked.encoding" class="smpl">last-chunk</a>
    16621662                   <a href="#chunked.trailer.part" class="smpl">trailer-part</a>
    … …  
    16801680                  of message body size.
    16811681               </p>
    1682                <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span>  <a href="#chunked.extension" class="smpl">chunk-ext</a>      = *( ";" <a href="#chunked.extension" class="smpl">chunk-ext-name</a> [ "=" <a href="#chunked.extension" class="smpl">chunk-ext-val</a> ] )
     1682               <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span>  <a href="#chunked.extension" class="smpl">chunk-ext</a>      = *( ";" <a href="#chunked.extension" class="smpl">chunk-ext-name</a> [ "=" <a href="#chunked.extension" class="smpl">chunk-ext-val</a> ] )
    16831683
    16841684  <a href="#chunked.extension" class="smpl">chunk-ext-name</a> = <a href="#rule.token.separators" class="smpl">token</a>
    … …  
    17011701                  header section.
    17021702               </p>
    1703                <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#chunked.trailer.part" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
    1704 </pre><p id="rfc.section.4.1.2.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field which needs to be known by the recipient before it can begin processing the message
    1705                   body. For example, most recipients need to know the values of <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> and <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> in order to select a content handler, so placing those fields in a trailer would force the recipient to buffer the entire
    1706                   body before it could begin, greatly increasing user-perceived latency and defeating one of the main advantages of using chunked
    1707                   to send data streams of unknown length. A sender <em class="bcp14">MUST NOT</em> generate a trailer containing a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, or <a href="#header.trailer" class="smpl">Trailer</a> field.
    1708                </p>
    1709                <p id="rfc.section.4.1.2.p.4">A server <em class="bcp14">MUST</em> generate an empty trailer with the chunked transfer coding unless at least one of the following is true:
    1710                </p>
    1711                <ol>
    1712                   <li>the request included a <a href="#header.te" class="smpl">TE</a> header field that indicates "trailers" is acceptable in the transfer coding of the response, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.3</a>; or,
    1713                   </li>
    1714                   <li>the trailer fields consist entirely of optional metadata and the recipient could use the message (in a manner acceptable to
    1715                      the generating server) without receiving that metadata. In other words, the generating server is willing to accept the possibility
    1716                      that the trailer fields might be silently discarded along the path to the client.
    1717                   </li>
    1718                </ol>
    1719                <p id="rfc.section.4.1.2.p.5">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later)
    1720                   proxy and forwarded to an HTTP/1.0 recipient.
     1703               <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#chunked.trailer.part" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
     1704</pre><p id="rfc.section.4.1.2.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field necessary for message framing (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and <a href="#header.content-length" class="smpl">Content-Length</a>), routing (e.g., <a href="#header.host" class="smpl">Host</a>), request modifiers (e.g., controls and conditionals in <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), authentication (e.g., see <a href="#Part7" id="rfc.xref.Part7.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> and <a href="#RFC6265" id="rfc.xref.RFC6265.3"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>), response control data (e.g., see <a href="p2-semantics.html#response.control.data" title="Control Data">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), or determining how to process the payload (e.g., <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a>, and <a href="#header.trailer" class="smpl">Trailer</a>).
     1705               </p>
     1706               <p id="rfc.section.4.1.2.p.4">When a chunked message containing a non-empty trailer is received, the recipient <em class="bcp14">MAY</em> process the fields (aside from those forbidden above) as if they were appended to the message's header section. A recipient <em class="bcp14">MUST</em> ignore (or consider as an error) any fields that are forbidden to be sent in a trailer, since processing them as if they were
     1707                  present in the header section might bypass external security filters.
     1708               </p>
     1709               <p id="rfc.section.4.1.2.p.5">Unless the request includes a <a href="#header.te" class="smpl">TE</a> header field indicating "trailers" is acceptable, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.3</a>, a server <em class="bcp14">SHOULD NOT</em> generate trailer fields that it believes are necessary for the user agent to receive. Without a TE containing "trailers",
     1710                  the server ought to assume that the trailer fields might be silently discarded along the path to the user agent. This requirement
     1711                  allows intermediaries to forward a de-chunked message to an HTTP/1.0 recipient without buffering the entire response.
    17211712               </p>
    17221713            </div>
    … …  
    17321723     read chunk-size, chunk-ext (if any), and CRLF
    17331724  }
    1734   read header-field
    1735   while (header-field not empty) {
    1736      append header-field to existing header fields
    1737      read header-field
     1725  read trailer field
     1726  while (trailer field is not empty) {
     1727     if trailer field is allowed to be sent in a trailer,
     1728         append trailer field to existing header fields
     1729     read trailer-field
    17381730  }
    17391731  Content-Length := length
    … …  
    17621754            </div>
    17631755            <div id="gzip.coding">
    1764                <div id="rfc.iref.g.78"></div>
     1756               <div id="rfc.iref.g.70"></div>
    17651757               <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a href="#gzip.coding">Gzip Coding</a></h3>
    17661758               <p id="rfc.section.4.2.3.p.1">The "gzip" coding is an LZ77 coding with a 32 bit CRC that is commonly produced by the gzip file compression program <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. A recipient <em class="bcp14">SHOULD</em> consider "x-gzip" to be equivalent to "gzip".
    … …  
    17771769               described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), and/or the keyword "trailers". A client <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.
    17781770            </p>
    1779             <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
     1771            <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
    17801772  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-coding</a> [ <a href="#header.te" class="smpl">t-ranking</a> ] )
    17811773  <a href="#header.te" class="smpl">t-ranking</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#header.te" class="smpl">rank</a>
    … …  
    17931785            </p>
    17941786            <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation
    1795                fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
     1787               fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
    17961788               a value of 0 means "not acceptable".
    17971789            </p>
    … …  
    18101802               and the recipient wishes to confirm an integrity check on the fly.
    18111803            </p>
    1812             <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.83"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
     1804            <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    18131805</pre></div>
    18141806      </div>
    … …  
    18281820            </p>
    18291821            <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1830                are defined in <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
     1822               are defined in <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
    18311823               processing (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    18321824            </p>
    … …  
    18571849               both the method being requested and whether the request is to a proxy.
    18581850            </p>
    1859             <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span>  <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a>
     1851            <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span>  <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a>
    18601852                 / <a href="#absolute-form" class="smpl">absolute-form</a>
    18611853                 / <a href="#authority-form" class="smpl">authority-form</a>
    … …  
    18981890               </p>
    18991891            </div>
    1900             <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
     1892            <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
    19011893            </p>
    19021894            <div id="rfc.figure.u.42"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    … …  
    19051897               </p>
    19061898            </div>
    1907             <p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
     1899            <p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
    19081900               the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    19091901            </p>
    … …  
    19251917               to distinguish among resources while servicing requests for multiple host names on a single IP address.
    19261918            </p>
    1927             <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.89"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
     1919            <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.82"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
    19281920</pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client <em class="bcp14">MUST</em> send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@"
    19291921               delimiter (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target URI, then a client <em class="bcp14">MUST</em> send a Host header field with an empty field-value.
    … …  
    19931985            <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    19941986               messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1995                on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.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>) precede a final response to the same request.
     1987               on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.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>) precede a final response to the same request.
    19961988            </p>
    19971989            <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final
    … …  
    20192011                  along the request/response chain.
    20202012               </p>
    2021                <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span>  <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
     2013               <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span>  <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    20222014
    20232015  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
    … …  
    20832075                  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>).
    20842076               </p>
    2085                <p id="rfc.section.5.7.2.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) of a message that contains a no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2077               <p id="rfc.section.5.7.2.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) of a message that contains a no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    20862078               </p>
    20872079               <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain a no-transform cache-control directive. A proxy that transforms a
    20882080                  payload <em class="bcp14">MUST</em> add a Warning header field with the warn-code of 214 ("Transformation Applied") if one is not already in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A proxy that transforms the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response can further inform downstream recipients that a transformation has been applied by changing the response status code
    2089                   to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.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>).
     2081                  to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    20902082               </p>
    20912083            </div>
    … …  
    21242116            </p>
    21252117            <p id="rfc.section.6.1.p.4">The Connection header field's value has the following grammar:</p>
    2126             <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span>  <a href="#header.connection" class="smpl">Connection</a>        = 1#<a href="#header.connection" class="smpl">connection-option</a>
     2118            <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span>  <a href="#header.connection" class="smpl">Connection</a>        = 1#<a href="#header.connection" class="smpl">connection-option</a>
    21272119  <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a>
    21282120</pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p>
    … …  
    21912183               </p>
    21922184               <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent
    2193                   methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.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>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
     2185                  methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.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>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
    21942186               </p>
    21952187               <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are
    … …  
    22052197            <div id="pipelining">
    22062198               <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a href="#pipelining">Pipelining</a></h3>
    2207                <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
     2199               <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
    22082200               </p>
    22092201               <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined
    … …  
    22122204                  problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section&nbsp;6.6</a>).
    22132205               </p>
    2214                <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.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>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
     2206               <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
    22152207                  the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
    22162208               </p>
    … …  
    22932285               in order of descending preference, before sending the final response. A server <em class="bcp14">MAY</em> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection.
    22942286            </p>
    2295             <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.98"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>          = 1#<a href="#header.upgrade" class="smpl">protocol</a>
     2287            <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.91"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>          = 1#<a href="#header.upgrade" class="smpl">protocol</a>
    22962288
    22972289  <a href="#header.upgrade" class="smpl">protocol</a>         = <a href="#header.upgrade" class="smpl">protocol-name</a> ["/" <a href="#header.upgrade" class="smpl">protocol-version</a>]
    … …  
    23362328            </p>
    23372329            <p id="rfc.section.6.7.p.11">A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e.,
    2338                the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
     2330               the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.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>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
    23392331            </p>
    23402332            <p id="rfc.section.6.7.p.12">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch
    23412333               the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those
    2342                purposes, 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 6.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>).
     2334               purposes, 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 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    23432335            </p>
    23442336            <p id="rfc.section.6.7.p.13">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    … …  
    26722664                  <li>Pointer to specification text</li>
    26732665               </ul>
    2674                <p id="rfc.section.8.4.1.p.2">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>.
     2666               <p id="rfc.section.8.4.1.p.2">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.33"><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>.
    26752667               </p>
    26762668               <p id="rfc.section.8.4.1.p.3">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 specification.
    … …  
    28452837         <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1>
    28462838         <p id="rfc.section.9.p.1">This section is meant to inform developers, information providers, and users of known security considerations relevant to
    2847             HTTP message syntax, parsing, and routing. Security considerations about HTTP semantics and payloads are addressed in <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
     2839            HTTP message syntax, parsing, and routing. Security considerations about HTTP semantics and payloads are addressed in <a href="#Part2" id="rfc.xref.Part2.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    28482840         </p>
    28492841         <div id="dns.related.attacks">
    … …  
    28782870               that most implementations will choose substantially higher limits.
    28792871            </p>
    2880             <p id="rfc.section.9.3.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 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.33"><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 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
     2872            <p id="rfc.section.9.3.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 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.35"><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 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
    28812873            </p>
    28822874            <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods,
    … …  
    35093501                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    35103502                     <ul>
    3511                         <li><tt>absolute-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>5.3</b></a></li>
     3503                        <li><tt>absolute-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.3</b></a></li>
    35123504                        <li><tt>absolute-path</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    35133505                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.7</b></a></li>
    35143506                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
    3515                         <li><tt>asterisk-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.3</b></a></li>
     3507                        <li><tt>asterisk-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>5.3</b></a></li>
    35163508                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.7</b></a></li>
    3517                         <li><tt>authority-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>5.3</b></a></li>
     3509                        <li><tt>authority-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.3</b></a></li>
    35183510                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.3</b></a></li>
    3519                         <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>4.1</b></a>, <a href="#rfc.iref.g.67"><b>4.1.1</b></a></li>
    3520                         <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>4.1</b></a>, <a href="#rfc.iref.g.73"><b>4.1.1</b></a></li>
    3521                         <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>4.1</b></a>, <a href="#rfc.iref.g.70"><b>4.1.1</b></a></li>
    3522                         <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>4.1</b></a>, <a href="#rfc.iref.g.71"><b>4.1.1</b></a></li>
    3523                         <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>4.1</b></a>, <a href="#rfc.iref.g.72"><b>4.1.1</b></a></li>
    3524                         <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>4.1</b></a>, <a href="#rfc.iref.g.68"><b>4.1.1</b></a></li>
    3525                         <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4.1</b></a>, <a href="#rfc.iref.g.66"><b>4.1.1</b></a></li>
     3511                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>4.1</b></a></li>
     3512                        <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>4.1</b></a></li>
     3513                        <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62">4.1</a>, <a href="#rfc.iref.g.65"><b>4.1.1</b></a></li>
     3514                        <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>4.1.1</b></a></li>
     3515                        <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>4.1.1</b></a></li>
     3516                        <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>4.1</b></a></li>
     3517                        <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4.1</b></a>, <a href="#rfc.iref.g.64"><b>4.1.1</b></a></li>
    35263518                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.6</b></a></li>
    3527                         <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.96"><b>6.1</b></a></li>
    3528                         <li><tt>connection-option</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.97"><b>6.1</b></a></li>
     3519                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>6.1</b></a></li>
     3520                        <li><tt>connection-option</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>6.1</b></a></li>
    35293521                        <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>3.3.2</b></a></li>
    35303522                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    … …  
    35353527                        <li>DQUOTE&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>1.2</b></a></li>
    35363528                        <li><tt>field-content</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>3.2</b></a></li>
    3537                         <li><tt>field-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>3.2</b></a></li>
     3529                        <li><tt>field-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>3.2</b></a>, <a href="#rfc.iref.g.76">4.4</a></li>
    35383530                        <li><tt>field-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>3.2</b></a></li>
    35393531                        <li><tt>fragment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    3540                         <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>3.2</b></a></li>
     3532                        <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>3.2</b></a>, <a href="#rfc.iref.g.69">4.1.2</a></li>
    35413533                        <li>HEXDIG&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>1.2</b></a></li>
    3542                         <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>5.4</b></a></li>
     3534                        <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>5.4</b></a></li>
    35433535                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    35443536                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>3</b></a></li>
    … …  
    35473539                        <li><tt>HTTP-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.6</b></a></li>
    35483540                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>2.7.2</b></a></li>
    3549                         <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>4.1</b></a>, <a href="#rfc.iref.g.69"><b>4.1.1</b></a></li>
     3541                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>4.1</b></a></li>
    35503542                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li>
    35513543                        <li><tt>message-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.3</b></a></li>
    … …  
    35543546                        <li><tt>obs-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.6</b></a></li>
    35553547                        <li>OCTET&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>1.2</b></a></li>
    3556                         <li><tt>origin-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>5.3</b></a></li>
     3548                        <li><tt>origin-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>5.3</b></a></li>
    35573549                        <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.3</b></a></li>
    35583550                        <li><tt>partial-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>2.7</b></a></li>
    35593551                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    3560                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>5.7.1</b></a></li>
    3561                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>5.7.1</b></a></li>
    3562                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.95"><b>5.7.1</b></a></li>
     3552                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>5.7.1</b></a></li>
     3553                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>5.7.1</b></a></li>
     3554                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.7.1</b></a></li>
    35633555                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.6</b></a></li>
    3564                         <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>4.1.1</b></a></li>
    35653556                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
    35663557                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.6</b></a></li>
    3567                         <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>4.1.1</b></a></li>
    35683558                        <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.6</b></a></li>
    3569                         <li><tt>rank</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>4.3</b></a></li>
     3559                        <li><tt>rank</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>4.3</b></a></li>
    35703560                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>3.1.2</b></a></li>
    3571                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.94"><b>5.7.1</b></a></li>
    3572                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>5.7.1</b></a></li>
     3561                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>5.7.1</b></a></li>
     3562                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>5.7.1</b></a></li>
    35733563                        <li><tt>request-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>3.1.1</b></a></li>
    3574                         <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>5.3</b></a></li>
     3564                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>5.3</b></a></li>
    35753565                        <li><tt>RWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.3</b></a></li>
    35763566                        <li><tt>segment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.7</b></a></li>
    … …  
    35793569                        <li><tt>status-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>3.1.2</b></a></li>
    35803570                        <li><tt>status-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.2</b></a></li>
    3581                         <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>4.3</b></a></li>
    3582                         <li><tt>t-ranking</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>4.3</b></a></li>
     3571                        <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>4.3</b></a></li>
     3572                        <li><tt>t-ranking</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>4.3</b></a></li>
    35833573                        <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.6</b></a></li>
    3584                         <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>4.3</b></a></li>
     3574                        <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>4.3</b></a></li>
    35853575                        <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2.6</b></a></li>
    3586                         <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>4.4</b></a></li>
    3587                         <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65">4.1</a>, <a href="#rfc.iref.g.74">4.1.1</a>, <a href="#rfc.iref.g.77"><b>4.1.2</b></a></li>
     3576                        <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>4.4</b></a></li>
     3577                        <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61">4.1</a>, <a href="#rfc.iref.g.68"><b>4.1.2</b></a></li>
    35883578                        <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>4</b></a></li>
    35893579                        <li><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>3.3.1</b></a></li>
    35903580                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>4</b></a></li>
    35913581                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    3592                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.98"><b>6.7</b></a></li>
     3582                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>6.7</b></a></li>
    35933583                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7</b></a></li>
    35943584                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    35953585                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3596                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>5.7.1</b></a></li>
     3586                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>5.7.1</b></a></li>
    35973587                     </ul>
    35983588                  </li>
    3599                   <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.78">4.2.3</a></li>
     3589                  <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.70">4.2.3</a></li>
    36003590               </ul>
    36013591            </li>
    … …  
    36433633            </li>
    36443634            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3645                   <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.1</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</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.19">4.3</a>, <a href="#rfc.xref.Part2.20">5.1</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.3</a>, <a href="#rfc.xref.Part2.23">5.6</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">6.3.1</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.3.2</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">6.7</a>, <a href="#rfc.xref.Part2.31">8.4.1</a>, <a href="#rfc.xref.Part2.32">9</a>, <a href="#rfc.xref.Part2.33">9.3</a>, <a href="#rfc.xref.Part2.34">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
     3635                  <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.1</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</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.19">4.1.2</a>, <a href="#rfc.xref.Part2.20">4.1.2</a>, <a href="#rfc.xref.Part2.21">4.3</a>, <a href="#rfc.xref.Part2.22">5.1</a>, <a href="#rfc.xref.Part2.23">5.3</a>, <a href="#rfc.xref.Part2.24">5.3</a>, <a href="#rfc.xref.Part2.25">5.6</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.3.2</a>, <a href="#rfc.xref.Part2.31">6.7</a>, <a href="#rfc.xref.Part2.32">6.7</a>, <a href="#rfc.xref.Part2.33">8.4.1</a>, <a href="#rfc.xref.Part2.34">9</a>, <a href="#rfc.xref.Part2.35">9.3</a>, <a href="#rfc.xref.Part2.36">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
    36463636                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    36473637                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">3.3.2</a></li>
    3648                         <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.31">8.4.1</a></li>
    3649                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.7.2</a></li>
     3638                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.33">8.4.1</a></li>
     3639                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.7.2</a></li>
    36503640                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3651                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.3.2</a></li>
    3652                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a></li>
     3641                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.3.2</a></li>
     3642                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.30">6.3.2</a></li>
    36533643                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.12">3.3</a></li>
    36543644                        <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.17">3.3.2</a></li>
    3655                         <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.21">5.3</a></li>
    3656                         <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.3</a></li>
    3657                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.7</a></li>
    3658                         <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">4.3</a></li>
     3645                        <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.23">5.3</a></li>
     3646                        <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.3</a></li>
     3647                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">4.1.2</a></li>
     3648                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.31">6.7</a></li>
     3649                        <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">4.3</a></li>
    36593650                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>
    3660                         <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.6</a></li>
    3661                         <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.7.2</a></li>
    3662                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">6.7</a></li>
    3663                         <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.34">9.3</a></li>
    3664                         <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.33">9.3</a></li>
     3651                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.6</a></li>
     3652                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">5.7.2</a></li>
     3653                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.32">6.7</a></li>
     3654                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.36">9.3</a></li>
     3655                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.35">9.3</a></li>
     3656                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">4.1.2</a></li>
    36653657                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    36663658                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
    … …  
    36803672                     </ul>
    36813673                  </li>
    3682                   <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">1</a>, <a href="#Part7"><b>11.1</b></a></li>
     3674                  <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">1</a>, <a href="#rfc.xref.Part7.2">4.1.2</a>, <a href="#Part7"><b>11.1</b></a></li>
    36833675                  <li>proxy&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>2.3</b></a></li>
    36843676               </ul>
    … …  
    37523744                     </ul>
    37533745                  </li>
    3754                   <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2.2</a>, <a href="#RFC6265"><b>11.2</b></a></li>
     3746                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2.2</a>, <a href="#rfc.xref.RFC6265.3">4.1.2</a>, <a href="#RFC6265"><b>11.2</b></a></li>
    37553747                  <li><em>RFC6585</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6585.1">9.3</a>, <a href="#RFC6585"><b>11.2</b></a></li>
    37563748               </ul>

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

    r2569 r2580  
    5050  <!ENTITY OPTIONS                "<xref target='Part2' x:rel='#OPTIONS' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5151  <!ENTITY qvalue                 "<xref target='Part2' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     52  <!ENTITY request-header-fields  "<xref target='Part2' x:rel='#request.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     53  <!ENTITY response-control-data  "<xref target='Part2' x:rel='#response.control.data' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5254  <!ENTITY resource               "<xref target='Part2' x:rel='#resources' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5355  <!ENTITY semantics              "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    19721974   recipient to know when it has received the entire message.
    19731975</t>
    1974 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="false" item="Grammar" subitem="trailer-part"/>
     1976<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="false" item="Grammar" subitem="trailer-part"/><iref primary="false" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-data"/>
    19751977  <x:ref>chunked-body</x:ref>   = *<x:ref>chunk</x:ref>
    19761978                   <x:ref>last-chunk</x:ref>
    … …  
    20052007   mid-message control information, or randomization of message body size.
    20062008</t>
    2007 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="false" item="Grammar" subitem="trailer-part"/><iref primary="true" item="Grammar" subitem="quoted-str-nf"/><iref primary="true" item="Grammar" subitem="qdtext-nf"/>
     2009<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/>
    20082010  <x:ref>chunk-ext</x:ref>      = *( ";" <x:ref>chunk-ext-name</x:ref> [ "=" <x:ref>chunk-ext-val</x:ref> ] )
    20092011
    … …  
    20402042   instead of the message's header section.
    20412043</t>
    2042 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="trailer-part"/>
     2044<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="trailer-part"/><iref primary="false" item="Grammar" subitem="header-field"/>
    20432045  <x:ref>trailer-part</x:ref>   = *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
    20442046</artwork></figure>
    20452047<t>
    2046    A sender &MUST-NOT; generate a trailer that contains a field which needs to
    2047    be known by the recipient before it can begin processing the message body.
    2048    For example, most recipients need to know the values of
    2049    <x:ref>Content-Encoding</x:ref> and <x:ref>Content-Type</x:ref> in order to
    2050    select a content handler, so placing those fields in a trailer would force
    2051    the recipient to buffer the entire body before it could begin, greatly
    2052    increasing user-perceived latency and defeating one of the main advantages
    2053    of using chunked to send data streams of unknown length.
    2054    A sender &MUST-NOT; generate a trailer containing a
    2055    <x:ref>Transfer-Encoding</x:ref>,
    2056    <x:ref>Content-Length</x:ref>, or
    2057    <x:ref>Trailer</x:ref> field.
    2058 </t>
    2059 <t>
    2060    A server &MUST; generate an empty trailer with the chunked transfer coding
    2061    unless at least one of the following is true:
    2062   <list style="numbers">
    2063     <t>the request included a <x:ref>TE</x:ref> header field that indicates
    2064     "trailers" is acceptable in the transfer coding of the response, as
    2065     described in <xref target="header.te"/>; or,</t>
    2066      
    2067     <t>the trailer fields consist entirely of optional metadata and the
    2068     recipient could use the message (in a manner acceptable to the generating
    2069     server) without receiving that metadata. In other words, the generating
    2070     server is willing to accept the possibility that the trailer fields might
    2071     be silently discarded along the path to the client.</t>
    2072   </list>
    2073 </t>
    2074 <t>
    2075    The above requirement prevents the need for an infinite buffer when a
    2076    message is being received by an HTTP/1.1 (or later) proxy and forwarded to
    2077    an HTTP/1.0 recipient.
     2048   A sender &MUST-NOT; generate a trailer that contains a field necessary for
     2049   message framing (e.g., <x:ref>Transfer-Encoding</x:ref> and
     2050   <x:ref>Content-Length</x:ref>), routing (e.g., <x:ref>Host</x:ref>),
     2051   request modifiers (e.g., controls and conditionals in
     2052   &request-header-fields;), authentication (e.g., see <xref target="Part7"/>
     2053   and <xref target="RFC6265"/>), response control data (e.g., see
     2054   &response-control-data;), or determining how to process the payload
     2055   (e.g., <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Type</x:ref>,
     2056   <x:ref>Content-Range</x:ref>, and <x:ref>Trailer</x:ref>).
     2057</t>
     2058<t>
     2059   When a chunked message containing a non-empty trailer is received, the
     2060   recipient &MAY; process the fields (aside from those forbidden above)
     2061   as if they were appended to the message's header section.
     2062   A recipient &MUST; ignore (or consider as an error) any fields that are
     2063   forbidden to be sent in a trailer, since processing them as if they were
     2064   present in the header section might bypass external security filters.
     2065</t>
     2066<t>
     2067   Unless the request includes a <x:ref>TE</x:ref> header field indicating
     2068   "trailers" is acceptable, as described in <xref target="header.te"/>, a
     2069   server &SHOULD-NOT; generate trailer fields that it believes are necessary
     2070   for the user agent to receive. Without a TE containing "trailers", the
     2071   server ought to assume that the trailer fields might be silently discarded
     2072   along the path to the user agent. This requirement allows intermediaries to
     2073   forward a de-chunked message to an HTTP/1.0 recipient without buffering the
     2074   entire response.
    20782075</t>
    20792076</section>
    … …  
    20932090     read chunk-size, chunk-ext (if any), and CRLF
    20942091  }
    2095   read header-field
    2096   while (header-field not empty) {
    2097      append header-field to existing header fields
    2098      read header-field
     2092  read trailer field
     2093  while (trailer field is not empty) {
     2094     if trailer field is allowed to be sent in a trailer,
     2095         append trailer field to existing header fields
     2096     read trailer-field
    20992097  }
    21002098  Content-Length := length
    … …  
    22292227   to confirm an integrity check on the fly.
    22302228</t>
    2231 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/>
     2229<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/><iref primary="false" item="Grammar" subitem="field-name"/>
    22322230  <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>
    22332231</artwork></figure>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2579 r2580  
    12231223                     </tr>
    12241224                     <tr>
     1225                        <td class="left">Trailer</td>
     1226                        <td class="left"><a href="p1-messaging.html#header.trailer" title="Trailer">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
     1227                     </tr>
     1228                     <tr>
    12251229                        <td class="left">Transfer-Encoding</td>
    1226                         <td class="left"><a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
     1230                        <td class="left"><a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
    12271231                     </tr>
    12281232                  </tbody>
    … …  
    16311635               <p id="rfc.section.4.3.6.p.2">CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
    16321636               </p>
    1633                <p id="rfc.section.4.3.6.p.3">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1637               <p id="rfc.section.4.3.6.p.3">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
    16341638                  For example,
    16351639               </p>
    … …  
    16701674                  with a resource, or the capabilities of a server, without implying a resource action.
    16711675               </p>
    1672                <p id="rfc.section.4.3.7.p.2">An OPTIONS request with an asterisk ("*") as the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend
     1676               <p id="rfc.section.4.3.7.p.2">An OPTIONS request with an asterisk ("*") as the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend
    16731677                  on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the
    16741678                  client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or
    … …  
    16931697               <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;<a href="#TRACE">TRACE</a></h3>
    16941698               <div id="rfc.iref.t.1"></div>
    1695                <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;5.1.2</a>).
     1699               <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;5.1.2</a>).
    16961700               </p>
    16971701               <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example,
    … …  
    16991703               </p>
    17001704               <p id="rfc.section.4.3.8.p.3">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1701                   or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
     1705                  or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
    17021706                  messages in an infinite loop.
    17031707               </p>
    … …  
    17371741                     <tr>
    17381742                        <td class="left">Host</td>
    1739                         <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
     1743                        <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
    17401744                     </tr>
    17411745                     <tr>
    … …  
    17531757                     <tr>
    17541758                        <td class="left">TE</td>
    1755                         <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
     1759                        <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
    17561760                     </tr>
    17571761                  </tbody>
    … …  
    18061810                  </li>
    18071811                  <li>A server that responds with a final status code before reading the entire message body <em class="bcp14">SHOULD</em> indicate in that response whether it intends to close the connection or continue reading and discarding the request message
    1808                      (see <a href="p1-messaging.html#persistent.tear-down" title="Tear-down">Section 6.6</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     1812                     (see <a href="p1-messaging.html#persistent.tear-down" title="Tear-down">Section 6.6</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    18091813                  </li>
    18101814               </ul>
    … …  
    22552259               </p>
    22562260               <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) )
    2257 </pre><p id="rfc.section.5.5.3.p.3">The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the user agent software and its significant subproducts. By convention, the product identifiers
     2261</pre><p id="rfc.section.5.5.3.p.3">The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the user agent software and its significant subproducts. By convention, the product identifiers
    22582262                  are listed in decreasing order of their significance for identifying the user agent software. Each product identifier consists
    22592263                  of a name and optional version.
    … …  
    25632567               <div id="rfc.iref.66"></div>
    25642568               <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a href="#status.101">101 Switching Protocols</a></h3>
    2565                <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the
     2569               <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the
    25662570                  empty line that terminates the 101 response.
    25672571               </p>
    … …  
    26322636               <div id="rfc.iref.67"></div>
    26332637               <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a href="#status.203">203 Non-Authoritative Information</a></h3>
    2634                <p id="rfc.section.6.3.4.p.1">The <dfn>203 (Non-Authoritative Information)</dfn> status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might
     2638               <p id="rfc.section.6.3.4.p.1">The <dfn>203 (Non-Authoritative Information)</dfn> status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might
    26352639                  impact later decisions regarding the content. For example, future cache validation requests for the content might only be
    26362640                  applicable along the same request path (through the same proxies).
    … …  
    28922896               <h3 id="rfc.section.6.5.7"><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;<a href="#status.408">408 Request Timeout</a></h3>
    28932897               <p id="rfc.section.6.5.7.p.1">The <dfn>408 (Request Timeout)</dfn> status code indicates that the server did not receive a complete request message within the time that it was prepared to wait.
    2894                   A server <em class="bcp14">SHOULD</em> send the <a href="p1-messaging.html#header.connection" class="smpl">close</a> connection option (<a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If
     2898                  A server <em class="bcp14">SHOULD</em> send the <a href="p1-messaging.html#header.connection" class="smpl">close</a> connection option (<a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If
    28952899                  the client has an outstanding request in transit, the client <em class="bcp14">MAY</em> repeat that request on a new connection.
    28962900               </p>
    … …  
    29272931               <div id="rfc.iref.69"></div>
    29282932               <h3 id="rfc.section.6.5.10"><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;<a href="#status.411">411 Length Required</a></h3>
    2929                <p id="rfc.section.6.5.10.p.1">The <dfn>411 (Length Required)</dfn> status code indicates that the server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> (<a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
     2933               <p id="rfc.section.6.5.10.p.1">The <dfn>411 (Length Required)</dfn> status code indicates that the server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> (<a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
    29302934                  message.
    29312935               </p>
    … …  
    29432947               <div id="rfc.iref.69"></div>
    29442948               <h3 id="rfc.section.6.5.12"><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;<a href="#status.414">414 URI Too Long</a></h3>
    2945                <p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly
     2949               <p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly
    29462950                  converted a POST request to a GET request with long query information, when the client has descended into a "black hole" of
    29472951                  redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client
    … …  
    29692973               <h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;<a href="#status.426">426 Upgrade Required</a></h3>
    29702974               <p id="rfc.section.6.5.15.p.1">The <dfn>426 (Upgrade Required)</dfn> status code indicates that the server refuses to perform the request using the current protocol but might be willing to do
    2971                   so after the client upgrades to a different protocol. The server <em class="bcp14">MUST</em> send an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field in a 426 response to indicate the required protocol(s) (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     2975                  so after the client upgrades to a different protocol. The server <em class="bcp14">MUST</em> send an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field in a 426 response to indicate the required protocol(s) (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    29722976               </p>
    29732977               <div id="rfc.figure.u.42"></div>
    … …  
    30363040               <p id="rfc.section.6.6.6.p.1">The <dfn>505 (HTTP Version Not Supported)</dfn> status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in
    30373041                  the request message. The server is indicating that it is unable or unwilling to complete the request using the same major
    3038                   version as the client, as described in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The server <em class="bcp14">SHOULD</em> generate a representation for the 505 response that describes why that version is not supported and what other protocols are
     3042                  version as the client, as described in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The server <em class="bcp14">SHOULD</em> generate a representation for the 505 response that describes why that version is not supported and what other protocols are
    30393043                  supported by that server.
    30403044               </p>
    … …  
    34253429               </p>
    34263430               <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) )
    3427 </pre><p id="rfc.section.7.4.2.p.3">The Server field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the origin server software and its significant subproducts. By convention, the product identifiers
     3431</pre><p id="rfc.section.7.4.2.p.3">The Server field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the origin server software and its significant subproducts. By convention, the product identifiers
    34283432                  are listed in decreasing order of their significance for identifying the origin server software. Each product identifier consists
    34293433                  of a name and optional version, as defined in <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;5.5.3</a>.
    … …  
    34663470                  to a single application or data format, since orthogonal technologies deserve orthogonal specification.
    34673471               </p>
    3468                <p id="rfc.section.8.1.2.p.2">Since message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the
     3472               <p id="rfc.section.8.1.2.p.2">Since message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the
    34693473                  parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of
    34703474                  new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a
    … …  
    38473851               <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3>
    38483852               <p id="rfc.section.8.3.1.p.1">Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource,
    3849                   or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.
     3853                  or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.
    38503854               </p>
    38513855               <p id="rfc.section.8.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>.
    … …  
    38563860                  processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see <a href="#BCP178" id="rfc.xref.BCP178.1"><cite title="Deprecating the &#34;X-&#34; Prefix and Similar Constructs in Application Protocols">[BCP178]</cite></a> for further information)
    38573861               </p>
    3858                <p id="rfc.section.8.3.1.p.4">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 7</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
     3862               <p id="rfc.section.8.3.1.p.4">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 7</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
    38593863                  can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
    38603864               </p>
    3861                <p id="rfc.section.8.3.1.p.5">Leading and trailing whitespace in raw field values is removed upon field parsing (<a href="p1-messaging.html#field.parsing" title="Field Parsing">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such
    3862                   as quoted-string (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     3865               <p id="rfc.section.8.3.1.p.5">Leading and trailing whitespace in raw field values is removed upon field parsing (<a href="p1-messaging.html#field.parsing" title="Field Parsing">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such
     3866                  as quoted-string (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    38633867               </p>
    38643868               <p id="rfc.section.8.3.1.p.6">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
    … …  
    38823886               <ul>
    38833887                  <li>
    3884                      <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     3888                     <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    38853889                     </p>
    38863890                     <p>If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default
    … …  
    39053909                  </li>
    39063910                  <li>
    3907                      <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop; see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     3911                     <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop; see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    39083912                     </p>
    39093913                  </li>
    … …  
    39163920                  </li>
    39173921                  <li>
    3918                      <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     3922                     <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    39193923                     </p>
    39203924                  </li>
    … …  
    40904094         <div id="content.coding.registry">
    40914095            <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a href="#content.coding.registry">Content Coding Registry</a></h2>
    4092             <p id="rfc.section.8.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     4096            <p id="rfc.section.8.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    40934097            </p>
    40944098            <div id="content.coding.procedure">
    … …  
    41014105                  <li>Pointer to specification text</li>
    41024106               </ul>
    4103                <p id="rfc.section.8.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     4107               <p id="rfc.section.8.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    41044108               </p>
    41054109               <p id="rfc.section.8.4.1.p.3">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.3"><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 content coding defined in this section.
    … …  
    41374141         <p id="rfc.section.9.p.1">This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics
    41384142            and its use for transferring information over the Internet. Considerations related to message syntax, parsing, and routing
    4139             are discussed in <a href="p1-messaging.html#security.considerations" title="Security Considerations">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     4143            are discussed in <a href="p1-messaging.html#security.considerations" title="Security Considerations">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    41404144         </p>
    41414145         <p id="rfc.section.9.p.2">The list of considerations below is not exhaustive. Most security concerns related to HTTP semantics are about securing server-side
    … …  
    42164220         <div id="disclosure.product.information">
    42174221            <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a href="#disclosure.product.information">Disclosure of Product Information</a></h2>
    4218             <p id="rfc.section.9.6.p.1">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;5.5.3</a>), <a href="p1-messaging.html#header.via" class="smpl">Via</a> (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), and <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.4.2</a>) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier
     4222            <p id="rfc.section.9.6.p.1">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;5.5.3</a>), <a href="p1-messaging.html#header.via" class="smpl">Via</a> (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), and <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.4.2</a>) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier
    42194223               for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the
    42204224               apparent software versions being used.
    … …  
    42564260      <div id="acks">
    42574261         <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a href="#acks">Acknowledgments</a></h1>
    4258          <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     4262         <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    42594263         </p>
    42604264      </div>
    … …  
    45514555            and the undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>)
    45524556         </p>
    4553          <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (<a href="#GET" id="rfc.xref.GET.6" title="GET">Section&nbsp;4.3.1</a>)
     4557         <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (<a href="#GET" id="rfc.xref.GET.6" title="GET">Section&nbsp;4.3.1</a>)
    45544558         </p>
    45554559         <p id="rfc.section.B.p.7">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section&nbsp;4.3.4</a>)
    … …  
    46124616            (any visible US-ASCII character).
    46134617         </p>
    4614          <p id="rfc.section.C.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
    4615          </p>
    4616          <div id="rfc.figure.u.65"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    4617   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    4618   <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    4619   <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4620   <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4621   <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    4622   <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    4623   <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4624   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    4625   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4618         <p id="rfc.section.C.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     4619         </p>
     4620         <div id="rfc.figure.u.65"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4621  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4622  <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4623  <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4624  <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4625  <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4626  <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
     4627  <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4628  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4629  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.57"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    46264630</pre></div>
    46274631      <div id="collected.abnf">
    46284632         <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a href="#collected.abnf">Collected ABNF</a></h1>
    4629          <p id="rfc.section.D.p.1">In the collected ABNF below, list rules are expanded as per <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.57"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     4633         <p id="rfc.section.D.p.1">In the collected ABNF below, list rules are expanded as per <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.58"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    46304634         </p>
    46314635         <div id="rfc.figure.u.66"></div><pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
    … …  
    49894993            </li>
    49904994            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    4991                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.1.1</a>, <a href="#rfc.xref.Part1.22">5.5.3</a>, <a href="#rfc.xref.Part1.23">6.2.2</a>, <a href="#rfc.xref.Part1.24">6.3.4</a>, <a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.26">6.5.10</a>, <a href="#rfc.xref.Part1.27">6.5.12</a>, <a href="#rfc.xref.Part1.28">6.5.15</a>, <a href="#rfc.xref.Part1.29">6.6.6</a>, <a href="#rfc.xref.Part1.30">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.1.2</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.38">8.3.1</a>, <a href="#rfc.xref.Part1.39">8.4</a>, <a href="#rfc.xref.Part1.40">8.4.1</a>, <a href="#rfc.xref.Part1.41">8.4.1</a>, <a href="#rfc.xref.Part1.42">9</a>, <a href="#rfc.xref.Part1.43">9.6</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">B</a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">D</a><ul>
    4992                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.57">D</a></li>
     4995                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">3.3</a>, <a href="#rfc.xref.Part1.16">4.3.6</a>, <a href="#rfc.xref.Part1.17">4.3.7</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">4.3.8</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.1</a>, <a href="#rfc.xref.Part1.22">5.1.1</a>, <a href="#rfc.xref.Part1.23">5.5.3</a>, <a href="#rfc.xref.Part1.24">6.2.2</a>, <a href="#rfc.xref.Part1.25">6.3.4</a>, <a href="#rfc.xref.Part1.26">6.5.7</a>, <a href="#rfc.xref.Part1.27">6.5.10</a>, <a href="#rfc.xref.Part1.28">6.5.12</a>, <a href="#rfc.xref.Part1.29">6.5.15</a>, <a href="#rfc.xref.Part1.30">6.6.6</a>, <a href="#rfc.xref.Part1.31">7.4.2</a>, <a href="#rfc.xref.Part1.32">8.1.2</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.38">8.3.1</a>, <a href="#rfc.xref.Part1.39">8.3.1</a>, <a href="#rfc.xref.Part1.40">8.4</a>, <a href="#rfc.xref.Part1.41">8.4.1</a>, <a href="#rfc.xref.Part1.42">8.4.1</a>, <a href="#rfc.xref.Part1.43">9</a>, <a href="#rfc.xref.Part1.44">9.6</a>, <a href="#rfc.xref.Part1.45">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.46">B</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a>, <a href="#rfc.xref.Part1.58">D</a><ul>
     4996                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.58">D</a></li>
    49934997                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    4994                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.6.6</a></li>
    4995                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.54">C</a></li>
    4996                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">5.5.3</a>, <a href="#rfc.xref.Part1.30">7.4.2</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.53">C</a></li>
    4997                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a></li>
    4998                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">8.3.1</a></li>
    4999                         <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a></li>
    5000                         <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.14">3.3</a></li>
    5001                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">8.1.2</a></li>
    5002                         <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.26">6.5.10</a></li>
    5003                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.40">8.4.1</a></li>
    5004                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.38">8.3.1</a></li>
     4998                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.6.6</a></li>
     4999                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.55">C</a></li>
     5000                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">5.5.3</a>, <a href="#rfc.xref.Part1.31">7.4.2</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.54">C</a></li>
     5001                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a></li>
     5002                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">8.3.1</a></li>
     5003                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a></li>
     5004                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.15">3.3</a></li>
     5005                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">8.1.2</a></li>
     5006                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.27">6.5.10</a></li>
     5007                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.41">8.4.1</a></li>
     5008                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.39">8.3.1</a></li>
    50055009                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3.1.2.1</a></li>
    5006                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.39">8.4</a>, <a href="#rfc.xref.Part1.41">8.4.1</a></li>
     5010                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.40">8.4</a>, <a href="#rfc.xref.Part1.42">8.4.1</a></li>
    50075011                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.1.2.1</a></li>
    50085012                        <li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.1.2.1</a></li>
    5009                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">5.1</a></li>
    5010                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.27">6.5.12</a></li>
    5011                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">5.1</a></li>
     5013                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.1</a></li>
     5014                        <li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">3.3</a></li>
     5015                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.16">4.3.6</a>, <a href="#rfc.xref.Part1.17">4.3.7</a>, <a href="#rfc.xref.Part1.28">6.5.12</a></li>
     5016                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">5.1</a></li>
    50125017                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a></li>
    5013                         <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.43">9.6</a></li>
    5014                         <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">6.3.4</a></li>
    5015                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.37">8.3.1</a></li>
    5016                         <li><em>Section 6.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">5.1.1</a></li>
    5017                         <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">6.2.2</a>, <a href="#rfc.xref.Part1.28">6.5.15</a></li>
    5018                         <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.33">8.3.1</a></li>
    5019                         <li><em>Section 8.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.3.8</a></li>
    5020                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.42">9</a></li>
    5021                         <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.44">10</a></li>
     5018                        <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">4.3.8</a>, <a href="#rfc.xref.Part1.44">9.6</a></li>
     5019                        <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">6.3.4</a></li>
     5020                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">6.5.7</a>, <a href="#rfc.xref.Part1.38">8.3.1</a></li>
     5021                        <li><em>Section 6.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">5.1.1</a></li>
     5022                        <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">6.2.2</a>, <a href="#rfc.xref.Part1.29">6.5.15</a></li>
     5023                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.34">8.3.1</a></li>
     5024                        <li><em>Section 8.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a></li>
     5025                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">9</a></li>
     5026                        <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.45">10</a></li>
    50225027                     </ul>
    50235028                  </li>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2579 r2580  
    6868  <!ENTITY header-range               "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    6969  <!ENTITY header-te                  "<xref target='Part1' x:rel='#header.te' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     70  <!ENTITY header-trailer                  "<xref target='Part1' x:rel='#header.trailer' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    7071  <!ENTITY header-transfer-encoding   "<xref target='Part1' x:rel='#header.transfer-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    7172  <!ENTITY header-upgrade             "<xref target='Part1' x:rel='#header.upgrade' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    920921  <c>Content-Length</c> <c>&header-content-length;</c>
    921922  <c>Content-Range</c> <c>&header-content-range;</c>
     923  <c>Trailer</c> <c>&header-trailer;</c>
    922924  <c>Transfer-Encoding</c> <c>&header-transfer-encoding;</c>
    923925</texttable>
Note: See TracChangeset for help on using the changeset viewer.