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).

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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>
Note: See TracChangeset for help on using the changeset viewer.