Changeset 1544 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 21/02/12 02:12:49 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1539 r1544 460 460 } 461 461 @bottom-center { 462 content: "Expires August 2 2, 2012";462 content: "Expires August 23, 2012"; 463 463 } 464 464 @bottom-right { … … 513 513 <meta name="dct.creator" content="Reschke, J. F."> 514 514 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 515 <meta name="dct.issued" scheme="ISO8601" content="2012-02- 19">515 <meta name="dct.issued" scheme="ISO8601" content="2012-02-20"> 516 516 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 517 517 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 544 544 </tr> 545 545 <tr> 546 <td class="left">Expires: August 2 2, 2012</td>546 <td class="left">Expires: August 23, 2012</td> 547 547 <td class="right">HP</td> 548 548 </tr> … … 597 597 <tr> 598 598 <td class="left"></td> 599 <td class="right">February 19, 2012</td>599 <td class="right">February 20, 2012</td> 600 600 </tr> 601 601 </tbody> … … 627 627 in progress”. 628 628 </p> 629 <p>This Internet-Draft will expire on August 2 2, 2012.</p>629 <p>This Internet-Draft will expire on August 23, 2012.</p> 630 630 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 631 631 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 947 947 to a single application, so that this is clear. 948 948 </p> 949 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message -body on either the request or the response message949 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message 950 950 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 951 951 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 1438 1438 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 1439 1439 </p> 1440 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message -body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied1440 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied 1441 1441 to ensure safe and proper transfer of the message. 1442 1442 </p> … … 1498 1498 </p> 1499 1499 <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p> 1500 <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message -body (as indicated by the presence of Content-Length or Transfer-Encoding), then1500 <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then 1501 1501 the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions 1502 1502 to HTTP might use the OPTIONS body to make more detailed queries on the server. … … 1543 1543 <div id="rfc.iref.h.1"></div> 1544 1544 <div id="rfc.iref.m.3"></div> 1545 <p id="rfc.section.6.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message -body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the1545 <p id="rfc.section.6.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1546 1546 representation implied by the request without transferring the representation body. This method is often used for testing 1547 1547 hypertext links for validity, accessibility, and recent modification. … … 1663 1663 <div id="rfc.iref.t.1"></div> 1664 1664 <div id="rfc.iref.m.7"></div> 1665 <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message -body of a 200 (OK) response. The final recipient is either1666 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message -body.1665 <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either 1666 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1667 1667 </p> 1668 1668 <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing … … 1671 1671 infinite loop. 1672 1672 </p> 1673 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message -body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1673 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1674 1674 </p> 1675 1675 <div id="rfc.iref.c.1"></div> … … 1768 1768 <dd>a representation of the target resource is sent in the response;</dd> 1769 1769 <dt>HEAD</dt> 1770 <dd>the same representation as GET, except without the message -body;</dd>1770 <dd>the same representation as GET, except without the message body;</dd> 1771 1771 <dt>POST</dt> 1772 1772 <dd>a representation describing or containing the result of the action;</dd> … … 1830 1830 automated data transfers to be prevalent, such as within distributed version control systems. 1831 1831 </p> 1832 <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message -body, and thus is always terminated by the first empty line after the header fields.1832 <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields. 1833 1833 </p> 1834 1834 <div id="rfc.iref.29"></div> … … 1839 1839 another input action. 1840 1840 </p> 1841 <p id="rfc.section.7.2.6.p.2">The message -body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1841 <p id="rfc.section.7.2.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1842 1842 </p> 1843 1843 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 2064 2064 <div id="rfc.iref.s.26"></div> 2065 2065 <h3 id="rfc.section.7.4.10"><a href="#rfc.section.7.4.10">7.4.10</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> 2066 <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message -body in the request2066 <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request 2067 2067 message. 2068 2068 </p> … … 3451 3451 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>>: "untangle ABNFs for header fields" 3452 3452 </li> 3453 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>>: "message -body in CONNECT request"3453 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>>: "message body in CONNECT request" 3454 3454 </li> 3455 3455 </ul>
Note: See TracChangeset
for help on using the changeset viewer.