Changeset 873 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 23/07/10 01:37:57 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r870 r873 1238 1238 </p> 1239 1239 <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not present, the message-body 1240 length is determined by reading the connection until it is closed. If a Transfer-Encoding header field is present in a request 1241 and the "chunked" transfer-coding is not present, the message-body length cannot be determined reliably; the server <em class="bcp14">MUST</em> respond with 400 (Bad Request) and then close the connection. 1240 length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present 1241 in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot be determined reliably; 1242 the server <em class="bcp14">MUST</em> respond with 400 (Bad Request) and then close the connection. 1242 1243 </p> 1243 1244 </li> … … 1270 1271 <p id="rfc.section.3.3.p.10">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required). 1271 1272 </p> 1272 <p id="rfc.section.3.3.p.11"> A client that sends a request containing a message-body <em class="bcp14">SHOULD</em> include a valid Content-Length header field if the message-body length is known in advance, since many existing services will1273 otherwise respond with a 411 (Length Required) status code though they can handle the chunked encoding. This is typically1274 because such services are implemented via a gateway that requires a content-length in advance of being called and the server1275 is unable or unwilling to buffer the entire request before processing.1273 <p id="rfc.section.3.3.p.11">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message-body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding, 1274 since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the 1275 chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in 1276 advance of being called and the server is unable or unwilling to buffer the entire request before processing. 1276 1277 </p> 1277 1278 <p id="rfc.section.3.3.p.12">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such 1278 1279 knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. 1279 1280 </p> 1280 <p id="rfc.section.3.3.p.13">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the given number1281 of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an1281 <p id="rfc.section.3.3.p.13">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected 1282 number of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an 1282 1283 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1283 1284 </p> … … 1567 1568 </pre><p id="rfc.section.6.2.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 9.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 9.7</a>). 1568 1569 </p> 1569 <p id="rfc.section.6.2.p.6">Whenever a transfer-coding is applied to a payload body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding 1570 is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. 1571 </p> 1572 <p id="rfc.section.6.2.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport 1570 <p id="rfc.section.6.2.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport 1573 1571 of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic 1574 1572 of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section 3.3</a>), or the desire to encrypt data over a shared transport. 1575 1573 </p> 1576 <p id="rfc.section.6.2.p. 8">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.1574 <p id="rfc.section.6.2.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. 1577 1575 </p> 1578 1576 <div id="rfc.iref.c.5"></div> … … 1642 1640 Remove "chunked" from Transfer-Encoding 1643 1641 </pre><p id="rfc.section.6.2.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand. 1642 </p> 1643 <p id="rfc.section.6.2.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting 1644 messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding 1645 applied <em class="bcp14">MUST</em> be "chunked". If a transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. 1644 1646 </p> 1645 1647 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>
Note: See TracChangeset
for help on using the changeset viewer.