Changeset 2031


Ignore:
Timestamp:
Dec 5, 2012, 8:59:49 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) Deal with second half of mnot p1 feedback; addresses #408

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

Legend:

Unmodified
Added
Removed

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

    r2030 r2031  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 7, 2013";
     451       content: "Expires June 8, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-04">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-05">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">December 4, 2012</td>
     522               <td class="right">December 5, 2012</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: June 7, 2013</td>
     525               <td class="left">Expires: June 8, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on June 7, 2013.</p>
     553      <p>This Internet-Draft will expire on June 8, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    635635               <li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
    636636               <li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    637                <li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a></li>
    638                <li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
    639                <li><a href="#rfc.section.5.8">5.8</a>&nbsp;&nbsp;&nbsp;<a href="#message.transforming">Message Transforming</a></li>
    640                <li><a href="#rfc.section.5.9">5.9</a>&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
     637               <li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
     638               <li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a><ul>
     639                     <li><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     640                     <li><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#message.transformation">Transformation</a></li>
     641                  </ul>
     642               </li>
    641643            </ul>
    642644         </li>
    … …  
    893895         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    894896         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    895          However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;5.7</a>) header fields for both connections.
     897         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) and <a href="#header.via" class="smpl">Via</a> (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;5.7.1</a>) header fields for both connections.
    896898      </p>
    897899      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    … …  
    13451347      </p>
    13461348      <div id="rfc.iref.t.4"></div>
     1349      <div id="rfc.iref.c.6"></div>
    13471350      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3>
    1348       <p id="rfc.section.3.3.1.p.1">When one or more transfer codings are applied to a payload body in order to form the message body, a Transfer-Encoding header
    1349          field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer codings are defined
    1350          in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>.
     1351      <p id="rfc.section.3.3.1.p.1">The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that
     1352         have been (or will be) applied to the payload body in order to form the message body. Transfer codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>.
    13511353      </p>
    13521354      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    … …  
    13541356         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is
    13551357         primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only
    1356          applied for transport efficiency or security from those that are characteristics of the target resource.
    1357       </p>
    1358       <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size
    1359          is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message body. If any transfer-coding is applied to a request payload body, the final transfer-coding
    1360          applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection.
     1358         applied for transport efficiency or security from those that are characteristics of the selected resource.
     1359      </p>
     1360      <p id="rfc.section.3.3.1.p.4">All HTTP/1.1 recipients <em class="bcp14">MUST</em> implement the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. If chunked is applied
     1361         to a payload body, the sender <em class="bcp14">MUST NOT</em> apply chunked more than once (i.e., chunking an already chunked message is not allowed). If any transfer coding is applied
     1362         to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding is applied
     1363         to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection.
    13611364      </p>
    13621365      <div id="rfc.figure.u.27"></div>
    … …  
    13651368         forming the message body.
    13661369      </p>
    1367       <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
    1368       </p>
    1369       <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    1370       </p>
    1371       <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
     1370      <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and any recipient along the request/response chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding
     1371         changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1372      </p>
     1373      <p id="rfc.section.3.3.1.p.7">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
    13721374         coding to the message body if the request had been an unconditional GET. This indication is not required, however, because
    13731375         any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
    13741376      </p>
    1375       <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
     1377      <p id="rfc.section.3.3.1.p.8">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
    13761378         not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge
    13771379         might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later).
    13781380      </p>
    1379       <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> and then close the connection.
    1380       </p>
    1381       <div id="rfc.iref.c.6"></div>
     1381      <p id="rfc.section.3.3.1.p.9">A server that receives a request message with a transfer coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a>.
     1382      </p>
     1383      <div id="rfc.iref.c.7"></div>
    13821384      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h3>
    13831385      <p id="rfc.section.3.3.2.p.1">When a message is allowed to contain a message body, does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field, and has a payload body length that is known to the sender before the message header section has been sent, the
    … …  
    14111413         </p>
    14121414      </div>
     1415      <div id="rfc.iref.c.8"></div>
    14131416      <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="message.body.length" href="#message.body.length">Message Body Length</a></h3>
    14141417      <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p>
    … …  
    14261429         </li>
    14271430         <li>
    1428             <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding
    1429                indicates the data is complete.
     1431            <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer
     1432               coding indicates the data is complete.
    14301433            </p>
    1431             <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the "chunked" transfer-coding is not the final encoding, the message body length
    1432                is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in
    1433                a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot be determined reliably;
    1434                the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection.
     1434            <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is
     1435               determined by reading the connection until it is closed by the server. If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot
     1436               be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection.
    14351437            </p>
    14361438            <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request
    14371439               or response smuggling (bypass of security-related checks on message routing or content) and thus ought to be handled as an
    1438                error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message body length after the transfer-coding
    1439                is decoded.
     1440               error. A sender <em class="bcp14">MUST</em> remove the received Content-Length field prior to forwarding such a message downstream.
    14401441            </p>
    14411442         </li>
    … …  
    14681469      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.
    14691470      </p>
    1470       <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the "chunked" encoding, since some existing services
    1471          respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via
    1472          a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire
    1473          request before processing.
     1471      <p id="rfc.section.3.3.3.p.5">Unless a transfer coding other than chunked has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing
     1472         services respond to chunked with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked transfer coding. This is typically because such services are implemented
     1473         via a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the
     1474         entire request before processing.
    14741475      </p>
    14751476      <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of
    … …  
    14771478      </p>
    14781479      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2>
    1479       <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a canceled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>.
    1480       </p>
    1481       <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number
    1482          of octets or by failure to decode a transfer-encoded message body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received)
    1483          cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error.
    1484       </p>
    1485       <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding
    1486          has not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response
    1487          that has neither chunked transfer encoding nor Content-Length is terminated by closure of the connection, and thus is considered
     1480      <p id="rfc.section.3.4.p.1">A server that receives an incomplete request message, usually due to a canceled request or a triggered time-out exception, <em class="bcp14">MAY</em> send an error response prior to closing the connection.
     1481      </p>
     1482      <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding
     1483         a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. If a response terminates in the middle of the header block (before the empty line is received)
     1484         and the status code might rely on header fields to convey the full meaning of the response, then the client cannot assume
     1485         that meaning has been conveyed; the client might need to repeat the request in order to determine what action to take next.
     1486      </p>
     1487      <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has
     1488         not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response
     1489         that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered
    14881490         complete regardless of the number of message body octets received, provided that the header block was received intact.
    14891491      </p>
    … …  
    14961498      </p>
    14971499      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    1498       <p id="rfc.section.3.5.p.1">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server
    1499          applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then
    1500          the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length.
    1501       </p>
    1502       <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if the server is reading the protocol
    1503          stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF.
     1500      <p id="rfc.section.3.5.p.1">Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a lame workaround for some early
     1501         server applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then
     1502         the user agent <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length.
     1503      </p>
     1504      <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if a server is reading the protocol
     1505         stream at the beginning of a message and receives a CRLF first, the server <em class="bcp14">SHOULD</em> ignore the CRLF.
    15041506      </p>
    15051507      <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, recipients <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR.
    … …  
    15151517      </p>
    15161518      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1>
    1517       <p id="rfc.section.4.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
    1518          to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the
    1519          transfer-coding is a property of the message rather than a property of the representation that is being transferred.
     1519      <p id="rfc.section.4.p.1">Transfer coding names are used to indicate an encoding transformation that has been, can be, or might need to be applied to
     1520         a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer
     1521         coding is a property of the message rather than a property of the representation that is being transferred.
    15201522      </p>
    15211523      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>    = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>
    … …  
    15311533  <a href="#rule.parameter" class="smpl">attribute</a>          = <a href="#rule.token.separators" class="smpl">token</a>
    15321534  <a href="#rule.parameter" class="smpl">value</a>              = <a href="#rule.token.separators" class="smpl">word</a>
    1533 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive and <em class="bcp14">SHOULD</em> be registered within the HTTP Transfer Coding registry, as defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>) header fields.
    1534       </p>
    1535       <div id="rfc.iref.c.7"></div>
     1535</pre><p id="rfc.section.4.p.5">All transfer-coding names are case-insensitive and <em class="bcp14">SHOULD</em> be registered within the HTTP Transfer Coding registry, as defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>) header fields.
     1536      </p>
     1537      <div id="rfc.iref.c.9"></div>
    15361538      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h2>
    1537       <p id="rfc.section.4.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
    1538          indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically generated content to be transferred along with the information necessary
     1539      <p id="rfc.section.4.1.p.1">The chunked transfer coding modifies the body of a message in order to transfer it as a series of chunks, each with its own
     1540         size indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically generated content to be transferred along with the information necessary
    15391541         for the recipient to verify that it has received the full message.
    15401542      </p>
    … …  
    15581560                 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding
    15591561  <a href="#chunked.encoding" class="smpl">qdtext-nf</a>      = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    1560 </pre><p id="rfc.section.4.1.p.3">Chunk extensions within the chucked encoding are deprecated. Senders <em class="bcp14">SHOULD NOT</em> send chunk-ext. Definition of new chunk extensions is discouraged.
    1561       </p>
    1562       <p id="rfc.section.4.1.p.4">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
    1563          by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
     1562</pre><p id="rfc.section.4.1.p.3">Chunk extensions within the chunked transfer coding are deprecated. Senders <em class="bcp14">SHOULD NOT</em> send chunk-ext. Definition of new chunk extensions is discouraged.
     1563      </p>
     1564      <p id="rfc.section.4.1.p.4">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked transfer coding
     1565         is complete when a chunk with a chunk-size of zero is received, possibly followed by a trailer, and finally terminated by
     1566         an empty line.
    15641567      </p>
    15651568      <div id="rfc.iref.t.5"></div>
    … …  
    15691572         status. The trailer <em class="bcp14">MUST NOT</em> contain fields that need to be known before a recipient processes the body, such as <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, and <a href="#header.trailer" class="smpl">Trailer</a>.
    15701573      </p>
    1571       <p id="rfc.section.4.1.1.p.2">When a message includes a message body encoded with the chunked transfer-coding and the sender desires to send metadata in
     1574      <p id="rfc.section.4.1.1.p.2">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in
    15721575         the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> send a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to
    15731576         prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed
    … …  
    15771580</pre><p id="rfc.section.4.1.1.p.4">If no <a href="#header.trailer" class="smpl">Trailer</a> header field is present, the sender of a chunked message body <em class="bcp14">SHOULD</em> send an empty trailer.
    15781581      </p>
    1579       <p id="rfc.section.4.1.1.p.5">A server <em class="bcp14">MUST</em> send an empty trailer with the chunked transfer-coding unless at least one of the following is true:
     1582      <p id="rfc.section.4.1.1.p.5">A server <em class="bcp14">MUST</em> send an empty trailer with the chunked transfer coding unless at least one of the following is true:
    15801583      </p>
    15811584      <ol>
    1582          <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,
     1585         <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,
    15831586         </li>
    15841587         <li>the trailer fields consist entirely of optional metadata and the recipient could use the message (in a manner acceptable to
    … …  
    15911594      </p>
    15921595      <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="decoding.chunked" href="#decoding.chunked">Decoding chunked</a></h3>
    1593       <p id="rfc.section.4.1.2.p.1">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
     1596      <p id="rfc.section.4.1.2.p.1">A process for decoding the chunked transfer coding can be represented in pseudo-code as:</p>
    15941597      <div id="rfc.figure.u.34"></div><pre class="text">  length := 0
    15951598  read chunk-size, chunk-ext (if any) and CRLF
    … …  
    16081611  Remove "chunked" from Transfer-Encoding
    16091612  Remove Trailer from existing header fields
    1610 </pre><p id="rfc.section.4.1.2.p.3">All recipients <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
     1613</pre><p id="rfc.section.4.1.2.p.3">All recipients <em class="bcp14">MUST</em> be able to receive and decode the chunked transfer coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
    16111614      </p>
    16121615      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
    16131616      <p id="rfc.section.4.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
    1614       <div id="rfc.iref.c.8"></div>
     1617      <div id="rfc.iref.c.10"></div>
    16151618      <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h3>
    16161619      <p id="rfc.section.4.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
    … …  
    16311634      <div id="rfc.iref.t.6"></div>
    16321635      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    1633       <p id="rfc.section.4.3.p.1">The "TE" header field in a request indicates what transfer-codings, besides "chunked", the client is willing to accept in
    1634          response, and whether or not the client is willing to accept trailer fields in a chunked transfer-coding.
    1635       </p>
    1636       <p id="rfc.section.4.3.p.2">The TE field-value consists of a comma-separated list of transfer-coding names, each allowing for optional parameters (as
    1637          described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), and/or the keyword "trailers". Clients <em class="bcp14">MUST NOT</em> send the chunked transfer-coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.
     1636      <p id="rfc.section.4.3.p.1">The "TE" header field in a request indicates what transfer codings, besides chunked, the client is willing to accept in response,
     1637         and whether or not the client is willing to accept trailer fields in a chunked transfer coding.
     1638      </p>
     1639      <p id="rfc.section.4.3.p.2">The TE field-value consists of a comma-separated list of transfer coding names, each allowing for optional parameters (as
     1640         described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), and/or the keyword "trailers". Clients <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.
    16381641      </p>
    16391642      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
    … …  
    16461649  TE:
    16471650  TE: trailers, deflate;q=0.5
    1648 </pre><p id="rfc.section.4.3.p.6">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    1649          as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>, on behalf of itself and any downstream clients. For chained requests, this implies that either: (a) all downstream clients
     1651</pre><p id="rfc.section.4.3.p.6">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer
     1652         coding, as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>, on behalf of itself and any downstream clients. For chained requests, this implies that either: (a) all downstream clients
    16501653         are willing to accept trailer fields in the forwarded response; or, (b) the client will attempt to buffer the response on
    16511654         behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response such
    16521655         that a client can be assured of buffering the entire response.
    16531656      </p>
    1654       <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
     1657      <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
    16551658         fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.16"><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;
    16561659         a value of 0 means "not acceptable".
    16571660      </p>
    1658       <p id="rfc.section.4.3.p.8">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with
    1659          no transfer-coding is always acceptable.
     1661      <p id="rfc.section.4.3.p.8">If the TE field-value is empty or if no TE field is present, the only acceptable transfer coding is chunked. A message with
     1662         no transfer coding is always acceptable.
    16601663      </p>
    16611664      <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
    … …  
    17251728         <p id="rfc.section.5.3.p.9"><span id="rfc.iref.a.2"></span> When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send the target URI in absolute-form as the request-target. The proxy is requested to either service that request from a valid
    17261729            cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to
    1727             the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in <a href="#message.forwarding" title="Message Forwarding">Section&nbsp;5.6</a>.
     1730            the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in <a href="#message.forwarding" title="Message Forwarding">Section&nbsp;5.7</a>.
    17281731         </p>
    17291732      </div>
    … …  
    18171820         the effective request URI's authority component.
    18181821      </p>
    1819       <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="message.forwarding" href="#message.forwarding">Message Forwarding</a></h2>
    1820       <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used
     1822      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
     1823      <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
     1824         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
     1825         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 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
     1826      </p>
     1827      <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
     1828         (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
     1829      </p>
     1830      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="message.forwarding" href="#message.forwarding">Message Forwarding</a></h2>
     1831      <p id="rfc.section.5.7.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used
    18211832         to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has
    18221833         characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can
    18231834         enhance (or interfere) with either direction of the stream.
    18241835      </p>
    1825       <p id="rfc.section.5.6.p.2">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>, to exclude fields that are only intended for the incoming connection.
    1826       </p>
    1827       <p id="rfc.section.5.6.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
     1836      <p id="rfc.section.5.7.p.2">Intermediaries that forward a message <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;6.1</a>, to exclude fields that are only intended for the incoming connection.
     1837      </p>
     1838      <p id="rfc.section.5.7.p.3">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
    18281839      </p>
    18291840      <div id="rfc.iref.v.1"></div>
    1830       <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    1831       <p id="rfc.section.5.7.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway in forwarded messages to indicate the intermediate protocols and recipients between the user
     1841      <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h3>
     1842      <p id="rfc.section.5.7.1.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway in forwarded messages to indicate the intermediate protocols and recipients between the user
    18321843         agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received"
    18331844         field used by email systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>). Via is used in HTTP for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of
    … …  
    18401851  <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
    18411852  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1842 </pre><p id="rfc.section.5.7.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
     1853</pre><p id="rfc.section.5.7.1.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    18431854         the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
    18441855         so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    18451856      </p>
    1846       <p id="rfc.section.5.7.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
     1857      <p id="rfc.section.5.7.1.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
    18471858         number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    18481859         be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
    18491860      </p>
    1850       <p id="rfc.section.5.7.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    1851       </p>
    1852       <p id="rfc.section.5.7.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    1853       </p>
    1854       <p id="rfc.section.5.7.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
     1861      <p id="rfc.section.5.7.1.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
     1862      </p>
     1863      <p id="rfc.section.5.7.1.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
     1864      </p>
     1865      <p id="rfc.section.5.7.1.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    18551866         HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
    18561867         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    18571868      </p>
    18581869      <div id="rfc.figure.u.52"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    1859 </pre><p id="rfc.section.5.7.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
     1870</pre><p id="rfc.section.5.7.1.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    18601871         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    18611872      </p>
    1862       <p id="rfc.section.5.7.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
     1873      <p id="rfc.section.5.7.1.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
    18631874         values. For example,
    18641875      </p>
    18651876      <div id="rfc.figure.u.53"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    1866 </pre><p id="rfc.section.5.7.p.12">could be collapsed to</p>
     1877</pre><p id="rfc.section.5.7.1.p.12">could be collapsed to</p>
    18671878      <div id="rfc.figure.u.54"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    1868 </pre><p id="rfc.section.5.7.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
     1879</pre><p id="rfc.section.5.7.1.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    18691880         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    18701881      </p>
    1871       <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;<a id="message.transforming" href="#message.transforming">Message Transforming</a></h2>
    1872       <p id="rfc.section.5.8.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
    1873       </p>
    1874       <p id="rfc.section.5.8.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
     1882      <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a id="message.transformation" href="#message.transformation">Transformation</a></h3>
     1883      <p id="rfc.section.5.7.2.p.1">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
     1884      </p>
     1885      <p id="rfc.section.5.7.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
    18751886         except as noted above to replace an empty path with "/" or "*".
    18761887      </p>
    1877       <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    1878       </p>
    1879       <p id="rfc.section.5.8.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
     1888      <p id="rfc.section.5.7.2.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     1889      </p>
     1890      <p id="rfc.section.5.7.2.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
    18801891         selected representation.
    18811892      </p>
    1882       <p id="rfc.section.5.8.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
     1893      <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
    18831894      </p>
    18841895      <ul>
    1885          <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    1886          </li>
    1887          <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1896         <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1897         </li>
     1898         <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    18881899         </li>
    18891900         <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)
    … …  
    18931904         <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>)
    18941905         </li>
    1895          <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1906         <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    18961907         </li>
    18971908      </ul>
    1898       <p id="rfc.section.5.8.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field.
    1899       </p>
    1900       <p id="rfc.section.5.8.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive:
     1909      <p id="rfc.section.5.7.2.p.6">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field (<a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) if already present in a response, but it <em class="bcp14">MAY</em> add an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field with a field-value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field.
     1910      </p>
     1911      <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive:
    19011912      </p>
    19021913      <ul>
    1903          <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1914         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    19041915         </li>
    19051916         <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>)
    19061917         </li>
    1907          <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1.5</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1918         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1.5</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    19081919         </li>
    19091920      </ul>
    1910       <p id="rfc.section.5.8.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    1911       </p>
    1912       <div class="note" id="rfc.section.5.8.p.9">
     1921      <p id="rfc.section.5.7.2.p.8">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     1922      </p>
     1923      <div class="note" id="rfc.section.5.7.2.p.9">
    19131924         <p> <b>Warning:</b> Unnecessary modification of header fields might cause authentication failures if stronger authentication mechanisms are introduced
    19141925            in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
    19151926         </p>
    19161927      </div>
    1917       <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    1918       <p id="rfc.section.5.9.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    1919          messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1920          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 7.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>) precede a final response to the same request.
    1921       </p>
    1922       <p id="rfc.section.5.9.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
    1923       </p>
    19241928      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connection.management" href="#connection.management">Connection Management</a></h1>
    19251929      <p id="rfc.section.6.p.1">HTTP messaging is independent of the underlying transport or session-layer connection protocol(s). HTTP only presumes a reliable
    … …  
    19361940         queues to enable fair use and detect denial of service attacks.
    19371941      </p>
    1938       <div id="rfc.iref.c.9"></div>
    1939       <div id="rfc.iref.c.10"></div>
     1942      <div id="rfc.iref.c.11"></div>
     1943      <div id="rfc.iref.c.12"></div>
    19401944      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    19411945      <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to
    … …  
    20802084         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection.
    20812085      </p>
    2082       <div id="rfc.iref.c.11"></div>
    2083       <div id="rfc.iref.c.12"></div>
     2086      <div id="rfc.iref.c.13"></div>
     2087      <div id="rfc.iref.c.14"></div>
    20842088      <h3 id="rfc.section.6.2.5"><a href="#rfc.section.6.2.5">6.2.5</a>&nbsp;<a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h3>
    20852089      <p id="rfc.section.6.2.5.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair.
    … …  
    22162220                  <td class="left">http</td>
    22172221                  <td class="left">standard</td>
    2218                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7</a>
     2222                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7.1</a>
    22192223                  </td>
    22202224               </tr>
    … …  
    28362840      </p>
    28372841      <h3 id="rfc.section.A.1.3"><a href="#rfc.section.A.1.3">A.1.3</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h3>
    2838       <p id="rfc.section.A.1.3.p.1">HTTP/1.1 introduces the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;3.3.1</a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
     2842      <p id="rfc.section.A.1.3.p.1">HTTP/1.1 introduces the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;3.3.1</a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer coding prior to forwarding a message via a MIME-compliant protocol.
    28392843      </p>
    28402844      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    28772881      <p id="rfc.section.A.2.p.17">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;3.3.2</a>)
    28782882      </p>
    2879       <p id="rfc.section.A.2.p.18">The "identity" transfer-coding value token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>)
     2883      <p id="rfc.section.A.2.p.18">The "identity" transfer coding token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>)
    28802884      </p>
    28812885      <p id="rfc.section.A.2.p.19">The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven
    … …  
    31063110                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.4</b></a></li>
    31073111                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li>
    3108                   <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">4.1</a></li>
     3112                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li>
    31093113                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    3110                   <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.10"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.12">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
    3111                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">4.2.1</a></li>
     3114                  <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.14">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3115                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
    31123116                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3113                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.9"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.11">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
    3114                   <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li>
     3117                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.13">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3118                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li>
    31153119               </ul>
    31163120            </li>
    … …  
    31793183                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    31803184                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    3181                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>5.7</b></a></li>
    3182                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.7</b></a></li>
    3183                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>5.7</b></a></li>
     3185                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>5.7.1</b></a></li>
     3186                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.7.1</b></a></li>
     3187                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>5.7.1</b></a></li>
    31843188                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.6</b></a></li>
    31853189                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>4.1</b></a></li>
    … …  
    31913195                        <li><tt>rank</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>4.3</b></a></li>
    31923196                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.2</b></a></li>
    3193                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>5.7</b></a></li>
    3194                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>5.7</b></a></li>
     3197                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>5.7.1</b></a></li>
     3198                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>5.7.1</b></a></li>
    31953199                        <li><tt>request-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>3.1.1</b></a></li>
    31963200                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.3</b></a></li>
    … …  
    32173221                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>4</b></a></li>
    32183222                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3219                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>5.7</b></a></li>
     3223                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>5.7.1</b></a></li>
    32203224                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.6</b></a></li>
    32213225                     </ul>
    … …  
    32673271            </li>
    32683272            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3269                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">5.8</a>, <a href="#rfc.xref.Part2.23">5.8</a>, <a href="#rfc.xref.Part2.24">5.8</a>, <a href="#rfc.xref.Part2.25">5.8</a>, <a href="#rfc.xref.Part2.26">5.9</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3273                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.6</a>, <a href="#rfc.xref.Part2.21">5.7.2</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    32703274                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    3271                         <li><em>Section 3.1.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.8</a></li>
     3275                        <li><em>Section 3.1.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.7.2</a></li>
    32723276                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.30">7.4</a></li>
    3273                         <li><em>Section 3.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.8</a></li>
    3274                         <li><em>Section 3.1.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.8</a></li>
    3275                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
     3277                        <li><em>Section 3.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.7.2</a></li>
     3278                        <li><em>Section 3.1.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.7.2</a></li>
     3279                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.7.2</a></li>
    32763280                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    32773281                        <li><em>Section 5.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a></li>
    … …  
    32813285                        <li><em>Section 6.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">4.3</a></li>
    32823286                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>
    3283                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.9</a></li>
     3287                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.6</a></li>
    32843288                        <li><em>Section 7.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    32853289                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.3</a></li>
    … …  
    32873291                        <li><em>Section 7.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">8.6</a></li>
    32883292                        <li><em>Section 8.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    3289                         <li><em>Section 8.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.8</a></li>
    3290                         <li><em>Section 8.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.8</a></li>
     3293                        <li><em>Section 8.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.7.2</a></li>
     3294                        <li><em>Section 8.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.7.2</a></li>
    32913295                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
    32923296                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    32933297                     </ul>
    32943298                  </li>
    3295                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.8</a>, <a href="#rfc.xref.Part4.5">5.8</a>, <a href="#Part4"><b>10.1</b></a><ul>
    3296                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.8</a></li>
    3297                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.8</a></li>
     3299                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#rfc.xref.Part4.4">5.7.2</a>, <a href="#rfc.xref.Part4.5">5.7.2</a>, <a href="#Part4"><b>10.1</b></a><ul>
     3300                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.7.2</a></li>
     3301                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.7.2</a></li>
    32983302                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li>
    32993303                     </ul>
    33003304                  </li>
    3301                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.8</a>, <a href="#Part5"><b>10.1</b></a><ul>
    3302                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">5.8</a></li>
     3305                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#rfc.xref.Part5.2">5.7.2</a>, <a href="#Part5"><b>10.1</b></a><ul>
     3306                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">5.7.2</a></li>
    33033307                     </ul>
    33043308                  </li>
    3305                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.8</a>, <a href="#rfc.xref.Part6.8">5.8</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
     3309                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.5">3.4</a>, <a href="#rfc.xref.Part6.6">5.2</a>, <a href="#rfc.xref.Part6.7">5.7.2</a>, <a href="#rfc.xref.Part6.8">5.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
    33063310                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.4</a></li>
    33073311                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">3.4</a></li>
    33083312                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.7.2</a>, <a href="#rfc.xref.Part6.9">6.1</a></li>
    3309                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.7">5.8</a></li>
    3310                         <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.8">5.8</a></li>
     3313                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.7">5.7.2</a></li>
     3314                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.8">5.7.2</a></li>
    33113315                     </ul>
    33123316                  </li>
    … …  
    33383342                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li>
    33393343                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">1</a>, <a href="#rfc.xref.RFC2145.2">9</a>, <a href="#RFC2145"><b>10.2</b></a></li>
    3340                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">5.8</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a><ul>
    3341                         <li><em>Section 14.15</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.3">5.8</a></li>
     3344                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.6</a>, <a href="#rfc.xref.RFC2616.3">5.7.2</a>, <a href="#rfc.xref.RFC2616.4">9</a>, <a href="#rfc.xref.RFC2616.5">9</a>, <a href="#RFC2616"><b>10.2</b></a><ul>
     3345                        <li><em>Section 14.15</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.3">5.7.2</a></li>
    33423346                        <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">9</a></li>
    33433347                     </ul>
    … …  
    33813385                  </li>
    33823386                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#rfc.xref.RFC5246.2">2.7.2</a>, <a href="#RFC5246"><b>10.2</b></a></li>
    3383                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7</a>, <a href="#RFC5322"><b>10.2</b></a><ul>
    3384                         <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.7</a></li>
     3387                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7.1</a>, <a href="#RFC5322"><b>10.2</b></a><ul>
     3388                        <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.7.1</a></li>
    33853389                     </ul>
    33863390                  </li>
    … …  
    34063410            </li>
    34073411            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3408                   <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">5.7</a>, <a href="#rfc.iref.u.5"><b>6.3</b></a>, <a href="#rfc.xref.header.upgrade.2">7.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
     3412                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">5.7.1</a>, <a href="#rfc.iref.u.5"><b>6.3</b></a>, <a href="#rfc.xref.header.upgrade.2">7.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    34093413                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    34103414                  <li>URI scheme&nbsp;&nbsp;
    … …  
    34193423            </li>
    34203424            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3421                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.v.1"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
     3425                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
    34223426               </ul>
    34233427            </li>

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

    r2030 r2031  
    14781478<section title="Transfer-Encoding" anchor="header.transfer-encoding">
    14791479  <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/>
     1480  <iref item="chunked (Coding Format)"/>
    14801481  <x:anchor-alias value="Transfer-Encoding"/>
    14811482<t>
    1482    When one or more transfer codings are applied to a payload body in order
    1483    to form the message body, a Transfer-Encoding header field &MUST; be sent
    1484    in the message and &MUST; contain the list of corresponding
    1485    transfer-coding names in the same order that they were applied.
     1483   The Transfer-Encoding header field lists the transfer coding names
     1484   corresponding to the sequence of transfer codings that have been
     1485   (or will be) applied to the payload body in order to form the message body.
    14861486   Transfer codings are defined in <xref target="transfer.codings"/>.
    14871487</t>
    … …  
    14971497   accurately delimit a dynamically generated payload and to distinguish
    14981498   payload encodings that are only applied for transport efficiency or
    1499    security from those that are characteristics of the target resource.
    1500 </t>
    1501 <t>
    1502    The "chunked" transfer-coding (<xref target="chunked.encoding"/>)
    1503    &MUST; be implemented by all HTTP/1.1 recipients because it plays a
    1504    crucial role in delimiting messages when the payload body size is not
    1505    known in advance.
    1506    When the "chunked" transfer-coding is used, it &MUST; be the last
    1507    transfer-coding applied to form the message body and &MUST-NOT;
    1508    be applied more than once in a message body.
    1509    If any transfer-coding is applied to a request payload body,
    1510    the final transfer-coding applied &MUST; be "chunked".
    1511    If any transfer-coding is applied to a response payload body, then either
    1512    the final transfer-coding applied &MUST; be "chunked" or
    1513    the message &MUST; be terminated by closing the connection.
     1499   security from those that are characteristics of the selected resource.
     1500</t>
     1501<t>
     1502   All HTTP/1.1 recipients &MUST; implement the chunked transfer coding
     1503   (<xref target="chunked.encoding"/>) because it plays a crucial role in
     1504   framing messages when the payload body size is not known in advance.
     1505   If chunked is applied to a payload body, the sender &MUST-NOT; apply
     1506   chunked more than once (i.e., chunking an already chunked message is not
     1507   allowed).
     1508   If any transfer coding is applied to a request payload body, the
     1509   sender &MUST; apply chunked as the final transfer coding to ensure that
     1510   the message is properly framed.
     1511   If any transfer coding is applied to a response payload body, the
     1512   sender &MUST; either apply chunked as the final transfer coding or
     1513   terminate the message by closing the connection.
    15141514</t>
    15151515<figure><preamble>
    … …  
    15231523</postamble></figure>
    15241524<t>
    1525    If more than one Transfer-Encoding header field is present in a message,
    1526    the multiple field-values &MUST; be combined into one field-value,
    1527    according to the algorithm defined in <xref target="header.fields"/>,
    1528    before determining the message body length.
    1529 </t>
    1530 <t>
    15311525   Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;),
    1532    Transfer-Encoding is a property of the message, not of the payload, and thus
    1533    &MAY; be added or removed by any implementation along the request/response
    1534    chain. Additional information about the encoding parameters &MAY; be
     1526   Transfer-Encoding is a property of the message, not of the payload, and
     1527   any recipient along the request/response chain &MAY; decode the received
     1528   transfer coding(s) or apply additional transfer coding(s) to the message
     1529   body, assuming that corresponding changes are made to the Transfer-Encoding
     1530   field-value. Additional information about the encoding parameters &MAY; be
    15351531   provided by other header fields not defined by this specification.
    15361532</t>
    … …  
    15571553</t>
    15581554<t>
    1559    A server that receives a request message with a transfer-coding it does
    1560    not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref> and then
    1561    close the connection.
     1555   A server that receives a request message with a transfer coding it does
     1556   not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref>.
    15621557</t>
    15631558</section>
    … …  
    16361631
    16371632<section title="Message Body Length" anchor="message.body.length">
     1633  <iref item="chunked (Coding Format)"/>
    16381634<t>
    16391635   The length of a message body is determined by one of the following
    … …  
    16591655    <x:lt><t>
    16601656     If a <x:ref>Transfer-Encoding</x:ref> header field is present
    1661      and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
     1657     and the chunked transfer coding (<xref target="chunked.encoding"/>)
    16621658     is the final encoding, the message body length is determined by reading
    1663      and decoding the chunked data until the transfer-coding indicates the
     1659     and decoding the chunked data until the transfer coding indicates the
    16641660     data is complete.
    16651661    </t>
    16661662    <t>
    16671663     If a <x:ref>Transfer-Encoding</x:ref> header field is present in a
    1668      response and the "chunked" transfer-coding is not the final encoding, the
     1664     response and the chunked transfer coding is not the final encoding, the
    16691665     message body length is determined by reading the connection until it is
    16701666     closed by the server.
    1671      If a Transfer-Encoding header field is present in a request and the
    1672      "chunked" transfer-coding is not the final encoding, the message body
     1667     If a <x:ref>Transfer-Encoding</x:ref> header field is present in a request and the
     1668     chunked transfer coding is not the final encoding, the message body
    16731669     length cannot be determined reliably; the server &MUST; respond with
    16741670     the <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    … …  
    16761672    <t>
    16771673     If a message is received with both a <x:ref>Transfer-Encoding</x:ref>
    1678      and a <x:ref>Content-Length</x:ref> header field, the
    1679      Transfer-Encoding overrides the Content-Length.
    1680      Such a message might indicate an attempt to perform request or response
    1681      smuggling (bypass of security-related checks on message routing or content)
    1682      and thus ought to be handled as an error.  The provided Content-Length &MUST;
    1683      be removed, prior to forwarding the message downstream, or replaced with
    1684      the real message body length after the transfer-coding is decoded.
     1674     and a <x:ref>Content-Length</x:ref> header field, the Transfer-Encoding
     1675     overrides the Content-Length. Such a message might indicate an attempt
     1676     to perform request or response smuggling (bypass of security-related
     1677     checks on message routing or content) and thus ought to be handled as
     1678     an error.  A sender &MUST; remove the received Content-Length field
     1679     prior to forwarding such a message downstream.
    16851680    </t></x:lt>
    16861681    <x:lt><t>
    … …  
    17371732</t>
    17381733<t>
    1739    Unless a transfer-coding other than "chunked" has been applied,
     1734   Unless a transfer coding other than chunked has been applied,
    17401735   a client that sends a request containing a message body &SHOULD;
    17411736   use a valid <x:ref>Content-Length</x:ref> header field if the message body
    1742    length is known in advance, rather than the "chunked" encoding, since some
    1743    existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref>
    1744    status code even though they understand the chunked encoding.  This
     1737   length is known in advance, rather than the chunked transfer coding, since some
     1738   existing services respond to chunked with a <x:ref>411 (Length Required)</x:ref>
     1739   status code even though they understand the chunked transfer coding.  This
    17451740   is typically because such services are implemented via a gateway that
    17461741   requires a content-length in advance of being called and the server
    … …  
    17591754<section anchor="incomplete.messages" title="Handling Incomplete Messages">
    17601755<t>
    1761    Request messages that are prematurely terminated, possibly due to a
    1762    canceled connection or a server-imposed time-out exception, &MUST;
    1763    result in closure of the connection; sending an error response
    1764    prior to closing the connection is &OPTIONAL;.
    1765 </t>
    1766 <t>
    1767    Response messages that are prematurely terminated, usually by closure
    1768    of the connection prior to receiving the expected number of octets or by
    1769    failure to decode a transfer-encoded message body, &MUST; be recorded
    1770    as incomplete.  A response that terminates in the middle of the header
    1771    block (before the empty line is received) cannot be assumed to convey the
    1772    full semantics of the response and &MUST; be treated as an error.
    1773 </t>
    1774 <t>
    1775    A message body that uses the chunked transfer encoding is
     1756   A server that receives an incomplete request message, usually due to a
     1757   canceled request or a triggered time-out exception, &MAY; send an error
     1758   response prior to closing the connection.
     1759</t>
     1760<t>
     1761   A client that receives an incomplete response message, which can occur
     1762   when a connection is closed prematurely or when decoding a supposedly
     1763   chunked transfer coding fails, &MUST; record the message as incomplete.
     1764   If a response terminates in the middle of the header block (before the
     1765   empty line is received) and the status code might rely on header fields to
     1766   convey the full meaning of the response, then the client cannot assume
     1767   that meaning has been conveyed; the client might need to repeat the
     1768   request in order to determine what action to take next.
     1769</t>
     1770<t>
     1771   A message body that uses the chunked transfer coding is
    17761772   incomplete if the zero-sized chunk that terminates the encoding has not
    17771773   been received.  A message that uses a valid <x:ref>Content-Length</x:ref> is
    17781774   incomplete if the size of the message body received (in octets) is less than
    17791775   the value given by Content-Length.  A response that has neither chunked
    1780    transfer encoding nor Content-Length is terminated by closure of the
     1776   transfer coding nor Content-Length is terminated by closure of the
    17811777   connection, and thus is considered complete regardless of the number of
    17821778   message body octets received, provided that the header block was received
    … …  
    18021798<section title="Message Parsing Robustness" anchor="message.robustness">
    18031799<t>
    1804    Older HTTP/1.0 client implementations might send an extra CRLF
     1800   Older HTTP/1.0 user agent implementations might send an extra CRLF
    18051801   after a POST request as a lame workaround for some early server
    18061802   applications that failed to read message body content that was
    1807    not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;
     1803   not terminated by a line-ending. An HTTP/1.1 user agent &MUST-NOT;
    18081804   preface or follow a request with an extra CRLF.  If terminating
    18091805   the request message body with a line-ending is desired, then the
    1810    client &MUST; include the terminating CRLF octets as part of the
     1806   user agent &MUST; include the terminating CRLF octets as part of the
    18111807   message body length.
    18121808</t>
    … …  
    18141810   In the interest of robustness, servers &SHOULD; ignore at least one
    18151811   empty line received where a request-line is expected. In other words, if
    1816    the server is reading the protocol stream at the beginning of a
    1817    message and receives a CRLF first, it &SHOULD; ignore the CRLF.
     1812   a server is reading the protocol stream at the beginning of a
     1813   message and receives a CRLF first, the server &SHOULD; ignore the CRLF.
    18181814</t>
    18191815<t>
    … …  
    18451841  <x:anchor-alias value="transfer-extension"/>
    18461842<t>
    1847    Transfer-coding values are used to indicate an encoding
     1843   Transfer coding names are used to indicate an encoding
    18481844   transformation that has been, can be, or might need to be applied to a
    18491845   payload body in order to ensure "safe transport" through the network.
    1850    This differs from a content coding in that the transfer-coding is a
     1846   This differs from a content coding in that the transfer coding is a
    18511847   property of the message rather than a property of the representation
    18521848   that is being transferred.
    … …  
    18721868</artwork></figure>
    18731869<t>
    1874    All transfer-coding values are case-insensitive and &SHOULD; be registered
     1870   All transfer-coding names are case-insensitive and &SHOULD; be registered
    18751871   within the HTTP Transfer Coding registry, as defined in
    18761872   <xref target="transfer.coding.registry"/>.
    … …  
    18811877
    18821878<section title="Chunked Transfer Coding" anchor="chunked.encoding">
    1883   <iref item="chunked (Coding Format)"/>
     1879  <iref primary="true" item="chunked (Coding Format)"/>
    18841880  <x:anchor-alias value="chunk"/>
    18851881  <x:anchor-alias value="chunked-body"/>
    … …  
    18941890  <x:anchor-alias value="qdtext-nf"/>
    18951891<t>
    1896    The chunked encoding modifies the body of a message in order to
     1892   The chunked transfer coding modifies the body of a message in order to
    18971893   transfer it as a series of chunks, each with its own size indicator,
    18981894   followed by an &OPTIONAL; trailer containing header fields. This
    … …  
    19231919</artwork></figure>
    19241920<t>
    1925    Chunk extensions within the chucked encoding are deprecated.
     1921   Chunk extensions within the chunked transfer coding are deprecated.
    19261922   Senders &SHOULD-NOT; send chunk-ext.
    19271923   Definition of new chunk extensions is discouraged.
    … …  
    19291925<t>
    19301926   The chunk-size field is a string of hex digits indicating the size of
    1931    the chunk-data in octets. The chunked encoding is ended by any chunk whose size is
    1932    zero, followed by the trailer, which is terminated by an empty line.
     1927   the chunk-data in octets. The chunked transfer coding is complete when a
     1928   chunk with a chunk-size of zero is received, possibly followed by a
     1929   trailer, and finally terminated by an empty line.
    19331930</t>
    19341931
    … …  
    19471944<t>
    19481945   When a message includes a message body encoded with the chunked
    1949    transfer-coding and the sender desires to send metadata in the form of
     1946   transfer coding and the sender desires to send metadata in the form of
    19501947   trailer fields at the end of the message, the sender &SHOULD; send a
    19511948   <x:ref>Trailer</x:ref> header field before the message body to indicate
    … …  
    19631960</t>
    19641961<t>
    1965    A server &MUST; send an empty trailer with the chunked transfer-coding
     1962   A server &MUST; send an empty trailer with the chunked transfer coding
    19661963   unless at least one of the following is true:
    19671964  <list style="numbers">
    19681965    <t>the request included a <x:ref>TE</x:ref> header field that indicates
    1969     "trailers" is acceptable in the transfer-coding of the response, as
     1966    "trailers" is acceptable in the transfer coding of the response, as
    19701967    described in <xref target="header.te"/>; or,</t>
    19711968     
    … …  
    19871984<section title="Decoding chunked" anchor="decoding.chunked">
    19881985<t>
    1989    A process for decoding the "chunked" transfer-coding
     1986   A process for decoding the chunked transfer coding
    19901987   can be represented in pseudo-code as:
    19911988</t>
    … …  
    20102007<t>
    20112008   All recipients &MUST; be able to receive and decode the
    2012    "chunked" transfer-coding and &MUST; ignore chunk-ext extensions
     2009   chunked transfer coding and &MUST; ignore chunk-ext extensions
    20132010   they do not understand.
    20142011</t>
    … …  
    20662063  <x:anchor-alias value="rank"/>
    20672064<t>
    2068    The "TE" header field in a request indicates what transfer-codings,
    2069    besides "chunked", the client is willing to accept in response, and
     2065   The "TE" header field in a request indicates what transfer codings,
     2066   besides chunked, the client is willing to accept in response, and
    20702067   whether or not the client is willing to accept trailer fields in a
    2071    chunked transfer-coding.
    2072 </t>
    2073 <t>
    2074    The TE field-value consists of a comma-separated list of transfer-coding
     2068   chunked transfer coding.
     2069</t>
     2070<t>
     2071   The TE field-value consists of a comma-separated list of transfer coding
    20752072   names, each allowing for optional parameters (as described in
    20762073   <xref target="transfer.codings"/>), and/or the keyword "trailers".
    2077    Clients &MUST-NOT; send the chunked transfer-coding name in TE;
     2074   Clients &MUST-NOT; send the chunked transfer coding name in TE;
    20782075   chunked is always acceptable for HTTP/1.1 recipients.
    20792076</t>
    … …  
    20952092<t>
    20962093   The presence of the keyword "trailers" indicates that the client is
    2097    willing to accept trailer fields in a chunked transfer-coding,
     2094   willing to accept trailer fields in a chunked transfer coding,
    20982095   as defined in <xref target="chunked.encoding"/>, on behalf of itself and
    20992096   any downstream clients. For chained requests, this implies that either:
    … …  
    21072104</t>
    21082105<t>
    2109    When multiple transfer-codings are acceptable, the client &MAY; rank the
     2106   When multiple transfer codings are acceptable, the client &MAY; rank the
    21102107   codings by preference using a case-insensitive "q" parameter (similar to
    21112108   the qvalues used in content negotiation fields, &qvalue;). The rank value
    … …  
    21152112<t>
    21162113   If the TE field-value is empty or if no TE field is present, the only
    2117    acceptable transfer-coding is "chunked". A message with no transfer-coding
     2114   acceptable transfer coding is chunked. A message with no transfer coding
    21182115   is always acceptable.
    21192116</t>
    … …  
    24632460</section>
    24642461
     2462<section title="Associating a Response to a Request" anchor="associating.response.to.request">
     2463<t>
     2464   HTTP does not include a request identifier for associating a given
     2465   request message with its corresponding one or more response messages.
     2466   Hence, it relies on the order of response arrival to correspond exactly
     2467   to the order in which requests are made on the same connection.
     2468   More than one response message per request only occurs when one or more
     2469   informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a
     2470   final response to the same request.
     2471</t>
     2472<t>
     2473   A client that has more than one outstanding request on a connection &MUST;
     2474   maintain a list of outstanding requests in the order sent and &MUST;
     2475   associate each received response message on that connection to the highest
     2476   ordered request that has not yet received a final (non-<x:ref>1xx</x:ref>)
     2477   response.
     2478</t>
     2479</section>
     2480
    24652481<section title="Message Forwarding" anchor="message.forwarding">
    24662482<t>
    … …  
    24842500   names, including any aliases, local variations, or literal IP addresses.
    24852501</t>
    2486 </section>
    24872502
    24882503<section title="Via" anchor="header.via">
    … …  
    25792594</section>
    25802595
    2581 <section title="Message Transforming" anchor="message.transforming">
     2596<section title="Transformation" anchor="message.transformation">
    25822597<t>
    25832598   If a proxy receives a request-target with a host name that is not a
    … …  
    25942609   A non-transforming proxy &MUST; preserve the message payload (&payload;),
    25952610   though it &MAY; change the message body through application or removal
    2596    of a transfer-coding (<xref target="transfer.codings"/>).
     2611   of a transfer coding (<xref target="transfer.codings"/>).
    25972612</t>
    25982613<t>
    … …  
    26452660</x:note>
    26462661</section>
    2647 
    2648 <section title="Associating a Response to a Request" anchor="associating.response.to.request">
    2649 <t>
    2650    HTTP does not include a request identifier for associating a given
    2651    request message with its corresponding one or more response messages.
    2652    Hence, it relies on the order of response arrival to correspond exactly
    2653    to the order in which requests are made on the same connection.
    2654    More than one response message per request only occurs when one or more
    2655    informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a final response
    2656    to the same request.
    2657 </t>
    2658 <t>
    2659    A client that uses persistent connections and sends more than one request
    2660    per connection &MUST; maintain a list of outstanding requests in the
    2661    order sent on that connection and &MUST; associate each received response
    2662    message to the highest ordered request that has not yet received a final
    2663    (non-<x:ref>1xx</x:ref>) response.
    2664 </t>
    26652662</section>
    26662663</section>
    … …  
    47364733   HTTP/1.1 introduces the <x:ref>Transfer-Encoding</x:ref> header field
    47374734   (<xref target="header.transfer-encoding"/>). Proxies/gateways &MUST; remove
    4738    any transfer-coding prior to forwarding a message via a MIME-compliant
     4735   any transfer coding prior to forwarding a message via a MIME-compliant
    47394736   protocol.
    47404737</t>
    … …  
    48274824</t>
    48284825<t>
    4829   The "identity" transfer-coding value token has been removed.
     4826  The "identity" transfer coding token has been removed.
    48304827  (Sections <xref format="counter" target="message.body"/> and
    48314828  <xref format="counter" target="transfer.codings"/>)

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

    r2030 r2031  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 7, 2013";
     451       content: "Expires June 8, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    496496      <meta name="dct.creator" content="Reschke, J. F.">
    497497      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    498       <meta name="dct.issued" scheme="ISO8601" content="2012-12-04">
     498      <meta name="dct.issued" scheme="ISO8601" content="2012-12-05">
    499499      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    500500      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    524524            <tr>
    525525               <td class="left">Intended status: Standards Track</td>
    526                <td class="right">December 4, 2012</td>
     526               <td class="right">December 5, 2012</td>
    527527            </tr>
    528528            <tr>
    529                <td class="left">Expires: June 7, 2013</td>
     529               <td class="left">Expires: June 8, 2013</td>
    530530               <td class="right"></td>
    531531            </tr>
    … …  
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on June 7, 2013.</p>
     557      <p>This Internet-Draft will expire on June 8, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    16161616      </p>
    16171617      <p id="rfc.section.5.3.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1618          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</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>) 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
     1618         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.17"><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
    16191619         messages in an infinite loop.
    16201620      </p>
    … …  
    30923092</pre><p id="rfc.section.8.4.2.p.4">Example:</p>
    30933093      <div id="rfc.figure.u.62"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    3094 </pre><p id="rfc.section.8.4.2.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.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>).
     3094</pre><p id="rfc.section.8.4.2.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</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>).
    30953095      </p>
    30963096      <div class="note" id="rfc.section.8.4.2.p.7">
    … …  
    41554155         trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section&nbsp;8.4.1</a>)
    41564156      </p>
    4157       <p id="rfc.section.C.p.30">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
     4157      <p id="rfc.section.C.p.30">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
    41584158      </p>
    41594159      <p id="rfc.section.C.p.31">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section&nbsp;3.1.1.2</a>)
    … …  
    41714171      <p id="rfc.section.C.p.36">The Status Code Registry is now defined by this specification; previously, it was defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;9.2</a>)
    41724172      </p>
    4173       <p id="rfc.section.C.p.37">References to the "identity" transfer-coding value token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
     4173      <p id="rfc.section.C.p.37">References to the "identity" transfer coding token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
    41744174      </p>
    41754175      <p id="rfc.section.C.p.38">The Content-Disposition header field is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix&nbsp;B</a>)
    … …  
    42044204<a href="#header.allow" class="smpl">Allow</a> = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
    42054205
    4206 <a href="#imported.abnf" class="smpl">BWS</a> = &lt;BWS, defined in [Part1], Section 3.2.1&gt;
     4206<a href="#imported.abnf" class="smpl">BWS</a> = &lt;BWS, defined in [Part1], Section 3.2.3&gt;
    42074207
    42084208<a href="#header.content-encoding" class="smpl">Content-Encoding</a> = *( "," OWS ) content-coding *( OWS "," [ OWS
    … …  
    42284228<a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*DIGIT
    42294229
    4230 <a href="#imported.abnf" class="smpl">OWS</a> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
    4231 
    4232 <a href="#imported.abnf" class="smpl">RWS</a> = &lt;RWS, defined in [Part1], Section 3.2.1&gt;
     4230<a href="#imported.abnf" class="smpl">OWS</a> = &lt;OWS, defined in [Part1], Section 3.2.3&gt;
     4231
     4232<a href="#imported.abnf" class="smpl">RWS</a> = &lt;RWS, defined in [Part1], Section 3.2.3&gt;
    42334233<a href="#header.referer" class="smpl">Referer</a> = absolute-URI / partial-URI
    42344234<a href="#header.retry-after" class="smpl">Retry-After</a> = HTTP-date / delta-seconds
    … …  
    42504250<a href="#charset" class="smpl">charset</a> = token
    42514251<a href="#header.accept-encoding" class="smpl">codings</a> = content-coding / "identity" / "*"
    4252 <a href="#imported.abnf" class="smpl">comment</a> = &lt;comment, defined in [Part1], Section 3.2.4&gt;
     4252<a href="#imported.abnf" class="smpl">comment</a> = &lt;comment, defined in [Part1], Section 3.2.6&gt;
    42534253<a href="#content.codings" class="smpl">content-coding</a> = token
    42544254
    … …  
    43124312<a href="#product.tokens" class="smpl">product-version</a> = token
    43134313
    4314 <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in [Part1], Section 3.2.4&gt;
     4314<a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in [Part1], Section 3.2.6&gt;
    43154315<a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
    43164316
    … …  
    43224322
    43234323<a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second
    4324 <a href="#imported.abnf" class="smpl">token</a> = &lt;token, defined in [Part1], Section 3.2.4&gt;
     4324<a href="#imported.abnf" class="smpl">token</a> = &lt;token, defined in [Part1], Section 3.2.6&gt;
    43254325<a href="#media.type" class="smpl">type</a> = token
    43264326
    … …  
    43284328
    43294329<a href="#quality.values" class="smpl">weight</a> = OWS ";" OWS "q=" qvalue
    4330 <a href="#imported.abnf" class="smpl">word</a> = &lt;word, defined in [Part1], Section 3.2.4&gt;
     4330<a href="#imported.abnf" class="smpl">word</a> = &lt;word, defined in [Part1], Section 3.2.6&gt;
    43314331
    43324332<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    … …  
    45574557                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">6.1</a></li>
    45584558                        <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>, <a href="#rfc.xref.Part1.27">8</a></li>
    4559                         <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">5.3.8</a>, <a href="#rfc.xref.Part1.29">8.4.2</a>, <a href="#rfc.xref.Part1.44">C</a></li>
     4559                        <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">5.3.8</a>, <a href="#rfc.xref.Part1.29">8.4.2</a>, <a href="#rfc.xref.Part1.44">C</a></li>
    45604560                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">9.3.1</a></li>
    45614561                        <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">7.2.2</a>, <a href="#rfc.xref.Part1.25">7.5.15</a></li>

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

    r2030 r2031  
    58415841</t>
    58425842<t>
    5843   References to the "identity" transfer-coding value token have been removed.
     5843  References to the "identity" transfer coding token have been removed.
    58445844  (<xref target="no.content-transfer-encoding"/>)
    58455845</t>
    … …  
    59115911<x:ref>Allow</x:ref> = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
    59125912
    5913 <x:ref>BWS</x:ref> = &lt;BWS, defined in [Part1], Section 3.2.1&gt;
     5913<x:ref>BWS</x:ref> = &lt;BWS, defined in [Part1], Section 3.2.3&gt;
    59145914
    59155915<x:ref>Content-Encoding</x:ref> = *( "," OWS ) content-coding *( OWS "," [ OWS
    … …  
    59355935<x:ref>Max-Forwards</x:ref> = 1*DIGIT
    59365936
    5937 <x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
    5938 
    5939 <x:ref>RWS</x:ref> = &lt;RWS, defined in [Part1], Section 3.2.1&gt;
     5937<x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 3.2.3&gt;
     5938
     5939<x:ref>RWS</x:ref> = &lt;RWS, defined in [Part1], Section 3.2.3&gt;
    59405940<x:ref>Referer</x:ref> = absolute-URI / partial-URI
    59415941<x:ref>Retry-After</x:ref> = HTTP-date / delta-seconds
    … …  
    59575957<x:ref>charset</x:ref> = token
    59585958<x:ref>codings</x:ref> = content-coding / "identity" / "*"
    5959 <x:ref>comment</x:ref> = &lt;comment, defined in [Part1], Section 3.2.4&gt;
     5959<x:ref>comment</x:ref> = &lt;comment, defined in [Part1], Section 3.2.6&gt;
    59605960<x:ref>content-coding</x:ref> = token
    59615961
    … …  
    60196019<x:ref>product-version</x:ref> = token
    60206020
    6021 <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in [Part1], Section 3.2.4&gt;
     6021<x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in [Part1], Section 3.2.6&gt;
    60226022<x:ref>qvalue</x:ref> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
    60236023
    … …  
    60296029
    60306030<x:ref>time-of-day</x:ref> = hour ":" minute ":" second
    6031 <x:ref>token</x:ref> = &lt;token, defined in [Part1], Section 3.2.4&gt;
     6031<x:ref>token</x:ref> = &lt;token, defined in [Part1], Section 3.2.6&gt;
    60326032<x:ref>type</x:ref> = token
    60336033
    … …  
    60356035
    60366036<x:ref>weight</x:ref> = OWS ";" OWS "q=" qvalue
    6037 <x:ref>word</x:ref> = &lt;word, defined in [Part1], Section 3.2.4&gt;
     6037<x:ref>word</x:ref> = &lt;word, defined in [Part1], Section 3.2.6&gt;
    60386038
    60396039<x:ref>year</x:ref> = 4DIGIT
Note: See TracChangeset for help on using the changeset viewer.