Changeset 872 for draft-ietf-httpbis


Ignore:
Timestamp:
Jul 22, 2010, 6:34:14 PM (9 years ago)
Author:
fielding@…
Message:

Addresses #28: Connection closing

Finished clarification of when closing the connection is
required for message delimiting.

File:
1 edited

Legend:

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

    r870 r872  
    13001300     If a Transfer-Encoding header field is present in a response and the
    13011301     "chunked" transfer-coding is not present, the message-body length is
    1302      determined by reading the connection until it is closed.
     1302     determined by reading the connection until it is closed by the server.
    13031303     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.
     1304     "chunked" transfer-coding is not the final encoding, the message-body
     1305     length cannot be determined reliably; the server &MUST; respond with
     1306     400 (Bad Request) and then close the connection.
    13071307    </t></x:lt>
    13081308    <x:lt><t>
     
    13571357</t>
    13581358<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.
     1359   Unless a transfer-coding other than "chunked" has been applied,
     1360   a client that sends a request containing a message-body &SHOULD;
     1361   use a valid Content-Length header field if the message-body length
     1362   is known in advance, rather than the "chunked" encoding, since some
     1363   existing services respond to "chunked" with a 411 (Length Required)
     1364   status code even though they understand the chunked encoding.  This
     1365   is typically because such services are implemented via a gateway that
     1366   requires a content-length in advance of being called and the server
     1367   is unable or unwilling to buffer the entire request before processing.
    13671368</t>
    13681369<t>
     
    13791380   prior to closing the connection is &OPTIONAL;.
    13801381   Response messages that are prematurely terminated, usually by closure
    1381    of the connection prior to receiving the given number of octets or by
     1382   of the connection prior to receiving the expected number of octets or by
    13821383   failure to decode a transfer-encoded message-body, &MUST; be recorded
    13831384   as incomplete.  A user agent &MUST-NOT; render an incomplete response
     
    19661967</t>
    19671968<t>
    1968    Whenever a transfer-coding is applied to a payload body, the set of
    1969    transfer-codings &MUST; include "chunked", unless the message indicates it
    1970    is terminated by closing the connection. When the "chunked" transfer-coding
    1971    is used, it &MUST; be the last transfer-coding applied to form the
    1972    message-body. The "chunked" transfer-coding &MUST-NOT; be applied more
    1973    than once to a message-body.
    1974 </t>
    1975 <t>
    19761969   Transfer-codings are analogous to the Content-Transfer-Encoding values of
    19771970   MIME, which were designed to enable safe transport of binary data over a
     
    20952088   "chunked" transfer-coding and &MUST; ignore chunk-ext extensions
    20962089   they do not understand.
     2090</t>
     2091<t>
     2092   Since "chunked" is the only transfer-coding required to be understood
     2093   by HTTP/1.1 recipients, it plays a crucial role in delimiting messages
     2094   on a persistent connection.  Whenever a transfer-coding is applied to
     2095   a payload body in a request, the final transfer-coding applied &MUST;
     2096   be "chunked".  If a transfer-coding is applied to a response payload
     2097   body, then either the final transfer-coding applied &MUST; be "chunked"
     2098   or the message &MUST; be terminated by closing the connection. When the
     2099   "chunked" transfer-coding is used, it &MUST; be the last transfer-coding
     2100   applied to form the message-body. The "chunked" transfer-coding &MUST-NOT;
     2101   be applied more than once in a message-body.
    20972102</t>
    20982103</section>
Note: See TracChangeset for help on using the changeset viewer.