Ignore:
Timestamp:
Sep 21, 2012, 4:55:01 PM (7 years ago)
Author:
fielding@…
Message:

Do not require Content-Length on responses that do not have a body.
This was actually an existing requirement in RFC2616:

Applications SHOULD use this field to indicate the transfer-length of
the message-body, unless this is prohibited by the rules in section
4.4.

because 4.4 does not prohibit sending of content-length, even though
it is believed what was meant by 2616 is that the SHOULD does not
apply to messages that prohibit a body.

Anyway, this change should clarify it, and the other requirements
on sending content-length, once and for all, at the cost of a bit
of duplication between p1 and p2.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1905 r1908  
    2626  <!ENTITY diff-mime              "<xref target='Part2' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2727  <!ENTITY representation         "<xref target='Part2' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     28  <!ENTITY HEAD                   "<xref target='Part2' x:rel='#HEAD' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2829  <!ENTITY header-allow           "<xref target='Part2' x:rel='#header.allow' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2930  <!ENTITY header-cache-control   "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    14621463   Responses to the HEAD request method never include a message body
    14631464   because the associated response header fields (e.g.,
    1464    <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.) only
    1465    indicate what their values would have been if the request method had been
    1466    GET. <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel
    1467    mode instead of having a message body.
     1465   <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.),
     1466   if present, indicate only what their values would have been if the request
     1467   method had been GET (&HEAD;).
     1468   <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel
     1469   mode instead of having a message body (&CONNECT;).
    14681470   All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and
    14691471   <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
     
    15631565  <x:anchor-alias value="Content-Length"/>
    15641566<t>
    1565    When a message does not have a <x:ref>Transfer-Encoding</x:ref> header field
    1566    and the payload body length can be determined prior to being transferred, a
    1567    Content-Length header field &SHOULD; be sent to indicate the length of the
    1568    payload body that is either present as the message body, for requests
    1569    and non-HEAD responses other than <x:ref>304 (Not Modified)</x:ref>, or
    1570    would have been present had the request been an unconditional GET.  The
    1571    length is expressed as a decimal number of octets.
     1567   When a message is allowed to contain a message body, does not have a
     1568   <x:ref>Transfer-Encoding</x:ref> header field, and has a payload body
     1569   length that is known to the sender before the message header section has
     1570   been sent, the sender &SHOULD; send a Content-Length header field to
     1571   indicate the length of the payload body as a decimal number of octets.
    15721572</t>
    15731573<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>
     
    15811581</artwork></figure>
    15821582<t>
    1583    In the case of a response to a HEAD request, Content-Length indicates
    1584    the size of the payload body (without any potential transfer-coding)
    1585    that would have been sent had the request been a GET.
    1586    In the case of a <x:ref>304 (Not Modified)</x:ref> response (&status-304;)
    1587    to a GET request, Content-Length indicates the size of the payload body (without
    1588    any potential transfer-coding) that would have been sent in a <x:ref>200 (OK)</x:ref>
    1589    response.
     1583   A sender &MUST-NOT; send a Content-Length header field in any message that
     1584   contains a <x:ref>Transfer-Encoding</x:ref> header field.
     1585</t>
     1586<t>
     1587   A server &MAY; send a Content-Length header field in a response to a HEAD
     1588   request (&HEAD;) in order to indicate the size of the payload body,
     1589   excluding any potential transfer-coding, that would have been sent had the
     1590   same request been a GET.
     1591</t>
     1592<t>
     1593   A server &MAY; send a Content-Length header field in a
     1594   <x:ref>304 (Not Modified)</x:ref> response to a conditional GET request
     1595   (&status-304;) in order to indicate the size of the payload body,
     1596   excluding any potential transfer-coding, that would have been sent in a
     1597   <x:ref>200 (OK)</x:ref> response.
     1598</t>
     1599<t>
     1600   A server &MUST-NOT; send a Content-Length header field in any response
     1601   with a status code of
     1602   <x:ref>1xx (Informational)</x:ref> or <x:ref>204 (No Content)</x:ref>.
     1603   A server &SHOULD-NOT; send a Content-Length header field in any
     1604   <x:ref>2xx (Successful)</x:ref> response to a CONNECT request (&CONNECT;).
    15901605</t>
    15911606<t>
Note: See TracChangeset for help on using the changeset viewer.