Changeset 1261 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 07/04/11 01:08:58 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1260 r1261 359 359 } 360 360 @bottom-center { 361 content: "Expires October 7, 2011";361 content: "Expires October 9, 2011"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-04-0 5">411 <meta name="dct.issued" scheme="ISO8601" content="2011-04-07"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <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 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."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: October 7, 2011</td>442 <td class="left">Expires: October 9, 2011</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">April 5, 2011</td>495 <td class="right">April 7, 2011</td> 496 496 </tr> 497 497 </tbody> … … 520 520 in progress”. 521 521 </p> 522 <p>This Internet-Draft will expire on October 7, 2011.</p>522 <p>This Internet-Draft will expire on October 9, 2011.</p> 523 523 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 524 524 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 830 830 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. 831 831 </p> 832 <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>) and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used832 <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used 833 833 to satisfy a subsequent request. 834 834 </p> … … 1341 1341 to be completed without transferring data already held by the client. 1342 1342 </p> 1343 <p id="rfc.section.7.3.p.5">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1344 </p> 1345 <p id="rfc.section.7.3.p.6">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations when used for forms. 1343 <p id="rfc.section.7.3.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations 1344 to reject the request. 1345 </p> 1346 <p id="rfc.section.7.3.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1347 </p> 1348 <p id="rfc.section.7.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations when used for forms. 1346 1349 </p> 1347 1350 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2> … … 1355 1358 representation differs from the current representation (as would be indicated by a change in Content-Length, Content-MD5, 1356 1359 ETag or Last-Modified), then the cache <em class="bcp14">MUST</em> treat the cache entry as stale. 1360 </p> 1361 <p id="rfc.section.7.4.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations 1362 to reject the request. 1357 1363 </p> 1358 1364 <div id="rfc.iref.p.1"></div> … … 1456 1462 enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. 1457 1463 </p> 1458 <p id="rfc.section.7.7.p.3">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses 1464 <p id="rfc.section.7.7.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing 1465 implementations to reject the request. 1466 </p> 1467 <p id="rfc.section.7.7.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses 1459 1468 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1460 1469 </p> … … 1492 1501 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1493 1502 1494 </pre><p id="rfc.section.7.9.p.7">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats 1503 </pre><p id="rfc.section.7.9.p.7">Bodies on CONNECT requests have no defined semantics. Note that sending a body on a CONNECT request might cause some existing 1504 implementations to reject the request. 1505 </p> 1506 <p id="rfc.section.7.9.p.8">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats 1495 1507 also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if 1496 1508 more than one TCP segment is outstanding. … … 3022 3034 <ul> 3023 3035 <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" 3036 </li> 3037 <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" 3024 3038 </li> 3025 3039 </ul>
Note: See TracChangeset
for help on using the changeset viewer.