Ignore:
Timestamp:
Dec 5, 2012, 8:59:49 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) Deal with second half of mnot p1 feedback; addresses #408

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2030 r2031  
    14781478<section title="Transfer-Encoding" anchor="header.transfer-encoding">
    14791479  <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/>
     1480  <iref item="chunked (Coding Format)"/>
    14801481  <x:anchor-alias value="Transfer-Encoding"/>
    14811482<t>
    1482    When one or more transfer codings are applied to a payload body in order
    1483    to form the message body, a Transfer-Encoding header field &MUST; be sent
    1484    in the message and &MUST; contain the list of corresponding
    1485    transfer-coding names in the same order that they were applied.
     1483   The Transfer-Encoding header field lists the transfer coding names
     1484   corresponding to the sequence of transfer codings that have been
     1485   (or will be) applied to the payload body in order to form the message body.
    14861486   Transfer codings are defined in <xref target="transfer.codings"/>.
    14871487</t>
    … …  
    14971497   accurately delimit a dynamically generated payload and to distinguish
    14981498   payload encodings that are only applied for transport efficiency or
    1499    security from those that are characteristics of the target resource.
    1500 </t>
    1501 <t>
    1502    The "chunked" transfer-coding (<xref target="chunked.encoding"/>)
    1503    &MUST; be implemented by all HTTP/1.1 recipients because it plays a
    1504    crucial role in delimiting messages when the payload body size is not
    1505    known in advance.
    1506    When the "chunked" transfer-coding is used, it &MUST; be the last
    1507    transfer-coding applied to form the message body and &MUST-NOT;
    1508    be applied more than once in a message body.
    1509    If any transfer-coding is applied to a request payload body,
    1510    the final transfer-coding applied &MUST; be "chunked".
    1511    If any transfer-coding is applied to a response payload body, then either
    1512    the final transfer-coding applied &MUST; be "chunked" or
    1513    the message &MUST; be terminated by closing the connection.
     1499   security from those that are characteristics of the selected resource.
     1500</t>
     1501<t>
     1502   All HTTP/1.1 recipients &MUST; implement the chunked transfer coding
     1503   (<xref target="chunked.encoding"/>) because it plays a crucial role in
     1504   framing messages when the payload body size is not known in advance.
     1505   If chunked is applied to a payload body, the sender &MUST-NOT; apply
     1506   chunked more than once (i.e., chunking an already chunked message is not
     1507   allowed).
     1508   If any transfer coding is applied to a request payload body, the
     1509   sender &MUST; apply chunked as the final transfer coding to ensure that
     1510   the message is properly framed.
     1511   If any transfer coding is applied to a response payload body, the
     1512   sender &MUST; either apply chunked as the final transfer coding or
     1513   terminate the message by closing the connection.
    15141514</t>
    15151515<figure><preamble>
    … …  
    15231523</postamble></figure>
    15241524<t>
    1525    If more than one Transfer-Encoding header field is present in a message,
    1526    the multiple field-values &MUST; be combined into one field-value,
    1527    according to the algorithm defined in <xref target="header.fields"/>,
    1528    before determining the message body length.
    1529 </t>
    1530 <t>
    15311525   Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;),
    1532    Transfer-Encoding is a property of the message, not of the payload, and thus
    1533    &MAY; be added or removed by any implementation along the request/response
    1534    chain. Additional information about the encoding parameters &MAY; be
     1526   Transfer-Encoding is a property of the message, not of the payload, and
     1527   any recipient along the request/response chain &MAY; decode the received
     1528   transfer coding(s) or apply additional transfer coding(s) to the message
     1529   body, assuming that corresponding changes are made to the Transfer-Encoding
     1530   field-value. Additional information about the encoding parameters &MAY; be
    15351531   provided by other header fields not defined by this specification.
    15361532</t>
    … …  
    15571553</t>
    15581554<t>
    1559    A server that receives a request message with a transfer-coding it does
    1560    not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref> and then
    1561    close the connection.
     1555   A server that receives a request message with a transfer coding it does
     1556   not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref>.
    15621557</t>
    15631558</section>
    … …  
    16361631
    16371632<section title="Message Body Length" anchor="message.body.length">
     1633  <iref item="chunked (Coding Format)"/>
    16381634<t>
    16391635   The length of a message body is determined by one of the following
    … …  
    16591655    <x:lt><t>
    16601656     If a <x:ref>Transfer-Encoding</x:ref> header field is present
    1661      and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
     1657     and the chunked transfer coding (<xref target="chunked.encoding"/>)
    16621658     is the final encoding, the message body length is determined by reading
    1663      and decoding the chunked data until the transfer-coding indicates the
     1659     and decoding the chunked data until the transfer coding indicates the
    16641660     data is complete.
    16651661    </t>
    16661662    <t>
    16671663     If a <x:ref>Transfer-Encoding</x:ref> header field is present in a
    1668      response and the "chunked" transfer-coding is not the final encoding, the
     1664     response and the chunked transfer coding is not the final encoding, the
    16691665     message body length is determined by reading the connection until it is
    16701666     closed by the server.
    1671      If a Transfer-Encoding header field is present in a request and the
    1672      "chunked" transfer-coding is not the final encoding, the message body
     1667     If a <x:ref>Transfer-Encoding</x:ref> header field is present in a request and the
     1668     chunked transfer coding is not the final encoding, the message body
    16731669     length cannot be determined reliably; the server &MUST; respond with
    16741670     the <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    … …  
    16761672    <t>
    16771673     If a message is received with both a <x:ref>Transfer-Encoding</x:ref>
    1678      and a <x:ref>Content-Length</x:ref> header field, the
    1679      Transfer-Encoding overrides the Content-Length.
    1680      Such a message might indicate an attempt to perform request or response
    1681      smuggling (bypass of security-related checks on message routing or content)
    1682      and thus ought to be handled as an error.  The provided Content-Length &MUST;
    1683      be removed, prior to forwarding the message downstream, or replaced with
    1684      the real message body length after the transfer-coding is decoded.
     1674     and a <x:ref>Content-Length</x:ref> header field, the Transfer-Encoding
     1675     overrides the Content-Length. Such a message might indicate an attempt
     1676     to perform request or response smuggling (bypass of security-related
     1677     checks on message routing or content) and thus ought to be handled as
     1678     an error.  A sender &MUST; remove the received Content-Length field
     1679     prior to forwarding such a message downstream.
    16851680    </t></x:lt>
    16861681    <x:lt><t>
    … …  
    17371732</t>
    17381733<t>
    1739    Unless a transfer-coding other than "chunked" has been applied,
     1734   Unless a transfer coding other than chunked has been applied,
    17401735   a client that sends a request containing a message body &SHOULD;
    17411736   use a valid <x:ref>Content-Length</x:ref> header field if the message body
    1742    length is known in advance, rather than the "chunked" encoding, since some
    1743    existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref>
    1744    status code even though they understand the chunked encoding.  This
     1737   length is known in advance, rather than the chunked transfer coding, since some
     1738   existing services respond to chunked with a <x:ref>411 (Length Required)</x:ref>
     1739   status code even though they understand the chunked transfer coding.  This
    17451740   is typically because such services are implemented via a gateway that
    17461741   requires a content-length in advance of being called and the server
    … …  
    17591754<section anchor="incomplete.messages" title="Handling Incomplete Messages">
    17601755<t>
    1761    Request messages that are prematurely terminated, possibly due to a
    1762    canceled connection or a server-imposed time-out exception, &MUST;
    1763    result in closure of the connection; sending an error response
    1764    prior to closing the connection is &OPTIONAL;.
    1765 </t>
    1766 <t>
    1767    Response messages that are prematurely terminated, usually by closure
    1768    of the connection prior to receiving the expected number of octets or by
    1769    failure to decode a transfer-encoded message body, &MUST; be recorded
    1770    as incomplete.  A response that terminates in the middle of the header
    1771    block (before the empty line is received) cannot be assumed to convey the
    1772    full semantics of the response and &MUST; be treated as an error.
    1773 </t>
    1774 <t>
    1775    A message body that uses the chunked transfer encoding is
     1756   A server that receives an incomplete request message, usually due to a
     1757   canceled request or a triggered time-out exception, &MAY; send an error
     1758   response prior to closing the connection.
     1759</t>
     1760<t>
     1761   A client that receives an incomplete response message, which can occur
     1762   when a connection is closed prematurely or when decoding a supposedly
     1763   chunked transfer coding fails, &MUST; record the message as incomplete.
     1764   If a response terminates in the middle of the header block (before the
     1765   empty line is received) and the status code might rely on header fields to
     1766   convey the full meaning of the response, then the client cannot assume
     1767   that meaning has been conveyed; the client might need to repeat the
     1768   request in order to determine what action to take next.
     1769</t>
     1770<t>
     1771   A message body that uses the chunked transfer coding is
    17761772   incomplete if the zero-sized chunk that terminates the encoding has not
    17771773   been received.  A message that uses a valid <x:ref>Content-Length</x:ref> is
    17781774   incomplete if the size of the message body received (in octets) is less than
    17791775   the value given by Content-Length.  A response that has neither chunked
    1780    transfer encoding nor Content-Length is terminated by closure of the
     1776   transfer coding nor Content-Length is terminated by closure of the
    17811777   connection, and thus is considered complete regardless of the number of
    17821778   message body octets received, provided that the header block was received
    … …  
    18021798<section title="Message Parsing Robustness" anchor="message.robustness">
    18031799<t>
    1804    Older HTTP/1.0 client implementations might send an extra CRLF
     1800   Older HTTP/1.0 user agent implementations might send an extra CRLF
    18051801   after a POST request as a lame workaround for some early server
    18061802   applications that failed to read message body content that was
    1807    not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;
     1803   not terminated by a line-ending. An HTTP/1.1 user agent &MUST-NOT;
    18081804   preface or follow a request with an extra CRLF.  If terminating
    18091805   the request message body with a line-ending is desired, then the
    1810    client &MUST; include the terminating CRLF octets as part of the
     1806   user agent &MUST; include the terminating CRLF octets as part of the
    18111807   message body length.
    18121808</t>
    … …  
    18141810   In the interest of robustness, servers &SHOULD; ignore at least one
    18151811   empty line received where a request-line is expected. In other words, if
    1816    the server is reading the protocol stream at the beginning of a
    1817    message and receives a CRLF first, it &SHOULD; ignore the CRLF.
     1812   a server is reading the protocol stream at the beginning of a
     1813   message and receives a CRLF first, the server &SHOULD; ignore the CRLF.
    18181814</t>
    18191815<t>
    … …  
    18451841  <x:anchor-alias value="transfer-extension"/>
    18461842<t>
    1847    Transfer-coding values are used to indicate an encoding
     1843   Transfer coding names are used to indicate an encoding
    18481844   transformation that has been, can be, or might need to be applied to a
    18491845   payload body in order to ensure "safe transport" through the network.
    1850    This differs from a content coding in that the transfer-coding is a
     1846   This differs from a content coding in that the transfer coding is a
    18511847   property of the message rather than a property of the representation
    18521848   that is being transferred.
    … …  
    18721868</artwork></figure>
    18731869<t>
    1874    All transfer-coding values are case-insensitive and &SHOULD; be registered
     1870   All transfer-coding names are case-insensitive and &SHOULD; be registered
    18751871   within the HTTP Transfer Coding registry, as defined in
    18761872   <xref target="transfer.coding.registry"/>.
    … …  
    18811877
    18821878<section title="Chunked Transfer Coding" anchor="chunked.encoding">
    1883   <iref item="chunked (Coding Format)"/>
     1879  <iref primary="true" item="chunked (Coding Format)"/>
    18841880  <x:anchor-alias value="chunk"/>
    18851881  <x:anchor-alias value="chunked-body"/>
    … …  
    18941890  <x:anchor-alias value="qdtext-nf"/>
    18951891<t>
    1896    The chunked encoding modifies the body of a message in order to
     1892   The chunked transfer coding modifies the body of a message in order to
    18971893   transfer it as a series of chunks, each with its own size indicator,
    18981894   followed by an &OPTIONAL; trailer containing header fields. This
    … …  
    19231919</artwork></figure>
    19241920<t>
    1925    Chunk extensions within the chucked encoding are deprecated.
     1921   Chunk extensions within the chunked transfer coding are deprecated.
    19261922   Senders &SHOULD-NOT; send chunk-ext.
    19271923   Definition of new chunk extensions is discouraged.
    … …  
    19291925<t>
    19301926   The chunk-size field is a string of hex digits indicating the size of
    1931    the chunk-data in octets. The chunked encoding is ended by any chunk whose size is
    1932    zero, followed by the trailer, which is terminated by an empty line.
     1927   the chunk-data in octets. The chunked transfer coding is complete when a
     1928   chunk with a chunk-size of zero is received, possibly followed by a
     1929   trailer, and finally terminated by an empty line.
    19331930</t>
    19341931
    … …  
    19471944<t>
    19481945   When a message includes a message body encoded with the chunked
    1949    transfer-coding and the sender desires to send metadata in the form of
     1946   transfer coding and the sender desires to send metadata in the form of
    19501947   trailer fields at the end of the message, the sender &SHOULD; send a
    19511948   <x:ref>Trailer</x:ref> header field before the message body to indicate
    … …  
    19631960</t>
    19641961<t>
    1965    A server &MUST; send an empty trailer with the chunked transfer-coding
     1962   A server &MUST; send an empty trailer with the chunked transfer coding
    19661963   unless at least one of the following is true:
    19671964  <list style="numbers">
    19681965    <t>the request included a <x:ref>TE</x:ref> header field that indicates
    1969     "trailers" is acceptable in the transfer-coding of the response, as
     1966    "trailers" is acceptable in the transfer coding of the response, as
    19701967    described in <xref target="header.te"/>; or,</t>
    19711968     
    … …  
    19871984<section title="Decoding chunked" anchor="decoding.chunked">
    19881985<t>
    1989    A process for decoding the "chunked" transfer-coding
     1986   A process for decoding the chunked transfer coding
    19901987   can be represented in pseudo-code as:
    19911988</t>
    … …  
    20102007<t>
    20112008   All recipients &MUST; be able to receive and decode the
    2012    "chunked" transfer-coding and &MUST; ignore chunk-ext extensions
     2009   chunked transfer coding and &MUST; ignore chunk-ext extensions
    20132010   they do not understand.
    20142011</t>
    … …  
    20662063  <x:anchor-alias value="rank"/>
    20672064<t>
    2068    The "TE" header field in a request indicates what transfer-codings,
    2069    besides "chunked", the client is willing to accept in response, and
     2065   The "TE" header field in a request indicates what transfer codings,
     2066   besides chunked, the client is willing to accept in response, and
    20702067   whether or not the client is willing to accept trailer fields in a
    2071    chunked transfer-coding.
    2072 </t>
    2073 <t>
    2074    The TE field-value consists of a comma-separated list of transfer-coding
     2068   chunked transfer coding.
     2069</t>
     2070<t>
     2071   The TE field-value consists of a comma-separated list of transfer coding
    20752072   names, each allowing for optional parameters (as described in
    20762073   <xref target="transfer.codings"/>), and/or the keyword "trailers".
    2077    Clients &MUST-NOT; send the chunked transfer-coding name in TE;
     2074   Clients &MUST-NOT; send the chunked transfer coding name in TE;
    20782075   chunked is always acceptable for HTTP/1.1 recipients.
    20792076</t>
    … …  
    20952092<t>
    20962093   The presence of the keyword "trailers" indicates that the client is
    2097    willing to accept trailer fields in a chunked transfer-coding,
     2094   willing to accept trailer fields in a chunked transfer coding,
    20982095   as defined in <xref target="chunked.encoding"/>, on behalf of itself and
    20992096   any downstream clients. For chained requests, this implies that either:
    … …  
    21072104</t>
    21082105<t>
    2109    When multiple transfer-codings are acceptable, the client &MAY; rank the
     2106   When multiple transfer codings are acceptable, the client &MAY; rank the
    21102107   codings by preference using a case-insensitive "q" parameter (similar to
    21112108   the qvalues used in content negotiation fields, &qvalue;). The rank value
    … …  
    21152112<t>
    21162113   If the TE field-value is empty or if no TE field is present, the only
    2117    acceptable transfer-coding is "chunked". A message with no transfer-coding
     2114   acceptable transfer coding is chunked. A message with no transfer coding
    21182115   is always acceptable.
    21192116</t>
    … …  
    24632460</section>
    24642461
     2462<section title="Associating a Response to a Request" anchor="associating.response.to.request">
     2463<t>
     2464   HTTP does not include a request identifier for associating a given
     2465   request message with its corresponding one or more response messages.
     2466   Hence, it relies on the order of response arrival to correspond exactly
     2467   to the order in which requests are made on the same connection.
     2468   More than one response message per request only occurs when one or more
     2469   informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a
     2470   final response to the same request.
     2471</t>
     2472<t>
     2473   A client that has more than one outstanding request on a connection &MUST;
     2474   maintain a list of outstanding requests in the order sent and &MUST;
     2475   associate each received response message on that connection to the highest
     2476   ordered request that has not yet received a final (non-<x:ref>1xx</x:ref>)
     2477   response.
     2478</t>
     2479</section>
     2480
    24652481<section title="Message Forwarding" anchor="message.forwarding">
    24662482<t>
    … …  
    24842500   names, including any aliases, local variations, or literal IP addresses.
    24852501</t>
    2486 </section>
    24872502
    24882503<section title="Via" anchor="header.via">
    … …  
    25792594</section>
    25802595
    2581 <section title="Message Transforming" anchor="message.transforming">
     2596<section title="Transformation" anchor="message.transformation">
    25822597<t>
    25832598   If a proxy receives a request-target with a host name that is not a
    … …  
    25942609   A non-transforming proxy &MUST; preserve the message payload (&payload;),
    25952610   though it &MAY; change the message body through application or removal
    2596    of a transfer-coding (<xref target="transfer.codings"/>).
     2611   of a transfer coding (<xref target="transfer.codings"/>).
    25972612</t>
    25982613<t>
    … …  
    26452660</x:note>
    26462661</section>
    2647 
    2648 <section title="Associating a Response to a Request" anchor="associating.response.to.request">
    2649 <t>
    2650    HTTP does not include a request identifier for associating a given
    2651    request message with its corresponding one or more response messages.
    2652    Hence, it relies on the order of response arrival to correspond exactly
    2653    to the order in which requests are made on the same connection.
    2654    More than one response message per request only occurs when one or more
    2655    informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a final response
    2656    to the same request.
    2657 </t>
    2658 <t>
    2659    A client that uses persistent connections and sends more than one request
    2660    per connection &MUST; maintain a list of outstanding requests in the
    2661    order sent on that connection and &MUST; associate each received response
    2662    message to the highest ordered request that has not yet received a final
    2663    (non-<x:ref>1xx</x:ref>) response.
    2664 </t>
    26652662</section>
    26662663</section>
    … …  
    47364733   HTTP/1.1 introduces the <x:ref>Transfer-Encoding</x:ref> header field
    47374734   (<xref target="header.transfer-encoding"/>). Proxies/gateways &MUST; remove
    4738    any transfer-coding prior to forwarding a message via a MIME-compliant
     4735   any transfer coding prior to forwarding a message via a MIME-compliant
    47394736   protocol.
    47404737</t>
    … …  
    48274824</t>
    48284825<t>
    4829   The "identity" transfer-coding value token has been removed.
     4826  The "identity" transfer coding token has been removed.
    48304827  (Sections <xref format="counter" target="message.body"/> and
    48314828  <xref format="counter" target="transfer.codings"/>)
Note: See TracChangeset for help on using the changeset viewer.