Changeset 2034


Ignore:
Timestamp:
Dec 6, 2012, 11:13:32 AM (7 years ago)
Author:
fielding@…
Message:

Clarify when Content-Length SHOULD be sent. Addresses #420

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

Legend:

Unmodified
Added
Removed

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

    r2033 r2034  
    13811381      <div id="rfc.iref.c.7"></div>
    13821382      <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>
    1383       <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
    1384          sender <em class="bcp14">SHOULD</em> send a Content-Length header field to indicate the length of the payload body as a decimal number of octets.
     1383      <p id="rfc.section.3.3.2.p.1">When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for a potential
     1384         payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information
     1385         necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length
     1386         indicates the size of the selected representation (<a href="p2-semantics.html#selected.representation" title="Selected Representation Header Fields">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    13851387      </p>
    13861388      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    … …  
    13891391</pre><p id="rfc.section.3.3.2.p.5">A sender <em class="bcp14">MUST NOT</em> send a Content-Length header field in any message that contains a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field.
    13901392      </p>
    1391       <p id="rfc.section.3.3.2.p.6">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 5.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
     1393      <p id="rfc.section.3.3.2.p.6">A user agent <em class="bcp14">SHOULD</em> send a Content-Length in a request message when no <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> is sent and the request method defines a meaning for an enclosed payload body. For example, a Content-Length header field
     1394         is normally sent in a POST request even when the value is 0 (indicating an empty payload body). A user agent <em class="bcp14">SHOULD NOT</em> send a Content-Length header field when the request message does not contain a payload body and the method semantics do not
     1395         anticipate such a body.
     1396      </p>
     1397      <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 5.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
    13921398         in the payload body of a response if the same request had used the GET method.
    13931399      </p>
    1394       <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to a conditional GET request (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
     1400      <p id="rfc.section.3.3.2.p.8">A server <em class="bcp14">MAY</em> send a Content-Length header field in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to a conditional GET request (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
    13951401         in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    13961402      </p>
    1397       <p id="rfc.section.3.3.2.p.8">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">SHOULD NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    1398       </p>
    1399       <p id="rfc.section.3.3.2.p.9">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
     1403      <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">SHOULD NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1404      </p>
     1405      <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header block. This will
     1406         allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse
     1407         the connection for additional requests.
     1408      </p>
     1409      <p id="rfc.section.3.3.2.p.11">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
    14001410         an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section&nbsp;8.6</a>).
    14011411      </p>
    1402       <p id="rfc.section.3.3.2.p.10">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value,
     1412      <p id="rfc.section.3.3.2.p.12">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value,
    14031413         or a single Content-Length header field with a field value containing a list of identical decimal values (e.g., "Content-Length:
    14041414         42, 42"), indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor,
    … …  
    14061416         that decimal value prior to determining the message body length.
    14071417      </p>
    1408       <div class="note" id="rfc.section.3.3.2.p.11">
     1418      <div class="note" id="rfc.section.3.3.2.p.13">
    14091419         <p> <b>Note:</b> HTTP's use of Content-Length for message framing differs significantly from the same field's use in MIME, where it is an optional
    14101420            field used only within the "message/external-body" media-type.
    … …  
    16491659      </p>
    16501660      <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
    1651          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;
     1661         fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.17"><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;
    16521662         a value of 0 means "not acceptable".
    16531663      </p>
    … …  
    16701680      </p>
    16711681      <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1672          are defined in <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers are reserved
     1682         are defined in <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment identifier component, if any, since fragment identifiers are reserved
    16731683         for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.16"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    16741684      </p>
    … …  
    17291739      </p>
    17301740      <div id="authority-form">
    1731          <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
     1741         <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
    17321742         </p>
    17331743      </div>
    17341744      <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    17351745</pre><div id="asterisk-form">
    1736          <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 5.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
     1746         <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 5.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
    17371747            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    17381748         </p>
    … …  
    18161826      <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
    18171827         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1818          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.
     1828         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.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
    18191829      </p>
    18201830      <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
    … …  
    18791889         except as noted above to replace an empty path with "/" or "*".
    18801890      </p>
    1881       <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>).
     1891      <p id="rfc.section.5.7.2.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    18821892      </p>
    18831893      <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
    … …  
    18871897      </p>
    18881898      <ul>
    1889          <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>)
    1890          </li>
    1891          <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>)
     1899         <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1900         </li>
     1901         <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    18921902         </li>
    18931903         <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>)
    … …  
    18971907         <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>)
    18981908         </li>
    1899          <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>)
     1909         <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    19001910         </li>
    19011911      </ul>
    … …  
    19051915      </p>
    19061916      <ul>
    1907          <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>)
     1917         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    19081918         </li>
    19091919         <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>)
    19101920         </li>
    1911          <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>)
     1921         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    19121922         </li>
    19131923      </ul>
    … …  
    20122022      <p id="rfc.section.6.3.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    20132023      </p>
    2014       <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2024      <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    20152025         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    20162026      </p>
    … …  
    20182028      <p id="rfc.section.6.3.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover
    20192029         from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence
    2020          is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding
     2030         is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding
    20212031         of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails.
    20222032      </p>
    … …  
    21112121      </p>
    21122122      <p id="rfc.section.6.7.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used
    2113          to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2123         to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    21142124      </p>
    21152125      <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    … …  
    23722382         <li>Pointer to specification text</li>
    23732383      </ul>
    2374       <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2384      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    23752385      </p>
    23762386      <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. Use of program names for the identification of encoding
    … …  
    25272537         that most implementations will choose substantially higher limits.
    25282538      </p>
    2529       <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2539      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    25302540      </p>
    25312541      <p id="rfc.section.8.6.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
    … …  
    32553265            </li>
    32563266            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3257                   <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.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">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>
     3267                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">5.7.2</a>, <a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a>, <a href="#rfc.xref.Part2.30">6.7</a>, <a href="#rfc.xref.Part2.31">7.4</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#rfc.xref.Part2.33">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    32583268                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    3259                         <li><em>Section 3.1.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.7.2</a></li>
    3260                         <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>
    3261                         <li><em>Section 3.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.7.2</a></li>
    3262                         <li><em>Section 3.1.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.7.2</a></li>
    3263                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.7.2</a></li>
     3269                        <li><em>Section 3.1.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">5.7.2</a></li>
     3270                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.31">7.4</a></li>
     3271                        <li><em>Section 3.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">5.7.2</a></li>
     3272                        <li><em>Section 3.1.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.7.2</a></li>
     3273                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.7.2</a></li>
    32643274                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3265                         <li><em>Section 5.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a></li>
    3266                         <li><em>Section 5.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.2</a></li>
    3267                         <li><em>Section 5.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.18">5.3</a></li>
    3268                         <li><em>Section 5.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">5.3</a></li>
    3269                         <li><em>Section 6.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">4.3</a></li>
     3275                        <li><em>Section 5.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a></li>
     3276                        <li><em>Section 5.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li>
     3277                        <li><em>Section 5.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li>
     3278                        <li><em>Section 5.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.3</a></li>
     3279                        <li><em>Section 6.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">4.3</a></li>
    32703280                        <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>
    3271                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.6</a></li>
     3281                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.6</a></li>
    32723282                        <li><em>Section 7.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    3273                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.7</a></li>
    3274                         <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.32">8.6</a></li>
    3275                         <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>
     3283                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">6.7</a></li>
     3284                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.33">8.6</a></li>
     3285                        <li><em>Section 7.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.32">8.6</a></li>
    32763286                        <li><em>Section 8.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    3277                         <li><em>Section 8.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.7.2</a></li>
    3278                         <li><em>Section 8.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.7.2</a></li>
     3287                        <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.2</a></li>
     3288                        <li><em>Section 8.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.7.2</a></li>
     3289                        <li><em>Section 8.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.7.2</a></li>
    32793290                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
    32803291                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>

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

    r2033 r2034  
    4848  <!ENTITY qvalue                 "<xref target='Part2' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4949  <!ENTITY resource               "<xref target='Part2' x:rel='#resource' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     50  <!ENTITY selected-representation    "<xref target='Part2' x:rel='#selected.representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5051  <!ENTITY status-codes           "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5152  <!ENTITY status-1xx             "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    15621563  <x:anchor-alias value="Content-Length"/>
    15631564<t>
    1564    When a message is allowed to contain a message body, does not have a
    1565    <x:ref>Transfer-Encoding</x:ref> header field, and has a payload body
    1566    length that is known to the sender before the message header section has
    1567    been sent, the sender &SHOULD; send a Content-Length header field to
    1568    indicate the length of the payload body as a decimal number of octets.
     1565   When a message does not have a <x:ref>Transfer-Encoding</x:ref> header
     1566   field, a Content-Length header field can provide the anticipated size,
     1567   as a decimal number of octets, for a potential payload body.
     1568   For messages that do include a payload body, the Content-Length field-value
     1569   provides the framing information necessary for determining where the body
     1570   (and message) ends.  For messages that do not include a payload body, the
     1571   Content-Length indicates the size of the selected representation
     1572   (&selected-representation;).
    15691573</t>
    15701574<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>
    … …  
    15801584   A sender &MUST-NOT; send a Content-Length header field in any message that
    15811585   contains a <x:ref>Transfer-Encoding</x:ref> header field.
     1586</t>
     1587<t>
     1588   A user agent &SHOULD; send a Content-Length in a request message when no
     1589   <x:ref>Transfer-Encoding</x:ref> is sent and the request method defines
     1590   a meaning for an enclosed payload body. For example, a Content-Length
     1591   header field is normally sent in a POST request even when the value is
     1592   0 (indicating an empty payload body).  A user agent &SHOULD-NOT; send a
     1593   Content-Length header field when the request message does not contain a
     1594   payload body and the method semantics do not anticipate such a body.
    15821595</t>
    15831596<t>
    … …  
    16021615   A server &SHOULD-NOT; send a Content-Length header field in any
    16031616   <x:ref>2xx (Successful)</x:ref> response to a CONNECT request (&CONNECT;).
     1617</t>
     1618<t>
     1619   Aside from the cases defined above, in the absence of Transfer-Encoding,
     1620   an origin server &SHOULD; send a Content-Length header field when the
     1621   payload body size is known prior to sending the complete header block.
     1622   This will allow downstream recipients to measure transfer progress,
     1623   know when a received message is complete, and potentially reuse the
     1624   connection for additional requests.
    16041625</t>
    16051626<t>
Note: See TracChangeset for help on using the changeset viewer.