Changeset 137 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 03/01/08 16:21:04 (15 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r135 r137 1108 1108 <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1109 1109 </p> 1110 <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 ( Unimplemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.1110 <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. 1111 1111 </p> 1112 1112 <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a> <a id="chunked.transfer.encoding" href="#chunked.transfer.encoding">Chunked Transfer Coding</a></h3> … … 1230 1230 <p id="rfc.section.4.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 1231 1231 the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 6.1.1</a>). All responses to the HEAD request method <em class="bcp14">MUST NOT</em> include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational), 1232 204 ( no content), and 304 (not modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although it <em class="bcp14">MAY</em> be of zero length.1232 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although it <em class="bcp14">MAY</em> be of zero length. 1233 1233 </p> 1234 1234 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="message.length" href="#message.length">Message Length</a></h2> … … 1271 1271 </ol> 1272 1272 <p id="rfc.section.4.4.p.3">For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body 1273 and a Content-Length is not given, the server <em class="bcp14">SHOULD</em> respond with 400 ( bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes1273 and a Content-Length is not given, the server <em class="bcp14">SHOULD</em> respond with 400 (Bad Request) if it cannot determine the length of the message, or with 411 (Length Required) if it wishes 1274 1274 to insist on receiving a valid Content-Length. 1275 1275 </p>
Note: See TracChangeset
for help on using the changeset viewer.