Changeset 852


Ignore:
Timestamp:
Jul 16, 2010, 10:56:53 PM (9 years ago)
Author:
fielding@…
Message:

Changed message-body ABNF to be *OCTET. Specifying the actual
number of octets will have to be done in prose.

Moved mistitled "Message Length" section into the Message Body
section, since it only explains how many octets are in the body.
Deleted useless "Entity Length" section and transfer-length term.

Addresses #28: Connection closing

Removed redundant mention of terminating by connection close
and rewrote explanation so that it doesn't self-contradict.

Addresses #90: Delimiting messages with multipart/byteranges

Removed message-delimiting paragraphs of multipart/byteranges
from p1 and p3.

Addresses #95: Handling multiple Content-Length headers

Added requirements for what to do if multiple or invalid
Content-Length is received.

Rephrased requirements for Transfer-Encoding to only apply
when a transfer-coding is present. Clarify that Transfer-Encoding
overrides Content-Length and treat receiving both as an error.
Clarify that only the chunked transfer-coding can delimit a
message (the original design allowed other self-descriptive
encodings, but that was abandoned in 2616).

Addresses #109: Clarify entity / representation / variant terminology

Entity-body terminology changed to payload in order to clarify that
it is what gets packaged (as a message-body) into a message,
allowing us to (eventually) distinguish between messages containing
whole representations and messages containing only partial
representations. Reduce use of the same terms for other things
(e.g., in explanation of dates).

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

Legend:

