06/12/12 19:13:32 (9 years ago)

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

1 edited


  • 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"/>
    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;).
    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.
     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.
    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;).
     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.
Note: See TracChangeset for help on using the changeset viewer.