Changeset 1913

Timestamp:

26/09/12 16:14:22 (11 years ago)

Author:

mnot@…

Message:

Make it crystal clear that cached POST responses can't be used to satisfy future POST requests

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (6 diffs)
• p2-semantics.xml (modified) (1 diff)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires March 26, 2013"; 
+       content: "Expires March 30, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <link href="p1-messaging.html" rel="prev">
       <link href="p4-conditional.html" rel="next">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.588, 2012-08-25 12:28:24, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.588, 2012-08-25 12:28:24, XSLT vendor: SAXON 9.1.0.8 from Saxonica http://www.saxonica.com/">
       <link rel="schema.dct" href="http://purl.org/dc/terms/">
       <meta name="dct.creator" content="Fielding, R.">
@@ -497 +497 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-09-22">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-09-26">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
@@ -528 +528 @@
             </tr>
             <tr>
-               <td class="left">Expires: March 26, 2013</td>
+               <td class="left">Expires: March 30, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">September 22, 2012</td>
+               <td class="right">September 26, 2012</td>
             </tr>
          </tbody>
@@ -560 +560 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 26, 2013.</p>
+      <p>This Internet-Draft will expire on March 30, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1414 +1414 @@
       <p id="rfc.section.4.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.1.1</a>).
       </p>
-      <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.1.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
+      <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.1.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD (not POST) requests.
       </p>
       <p id="rfc.section.4.3.3.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -1196 +1196 @@
 </t>
 <t>
-   Responses to POST requests are only cacheable when they
-   include explicit freshness information (see &p6-explicit;). A
-   cached POST response with a <x:ref>Content-Location</x:ref> header field 
-   (see &header-content-location;) whose value is the effective 
-   Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
+   Responses to POST requests are only cacheable when they include explicit
+   freshness information (see &p6-explicit;). A cached POST response with a
+   <x:ref>Content-Location</x:ref> header field (see
+   &header-content-location;) whose value is the effective Request URI &MAY;
+   be used to satisfy subsequent GET and HEAD (not POST) requests.
 </t>
 <t>