Unmodified
Added
Removed

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

    r849 r852  
    1616  <!ENTITY ID-YEAR "2010">
    1717  <!ENTITY caching-overview       "<xref target='Part6' x:rel='#caching.overview' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     18  <!ENTITY cache-incomplete       "<xref target='Part6' x:rel='#errors.or.incomplete.response.cache.behavior' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY payload                "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY media-types            "<xref target='Part3' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    2122  <!ENTITY CONNECT                "<xref target='Part2' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2223  <!ENTITY content.negotiation    "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    23   <!ENTITY diff2045entity         "<xref target='Part3' x:rel='#differences.between.http.entities.and.rfc.2045.entities' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     24  <!ENTITY diff-mime              "<xref target='Part3' x:rel='#differences.between.http.entities.and.rfc.2045.entities' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2425  <!ENTITY entity                 "<xref target='Part3' x:rel='#entity' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    25   <!ENTITY entity-body            "<xref target='Part3' x:rel='#entity.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2626  <!ENTITY entity-header-fields   "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    27   <!ENTITY entity-length          "<xref target='Part3' x:rel='#entity.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2827  <!ENTITY header-cache-control   "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2928  <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    236235   Messages are passed in a format similar to that used by Internet mail
    237236   <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
    238    (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences
     237   (MIME) <xref target="RFC2045"/> (see &diff-mime; for the differences
    239238   between HTTP and MIME messages).
    240239</t>
    … …  
    421420  <x:anchor-alias value="CRLF"/>
    422421   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
    423    protocol elements except the entity-body (see <xref target="tolerant.applications"/> for
    424    tolerant applications). The end-of-line marker within an entity-body
    425    is defined by its associated media type, as described in &media-types;.
     422   protocol elements other than the message-body
     423   (see <xref target="tolerant.applications"/> for tolerant applications).
    426424</t>
    427425<t anchor="rule.LWS">
    … …  
    522520  <x:anchor-alias value="request-header"/>
    523521  <x:anchor-alias value="response-header"/>
    524   <x:anchor-alias value="entity-body"/>
    525522  <x:anchor-alias value="entity-header"/>
    526523  <x:anchor-alias value="Cache-Control"/>
    … …  
    535532</artwork></figure>
    536533<figure><!-- Part3--><artwork type="abnf2616">
    537   <x:ref>entity-body</x:ref>     = &lt;entity-body, defined in &entity-body;&gt;
    538534  <x:ref>entity-header</x:ref>   = &lt;entity-header, defined in &entity-header-fields;&gt;
    539535</artwork></figure>
    … …  
    10581054   differ only in the start-line, which is either a Request-Line (for requests)
    10591055   or a Status-Line (for responses), and in the algorithm for determining
    1060    the length of the message-body (<xref target="message.length"/>).
     1056   the length of the message-body (<xref target="message.body.length"/>).
    10611057   In theory, a client could receive requests and a server could receive
    10621058   responses, distinguishing them by their different start-line formats,
    … …  
    11051101   data to determine if a message-body is expected.  If a message-body
    11061102   has been indicated, then it is read as a stream until an amount
    1107    of OCTETs equal to the message-length is read or the connection
     1103   of octets equal to the message-body length is read or the connection
    11081104   is closed.  Care must be taken to parse an HTTP message as a sequence
    1109    of OCTETs in an encoding that is a superset of US-ASCII.  Attempting
     1105   of octets in an encoding that is a superset of US-ASCII.  Attempting
    11101106   to parse HTTP as a stream of Unicode characters in a character encoding
    11111107   like UTF-16 may introduce security flaws due to the differing ways
    … …  
    12331229<t>
    12341230   The message-body (if any) of an HTTP message is used to carry the
    1235    entity-body associated with the request or response. The message-body
    1236    differs from the entity-body only when a transfer-coding has been
     1231   payload body associated with the request or response. The message-body
     1232   differs from the payload body only when a transfer-coding has been
    12371233   applied, as indicated by the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
    12381234</t>
    12391235<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-body"/>
    1240   <x:ref>message-body</x:ref> = <x:ref>entity-body</x:ref>
    1241                / &lt;entity-body encoded as per <x:ref>Transfer-Encoding</x:ref>&gt;
    1242 </artwork></figure>
    1243 <t>
    1244    Transfer-Encoding &MUST; be used to indicate any transfer-codings
    1245    applied by an application to ensure safe and proper transfer of the
    1246    message. Transfer-Encoding is a property of the message, not of the
    1247    entity, and thus &MAY; be added or removed by any application along the
    1248    request/response chain. (However, <xref target="transfer.codings"/> places restrictions on
    1249    when certain transfer-codings may be used.)
     1236  <x:ref>message-body</x:ref> = *OCTET
     1237</artwork></figure>
     1238<t>
     1239   When one or more transfer-codings are applied to a payload body,
     1240   usually for the sake of stream-delimiting or data compression, the
     1241   Transfer-Encoding header field &MUST; be provided with the list of
     1242   transfer-codings applied. Transfer-Encoding is a property of the message,
     1243   not of the payload, and thus &MAY; be added or removed by any implementation
     1244   along the request/response chain under the constraints found in
     1245   <xref target="transfer.codings"/>.
    12501246</t>
    12511247<t>
    … …  
    12561252   The presence of a message-body in a request is signaled by the
    12571253   inclusion of a Content-Length or Transfer-Encoding header field in
    1258    the request's header fields.
    1259    When a request message contains both a message-body of non-zero
    1260    length and a method that does not define any semantics for that
    1261    request message-body, then an origin server &SHOULD; either ignore
    1262    the message-body or respond with an appropriate error message
    1263    (e.g., 413).  A proxy or gateway, when presented the same request,
    1264    &SHOULD; either forward the request inbound with the message-body or
    1265    ignore the message-body when determining a response.
     1254   the request's header fields, even if the request method does not
     1255   define any use for a message-body.  This allows the request
     1256   message framing algorithm to be independent of method semantics.
     1257   A server &MUST; read the entire request message-body or close
     1258   the connection after sending its response.
    12661259</t>
    12671260<t>
    12681261   For response messages, whether or not a message-body is included with
    12691262   a message is dependent on both the request method and the response
    1270    status code (<xref target="status.code.and.reason.phrase"/>). All responses to the HEAD request method
    1271    &MUST-NOT; include a message-body, even though the presence of entity-header
    1272    fields might lead one to believe they do. All 1xx
    1273    (Informational), 204 (No Content), and 304 (Not Modified) responses
    1274    &MUST-NOT; include a message-body. All other responses do include a
    1275    message-body, although it &MAY; be of zero length.
    1276 </t>
    1277 </section>
    1278 
    1279 <section title="Message Length" anchor="message.length">
    1280 <t>
    1281    The transfer-length of a message is the length of the message-body as
    1282    it appears in the message; that is, after any transfer-codings have
    1283    been applied. When a message-body is included with a message, the
    1284    transfer-length of that body is determined by one of the following
     1263   status code (<xref target="status.code.and.reason.phrase"/>).
     1264   Responses to the HEAD request method never include a message-body
     1265   because the associated response header fields (e.g., Transfer-Encoding,
     1266   Content-Length, etc.) only indicate what their values would have been
     1267   if the method had been GET.  All 1xx (Informational), 204 (No Content),
     1268   and 304 (Not Modified) responses &MUST-NOT; include a message-body.
     1269   All other responses do include a message-body, although the body
     1270   &MAY; be of zero length.
     1271</t>
     1272<t anchor="message.body.length">
     1273   The length of the message-body is determined by one of the following
    12851274   (in order of precedence):
    12861275</t>
    … …  
    12881277  <list style="numbers">
    12891278    <x:lt><t>
    1290      Any response message which "&MUST-NOT;" include a message-body (such
    1291      as the 1xx, 204, and 304 responses and any response to a HEAD
    1292      request) is always terminated by the first empty line after the
    1293      header fields, regardless of the entity-header fields present in
    1294      the message.
     1279     Any response to a HEAD request and any response with a status
     1280     code of 100-199, 204, or 304 is always terminated by the first
     1281     empty line after the header fields, regardless of the header
     1282     fields present in the message, and thus cannot contain a message-body.
    12951283    </t></x:lt>
    12961284    <x:lt><t>
    12971285     If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>)
    12981286     is present and the "chunked" transfer-coding (<xref target="transfer.codings"/>)
    1299      is used, the transfer-length is defined by the use of this transfer-coding.
    1300      If a Transfer-Encoding header field is present and the "chunked" transfer-coding
    1301      is not present, the transfer-length is defined by the sender closing the connection.
     1287     is used, the message-body length is determined by reading and decoding the
     1288     chunked data until the transfer-coding indicates the data is complete.
     1289    </t>
     1290    <t>
     1291     If a message is received with both a Transfer-Encoding header field and a
     1292     Content-Length header field, the Transfer-Encoding overrides the Content-Length.
     1293     Such a message may indicate an attempt to perform request or response
     1294     smuggling (bypass of security-related checks on message routing or content)
     1295     and thus should be handled as an error.  The provided Content-Length &MUST;
     1296     be removed, prior to forwarding the message downstream, or replaced with
     1297     the real message-body length after the transfer-coding is decoded.
     1298    </t>
     1299    <t>
     1300     If a Transfer-Encoding header field is present in a response and the
     1301     "chunked" transfer-coding is not present, the message-body length is
     1302     determined by reading the connection until it is closed.
     1303     If a Transfer-Encoding header field is present in a request and the
     1304     "chunked" transfer-coding is not present, the message-body length cannot
     1305     be determined reliably; the server &MUST; respond with 400 (Bad Request)
     1306     and then close the connection.
    13021307    </t></x:lt>
    13031308    <x:lt><t>
    1304      If a Content-Length header field (<xref target="header.content-length"/>) is present, its
    1305      value in OCTETs represents both the entity-length and the
    1306      transfer-length. The Content-Length header field &MUST-NOT; be sent
    1307      if these two lengths are different (i.e., if a Transfer-Encoding
    1308      header field is present). If a message is received with both a
    1309      Transfer-Encoding header field and a Content-Length header field,
    1310      the latter &MUST; be ignored.
     1309     If a valid Content-Length header field (<xref target="header.content-length"/>)
     1310     is present without Transfer-Encoding, its decimal value in octets defines
     1311     the message-body length.  If the actual number of octets sent in the message
     1312     is less than the indicated Content-Length, the recipient &MUST; consider
     1313     the message to be incomplete and treat the connection as no longer usable.
     1314     If the actual number of octets sent in the message is less than the indicated
     1315     Content-Length, the recipient &MUST; only process the message-body up to the
     1316     field value's number of octets; the remainder of the message &MUST; either
     1317     be discarded or treated as the next message in a pipeline.  For the sake of
     1318     robustness, a user-agent &MAY; attempt to detect and correct such an error
     1319     in message framing if it is parsing the response to the last request on
     1320     on a connection and the connection has been closed by the server.
     1321    </t>
     1322    <t>
     1323     If a message is received with multiple Content-Length header fields or a
     1324     Content-Length header field with an invalid value, the message framing
     1325     is invalid and &MUST; be treated as an error to prevent request or
     1326     response smuggling.
     1327     If this is a request message, the server &MUST; respond with
     1328     a 400 (Bad Request) status and then close the connection.
     1329     If this is a response message received by a proxy or gateway, the proxy
     1330     or gateway &MUST; discard the received response, send a 502 (Bad Gateway)
     1331     status as its downstream response, and then close the connection.
     1332     If this is a response message received by a user-agent, the message-body
     1333     length is determined by reading the connection until it is closed;
     1334     an error &SHOULD; be indicated to the user.
    13111335    </t></x:lt>
    13121336    <x:lt><t>
    1313      If the message uses the media type "multipart/byteranges", and the
    1314      transfer-length is not otherwise specified, then this self-delimiting
    1315      media type defines the transfer-length. This media type
    1316      &MUST-NOT; be used unless the sender knows that the recipient can parse
    1317      it; the presence in a request of a Range header with multiple byte-range
    1318      specifiers from a HTTP/1.1 client implies that the client can parse
    1319      multipart/byteranges responses.
    1320     <list style="empty"><t>
    1321        A range header might be forwarded by a HTTP/1.0 proxy that does not
    1322        understand multipart/byteranges; in this case the server &MUST;
    1323        delimit the message using methods defined in items 1, 3 or 5 of
    1324        this section.
    1325     </t></list>
     1337     If this is a request message and none of the above are true, then the
     1338     message-body length is zero (no message-body is present).
    13261339    </t></x:lt>
    13271340    <x:lt><t>
    1328      By the server closing the connection. (Closing the connection
    1329      cannot be used to indicate the end of a request body, since that
    1330      would leave no possibility for the server to send back a response.)
     1341     Otherwise, this is a response message without a declared message-body
     1342     length, so the message-body length is determined by the number of octets
     1343     received prior to the server closing the connection.
    13311344    </t></x:lt>
    13321345  </list>
    13331346</t>
    13341347<t>
    1335    For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
    1336    containing a message-body &MUST; include a valid Content-Length header
    1337    field unless the server is known to be HTTP/1.1 compliant. If a
    1338    request contains a message-body and a Content-Length is not given,
    1339    the server &SHOULD; respond with 400 (Bad Request) if it cannot
    1340    determine the length of the message, or with 411 (Length Required) if
    1341    it wishes to insist on receiving a valid Content-Length.
    1342 </t>
    1343 <t>
    1344    All HTTP/1.1 applications that receive entities &MUST; accept the
    1345    "chunked" transfer-coding (<xref target="transfer.codings"/>), thus allowing this mechanism
    1346    to be used for messages when the message length cannot be determined
    1347    in advance.
    1348 </t>
    1349 <t>
    1350    Messages &MUST-NOT; include both a Content-Length header field and a
    1351    transfer-coding. If the message does include a
    1352    transfer-coding, the Content-Length &MUST; be ignored.
    1353 </t>
    1354 <t>
    1355    When a Content-Length is given in a message where a message-body is
    1356    allowed, its field value &MUST; exactly match the number of OCTETs in
    1357    the message-body. HTTP/1.1 user agents &MUST; notify the user when an
    1358    invalid length is received and detected.
     1348   Since there is no way to distinguish a successfully completed,
     1349   close-delimited message from a partially-received message interrupted
     1350   by network failure, implementations &SHOULD; use encoding or
     1351   length-delimited messages whenever possible.  The close-delimiting
     1352   feature exists primarily for backwards compatibility with HTTP/1.0.
     1353</t>
     1354<t>
     1355   A server &MAY; reject a request that contains a message-body but
     1356   not a Content-Length by responding with 411 (Length Required).
     1357</t>
     1358<t>
     1359   A client that sends a request containing a message-body &SHOULD;
     1360   include a valid Content-Length header field if the message-body length
     1361   is known in advance, since many existing services will otherwise respond
     1362   with a 411 (Length Required) status code though they can handle the
     1363   chunked encoding.  This is typically because such services are
     1364   implemented via a gateway that requires a content-length in
     1365   advance of being called and the server is unable or unwilling
     1366   to buffer the entire request before processing.
     1367</t>
     1368<t>
     1369   A client that sends a request containing a message-body &MUST; include a
     1370   valid Content-Length header field if it does not know the server will
     1371   handle HTTP/1.1 (or later) requests; such knowledge can be in the form
     1372   of specific user configuration or by remembering the version of a prior
     1373   received response.
     1374</t>
     1375<t>
     1376   Request messages that are prematurely terminated, possibly due to a
     1377   cancelled connection or a server-imposed time-out exception, &MUST;
     1378   result in closure of the connection; sending an HTTP/1.1 error response
     1379   prior to closing the connection is &OPTIONAL;.
     1380   Response messages that are prematurely terminated, usually by closure
     1381   of the connection prior to receiving the given number of octets or by
     1382   failure to decode a transfer-encoded message-body, &MUST; be recorded
     1383   as incomplete.  A user agent &MUST-NOT; render an incomplete response
     1384   message-body as if it were complete (i.e., some indication must be given
     1385   to the user that an error occurred).  Cache requirements for incomplete
     1386   responses are defined in &cache-incomplete;.
    13591387</t>
    13601388</section>
    … …  
    13651393   There are a few header fields which have general applicability for
    13661394   both request and response messages, but which do not apply to the
    1367    entity being transferred. These header fields apply only to the
     1395   payload being transferred. These header fields apply only to the
    13681396   message being transmitted.
    13691397</t>
    … …  
    15491577   Various ad-hoc limitations on request-target length are found in practice.
    15501578   It is &RECOMMENDED; that all HTTP senders and recipients support
    1551    request-target lengths of 8000 or more OCTETs.
     1579   request-target lengths of 8000 or more octets.
    15521580</t>
    15531581<x:note>
    … …  
    17611789<t>
    17621790   HTTP applications have historically allowed three different formats
    1763    for the representation of date/time stamps.
    1764 </t>
    1765 <t>
    1766    The first format is preferred as an Internet standard and represents
     1791   for date/time stamps.
     1792   However, the preferred format is
    17671793   a fixed-length subset of that defined by <xref target="RFC1123"/>:
    17681794</t>
    … …  
    17791805</artwork></figure>
    17801806<t>
    1781    HTTP/1.1 clients and servers that parse the date value &MUST; accept
     1807   HTTP/1.1 clients and servers that parse a date value &MUST; accept
    17821808   all three formats (for compatibility with HTTP/1.0), though they &MUST;
    17831809   only generate the RFC 1123 format for representing HTTP-date values
    … …  
    19091935<t>
    19101936   Transfer-coding values are used to indicate an encoding
    1911    transformation that has been, can be, or may need to be applied to an
    1912    entity-body in order to ensure "safe transport" through the network.
     1937   transformation that has been, can be, or may need to be applied to a
     1938   payload body in order to ensure "safe transport" through the network.
    19131939   This differs from a content coding in that the transfer-coding is a
    1914    property of the message, not of the original entity.
     1940   property of the message rather than a property of the representation
     1941   that is being transferred.
    19151942</t>
    19161943<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/>
    … …  
    19261953  <x:anchor-alias value="transfer-parameter"/>
    19271954  <x:anchor-alias value="value"/>
    1928    Parameters are in  the form of attribute/value pairs.
     1955   Parameters are in the form of attribute/value pairs.
    19291956</t>
    19301957<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/>
    … …  
    19391966</t>
    19401967<t>
    1941    Whenever a transfer-coding is applied to a message-body, the set of
     1968   Whenever a transfer-coding is applied to a payload body, the set of
    19421969   transfer-codings &MUST; include "chunked", unless the message indicates it
    19431970   is terminated by closing the connection. When the "chunked" transfer-coding
    1944    is used, it &MUST; be the last transfer-coding applied to the
     1971   is used, it &MUST; be the last transfer-coding applied to form the
    19451972   message-body. The "chunked" transfer-coding &MUST-NOT; be applied more
    19461973   than once to a message-body. These rules allow the recipient to
    1947    determine the transfer-length of the message (<xref target="message.length"/>).
     1974   determine the message-body length of the message (<xref target="message.body.length"/>).
    19481975</t>
    19491976<t>
    … …  
    19541981   has a different focus for an 8bit-clean transfer protocol. In HTTP,
    19551982   the only unsafe characteristic of message-bodies is the difficulty in
    1956    determining the exact body length (<xref target="message.length"/>), or the desire to
     1983   determining the exact body length (<xref target="message.body.length"/>), or the desire to
    19571984   encrypt data over a shared transport.
    19581985</t>
    19591986<t>
    1960    A server which receives an entity-body with a transfer-coding it does
    1961    not understand &SHOULD; return 501 (Not Implemented), and close the
    1962    connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
     1987   A server that receives a request message with a transfer-coding it does
     1988   not understand &SHOULD; respond with 501 (Not Implemented) and then
     1989   close the connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
    19631990   client.
    19641991</t>
    … …  
    20532080  while (chunk-size &gt; 0) {
    20542081     read chunk-data and CRLF
    2055      append chunk-data to entity-body
     2082     append chunk-data to decoded-body
    20562083     length := length + chunk-size
    20572084     read chunk-size and CRLF
    20582085  }
    2059   read entity-header
    2060   while (entity-header not empty) {
    2061      append entity-header to existing header fields
    2062      read entity-header
     2086  read header-field
     2087  while (header-field not empty) {
     2088     append header-field to existing header fields
     2089     read header-field
    20632090  }
    20642091  Content-Length := length
    … …  
    20672094<t>
    20682095   All HTTP/1.1 applications &MUST; be able to receive and decode the
    2069    "chunked" transfer-coding, and &MUST; ignore chunk-ext extensions
     2096   "chunked" transfer-coding and &MUST; ignore chunk-ext extensions
    20702097   they do not understand.
    20712098</t>
    … …  
    23212348   In order to remain persistent, all messages on the connection &MUST;
    23222349   have a self-defined message length (i.e., one not defined by closure
    2323    of the connection), as described in <xref target="message.length"/>.
     2350   of the connection), as described in <xref target="message.body.length"/>.
    23242351</t>
    23252352</section>
    … …  
    24752502</x:note>
    24762503<t>
    2477    The Content-Length field of a request or response is added or deleted
    2478    according to the rules in <xref target="message.length"/>. A transparent proxy &MUST;
    2479    preserve the entity-length (&entity-length;) of the entity-body,
    2480    although it &MAY; change the transfer-length (<xref target="message.length"/>).
     2504   A transparent proxy &MUST; preserve the message payload (&payload;),
     2505   though it &MAY; change the message-body through application or removal
     2506   of a transfer-coding (<xref target="transfer.codings"/>).
    24812507</t>
    24822508</section>
    … …  
    28582884  <x:anchor-alias value="Content-Length-v"/>
    28592885<t>
    2860    The "Content-Length" entity-header field indicates the size of the
    2861    entity-body, in number of OCTETs. In the case of responses to the HEAD
    2862    method, it indicates the size of the entity-body that would have been sent
    2863    had the request been a GET.
     2886   The "Content-Length" header field indicates the size of the
     2887   message-body, in decimal number of octets, for any message other than
     2888   a response to the HEAD method or a response with a status code of 304.
     2889   In the case of responses to the HEAD method, it indicates the size of
     2890   the payload body (not including any potential transfer-coding) that
     2891   would have been sent had the request been a GET.
     2892   In the case of the 304 (Not Modified) response, it indicates the size of
     2893   the payload body (not including any potential transfer-coding) that
     2894   would have been sent in a 200 (OK) response.
    28642895</t>
    28652896<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/>
    … …  
    28742905</artwork></figure>
    28752906<t>
    2876    Applications &SHOULD; use this field to indicate the transfer-length of
    2877    the message-body, unless this is prohibited by the rules in <xref target="message.length"/>.
     2907   Implementations &SHOULD; use this field to indicate the message-body
     2908   length when no transfer-coding is being applied and the
     2909   payload's body length can be determined prior to being transferred.
    28782910</t>
    28792911<t>
    28802912   Any Content-Length greater than or equal to zero is a valid value.
    2881    <xref target="message.length"/> describes how to determine the length of a message-body
     2913   <xref target="message.body.length"/> describes how to determine the length of a message-body
    28822914   if a Content-Length is not given.
    28832915</t>
    … …  
    28852917   Note that the meaning of this field is significantly different from
    28862918   the corresponding definition in MIME, where it is an optional field
    2887    used within the "message/external-body" content-type. In HTTP, it
    2888    &SHOULD; be sent whenever the message's length can be determined prior
    2889    to being transferred, unless this is prohibited by the rules in
    2890    <xref target="message.length"/>.
     2919   used within the "message/external-body" content-type.
    28912920</t>
    28922921</section>
    … …  
    29432972<t>
    29442973   Clients &SHOULD; only send a Date header field in messages that include
    2945    an entity-body, as in the case of the PUT and POST requests, and even
     2974   a payload, as is usually the case for PUT and POST requests, and even
    29462975   then it is optional. A client without a clock &MUST-NOT; send a Date
    29472976   header field in a request.
    … …  
    29532982   generation, unless the implementation has no means of generating a
    29542983   reasonably accurate date and time. In theory, the date ought to
    2955    represent the moment just before the entity is generated. In
     2984   represent the moment just before the payload is generated. In
    29562985   practice, the date can be generated at any time during the message
    29572986   origination without affecting its semantic value.
    … …  
    46724701</t>
    46734702<t>
    4674    The character set of an entity-body &SHOULD; be labeled as the lowest
    4675    common denominator of the character codes used within that body, with
    4676    the exception that not labeling the entity is preferred over labeling
    4677    the entity with the labels US-ASCII or ISO-8859-1. See &payload;.
     4703   The character set of a representation &SHOULD; be labeled as the lowest
     4704   common denominator of the character codes used within that representation, with
     4705   the exception that not labeling the representation is preferred over labeling
     4706   the representation with the labels US-ASCII or ISO-8859-1. See &payload;.
    46784707</t>
    46794708<t>
    … …  
    48444873   transfer encoding that may not be self delimiting); it was important
    48454874   to straighten out exactly how message lengths are computed. (Sections
    4846    <xref target="transfer.codings" format="counter"/>, <xref target="message.length" format="counter"/>,
     4875   <xref target="transfer.codings" format="counter"/>, <xref target="message.body.length" format="counter"/>,
    48474876   <xref target="header.content-length" format="counter"/>,
    48484877   see also <xref target="Part3"/>, <xref target="Part5"/> and <xref target="Part6"/>)
    … …  
    49014930  Remove reference to non-existent identity transfer-coding value tokens.
    49024931  (Sections <xref format="counter" target="transfer.codings"/> and
    4903   <xref format="counter" target="message.length"/>)
     4932  <xref format="counter" target="message.body.length"/>)
    49044933</t>
    49054934<t>
    … …  
    50295058 / %x53.75.6E.64.61.79 ; Sunday
    50305059
    5031 <x:ref>entity-body</x:ref> = &lt;entity-body, defined in [Part3], Section 3.2&gt;
    50325060<x:ref>entity-header</x:ref> = &lt;entity-header, defined in [Part3], Section 3.1&gt;
    50335061
    … …  
    50465074<x:ref>last-chunk</x:ref> = 1*"0" *WSP [ chunk-ext ] CRLF
    50475075
    5048 <x:ref>message-body</x:ref> = entity-body /
    5049  &lt;entity-body encoded as per Transfer-Encoding&gt;
     5076<x:ref>message-body</x:ref> = *OCTET
    50505077<x:ref>minute</x:ref> = 2DIGIT
    50515078<x:ref>month</x:ref> = %x4A.61.6E ; Jan

  • draft-ietf-httpbis/latest/p3-payload.xml

    r848 r852  
    2727  <!ENTITY header-vary              "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2828  <!ENTITY message-body             "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    29   <!ENTITY message-length           "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     29  <!ENTITY message-length           "<xref target='Part1' x:rel='#message.body.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3030  <!ENTITY header-fields            "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3131  <!ENTITY multipart-byteranges     "<xref target='Part5' x:rel='#internet.media.type.multipart.byteranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    654654   value. The message body is itself a protocol element and &MUST;
    655655   therefore use only CRLF to represent line breaks between body-parts.
    656    Unlike in RFC 2046, the epilogue of any multipart message &MUST; be
    657    empty; HTTP applications &MUST-NOT; transmit the epilogue (even if the
    658    original multipart contains an epilogue). These restrictions exist in
    659    order to preserve the self-delimiting nature of a multipart message-body,
    660    wherein the "end" of the message-body is indicated by the
    661    ending multipart boundary.
    662656</t>
    663657<t>
    664658   In general, HTTP treats a multipart message-body no differently than
    665    any other media type: strictly as payload. The one exception is the
    666    "multipart/byteranges" type (&multipart-byteranges;) when it appears in a 206
    667    (Partial Content) response.
     659   any other media type: strictly as payload.  HTTP does not use the
     660   multipart boundary as an indicator of message-body length.
    668661   <!-- jre: re-insert removed text pointing to caching? -->
    669    In all
    670    other cases, an HTTP user agent &SHOULD; follow the same or similar
     662   In all other respects, an HTTP user agent &SHOULD; follow the same or similar
    671663   behavior as a MIME user agent would upon receipt of a multipart type.
    672664   The MIME header fields within each body-part of a multipart message-body
    … …  
    675667</t>
    676668<t>
    677    In general, an HTTP user agent &SHOULD; follow the same or similar
    678    behavior as a MIME user agent would upon receipt of a multipart type.
    679669   If an application receives an unrecognized multipart subtype, the
    680670   application &MUST; treat it as being equivalent to "multipart/mixed".
    … …  
    822812</section>
    823813   
    824 <section title="Entity Length" anchor="entity.length">
    825 <t>
    826    The entity-length of a message is the length of the message-body
    827    before any transfer-codings have been applied. &message-length; defines
    828    how the transfer-length of a message-body is determined.
    829 </t>
    830 </section>
    831814</section>
    832815</section>
    … …  
    27342717   transfer encoding that may not be self delimiting); it was important
    27352718   to straighten out exactly how message lengths are computed.
    2736    (<xref target="entity.length"/>, see also <xref target="Part1"/>,
    2737    <xref target="Part5"/> and <xref target="Part6"/>).
    27382719</t>
    27392720<t>

  • draft-ietf-httpbis/latest/p5-range.xml

    r848 r852  
    357357        Content-Type including Content-Range fields for each part. If a
    358358        Content-Length header field is present in the response, its
    359         value &MUST; match the actual number of OCTETs transmitted in the
     359        value &MUST; match the actual number of octets transmitted in the
    360360        message-body.
    361361    </t>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r848 r852  
    3030  <!ENTITY header-last-modified        "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3131  <!ENTITY header-fields               "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    32   <!ENTITY message-length              "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3332  <!ENTITY safe-methods                "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3433  <!ENTITY weak-and-strong             "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
Note: See TracChangeset for help on using the changeset viewer.