Changeset 957 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 28/07/10 03:04:03 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r953 r957 1219 1219 <p id="rfc.section.3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field 1220 1220 in the request's header fields, even if the request method does not define any use for a message-body. This allows the request 1221 message framing algorithm to be independent of method semantics. A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response.1221 message framing algorithm to be independent of method semantics. 1222 1222 </p> 1223 1223 <p id="rfc.section.3.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and … … 1235 1235 </li> 1236 1236 <li> 1237 <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 9.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>) is used, the message-body length is determined by reading and decoding the chunked data until the transfer-coding indicates 1238 the data is complete. 1237 <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 9.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding 1238 indicates the data is complete. 1239 </p> 1240 <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding, 1241 the message-body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header 1242 field is present in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot 1243 be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection. 1239 1244 </p> 1240 1245 <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding … … 1243 1248 is decoded. 1244 1249 </p> 1245 <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not present, the message-body1246 length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present1247 in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot be determined reliably;1248 the server <em class="bcp14">MUST</em> respond with 400 (Bad Request) and then close the connection.1249 </p>1250 1250 </li> 1251 1251 <li> 1252 <p>If a valid Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 9.2</a>) is present without Transfer-Encoding, its decimal value in octets defines the message-body length. If the actual number 1253 of octets sent in the message is less than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in 1254 the message is less than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message-body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on on a connection 1255 and the connection has been closed by the server. 1256 </p> 1257 <p>If a message is received with multiple Content-Length header fields or a Content-Length header field with an invalid value, 1258 the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy 1252 <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields or a single Content-Length 1253 header field with an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy 1259 1254 or gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection. 1260 1255 If this is a response message received by a user-agent, the message-body length is determined by reading the connection until … … 1263 1258 </li> 1264 1259 <li> 1260 <p>If a valid Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 9.2</a>) is present without Transfer-Encoding, its decimal value defines the message-body length in octets. If the actual number 1261 of octets sent in the message is less than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in 1262 the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message-body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on on a connection 1263 and the connection has been closed by the server. 1264 </p> 1265 </li> 1266 <li> 1265 1267 <p>If this is a request message and none of the above are true, then the message-body length is zero (no message-body is present).</p> 1266 1268 </li> … … 1288 1290 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 1289 1291 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>. 1292 </p> 1293 <p id="rfc.section.3.3.p.14">A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response, since otherwise the remaining data 1294 on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message-body if it intends to reuse the same connection for a subsequent request. Pipelining multiple 1295 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 7.1.2.2</a>. 1290 1296 </p> 1291 1297 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2>
Note: See TracChangeset
for help on using the changeset viewer.