Changeset 957 for draft-ietf-httpbis
- Timestamp:
- 28/07/10 03:04:03 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 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> -
draft-ietf-httpbis/latest/p1-messaging.xml
r953 r957 1276 1276 define any use for a message-body. This allows the request 1277 1277 message framing algorithm to be independent of method semantics. 1278 A server &MUST; read the entire request message-body or close1279 the connection after sending its response.1280 1278 </t> 1281 1279 <t> … … 1306 1304 If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>) 1307 1305 is present and the "chunked" transfer-coding (<xref target="transfer.codings"/>) 1308 is used, the message-body length is determined by reading and decoding the 1309 chunked data until the transfer-coding indicates the data is complete. 1306 is the final encoding, the message-body length is determined by reading 1307 and decoding the chunked data until the transfer-coding indicates the 1308 data is complete. 1309 </t> 1310 <t> 1311 If a Transfer-Encoding header field is present in a response and the 1312 "chunked" transfer-coding is not the final encoding, the message-body 1313 length is determined by reading the connection until it is closed by 1314 the server. 1315 If a Transfer-Encoding header field is present in a request and the 1316 "chunked" transfer-coding is not the final encoding, the message-body 1317 length cannot be determined reliably; the server &MUST; respond with 1318 the 400 (Bad Request) status code and then close the connection. 1310 1319 </t> 1311 1320 <t> … … 1317 1326 be removed, prior to forwarding the message downstream, or replaced with 1318 1327 the real message-body length after the transfer-coding is decoded. 1319 </t>1320 <t>1321 If a Transfer-Encoding header field is present in a response and the1322 "chunked" transfer-coding is not present, the message-body length is1323 determined by reading the connection until it is closed by the server.1324 If a Transfer-Encoding header field is present in a request and the1325 "chunked" transfer-coding is not the final encoding, the message-body1326 length cannot be determined reliably; the server &MUST; respond with1327 400 (Bad Request) and then close the connection.1328 1328 </t></x:lt> 1329 1329 <x:lt><t> 1330 If a valid Content-Length header field (<xref target="header.content-length"/>) 1331 is present without Transfer-Encoding, its decimal value in octets defines 1332 the message-body length. If the actual number of octets sent in the message 1333 is less than the indicated Content-Length, the recipient &MUST; consider 1334 the message to be incomplete and treat the connection as no longer usable. 1335 If the actual number of octets sent in the message is less than the indicated 1336 Content-Length, the recipient &MUST; only process the message-body up to the 1337 field value's number of octets; the remainder of the message &MUST; either 1338 be discarded or treated as the next message in a pipeline. For the sake of 1339 robustness, a user-agent &MAY; attempt to detect and correct such an error 1340 in message framing if it is parsing the response to the last request on 1341 on a connection and the connection has been closed by the server. 1342 </t> 1343 <t> 1344 If a message is received with multiple Content-Length header fields or a 1345 Content-Length header field with an invalid value, the message framing 1346 is invalid and &MUST; be treated as an error to prevent request or 1347 response smuggling. 1330 If a message is received without Transfer-Encoding and with either 1331 multiple Content-Length header fields or a single Content-Length header 1332 field with an invalid value, then the message framing is invalid and 1333 &MUST; be treated as an error to prevent request or response smuggling. 1348 1334 If this is a request message, the server &MUST; respond with 1349 1335 a 400 (Bad Request) status code and then close the connection. … … 1354 1340 length is determined by reading the connection until it is closed; 1355 1341 an error &SHOULD; be indicated to the user. 1342 </t></x:lt> 1343 <x:lt><t> 1344 If a valid Content-Length header field (<xref target="header.content-length"/>) 1345 is present without Transfer-Encoding, its decimal value defines the 1346 message-body length in octets. If the actual number of octets sent in 1347 the message is less than the indicated Content-Length, the recipient 1348 &MUST; consider the message to be incomplete and treat the connection 1349 as no longer usable. 1350 If the actual number of octets sent in the message is more than the indicated 1351 Content-Length, the recipient &MUST; only process the message-body up to the 1352 field value's number of octets; the remainder of the message &MUST; either 1353 be discarded or treated as the next message in a pipeline. For the sake of 1354 robustness, a user-agent &MAY; attempt to detect and correct such an error 1355 in message framing if it is parsing the response to the last request on 1356 on a connection and the connection has been closed by the server. 1356 1357 </t></x:lt> 1357 1358 <x:lt><t> … … 1407 1408 to the user that an error occurred). Cache requirements for incomplete 1408 1409 responses are defined in &cache-incomplete;. 1410 </t> 1411 <t> 1412 A server &MUST; read the entire request message-body or close 1413 the connection after sending its response, since otherwise the 1414 remaining data on a persistent connection would be misinterpreted 1415 as the next request. Likewise, 1416 a client &MUST; read the entire response message-body if it intends 1417 to reuse the same connection for a subsequent request. Pipelining 1418 multiple requests on a connection is described in <xref target="pipelining"/>. 1409 1419 </t> 1410 1420 </section> -
draft-ietf-httpbis/latest/p3-payload.html
r942 r957 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 6">403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-27"> 404 404 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 405 405 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: January 2 7, 2011</td>429 <td class="left">Expires: January 28, 2011</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">July 2 6, 2010</td>486 <td class="right">July 27, 2010</td> 487 487 </tr> 488 488 </tbody> … … 510 510 in progress”. 511 511 </p> 512 <p>This Internet-Draft will expire in January 2 7, 2011.</p>512 <p>This Internet-Draft will expire in January 28, 2011.</p> 513 513 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 514 514 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p4-conditional.html
r928 r957 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 4">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-27"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: January 2 5, 2011</td>428 <td class="left">Expires: January 28, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">July 2 4, 2010</td>485 <td class="right">July 27, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 2 5, 2011.</p>511 <p>This Internet-Draft will expire in January 28, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p5-range.html
r931 r957 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 4">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-27"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: January 2 5, 2011</td>428 <td class="left">Expires: January 28, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">July 2 4, 2010</td>485 <td class="right">July 27, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 2 5, 2011.</p>511 <p>This Internet-Draft will expire in January 28, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r923 r957 393 393 <meta name="dct.creator" content="Reschke, J. F."> 394 394 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 395 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 4">395 <meta name="dct.issued" scheme="ISO8601" content="2010-07-27"> 396 396 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 397 397 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 424 424 </tr> 425 425 <tr> 426 <td class="left">Expires: January 2 5, 2011</td>426 <td class="left">Expires: January 28, 2011</td> 427 427 <td class="right">HP</td> 428 428 </tr> … … 477 477 <tr> 478 478 <td class="left"></td> 479 <td class="right">July 2 4, 2010</td>479 <td class="right">July 27, 2010</td> 480 480 </tr> 481 481 </tbody> … … 503 503 in progress”. 504 504 </p> 505 <p>This Internet-Draft will expire in January 2 5, 2011.</p>505 <p>This Internet-Draft will expire in January 28, 2011.</p> 506 506 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 507 507 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.