Source: https://trac.ietf.org/trac/httpbis/changeset/1913
Timestamp: 2019-11-18 04:25:46
Document Index: 592784631

Matched Legal Cases: ['art6', 'art6', 'art6', 'art6', 'art6', 'art6']

Changeset 1913 – Hypertext Transfer Protocol Wiki
Sep 26, 2012, 9:14:22 AM (7 years ago)
mnot@…
Make it crystal clear that cached POST responses can't be used to satisfy future POST requests
content: "Expires March 26, 2013";
content: "Expires March 30, 2013";
<meta name="dct.issued" scheme="ISO8601" content="2012-09-22">
<meta name="dct.issued" scheme="ISO8601" content="2012-09-26">
<td class="left">Expires: March 26, 2013</td>
<td class="left">Expires: March 30, 2013</td>
<td class="right">September 22, 2012</td>
<td class="right">September 26, 2012</td>
<p>This Internet-Draft will expire on March 26, 2013.</p>
<p>This Internet-Draft will expire on March 30, 2013.</p>
<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 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 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.
cached POST response with a <x:ref>Content-Location</x:ref> header field
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.