Changeset 1999 for draft-ietf-httpbis

Timestamp:

27/11/12 03:10:52 (10 years ago)

Author:

mnot@…

Message:

Replace caching details with reference to p6; addresses #403.

Location:

draft-ietf-httpbis/latest

Files:

• p7-auth.html (modified) (6 diffs)
• p7-auth.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p7-auth.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires May 8, 2013"; 
+       content: "Expires May 31, 2013"; 
   } 
   @bottom-right {
@@ -484 +484 @@
       <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D">
       <link href="p6-cache.html" rel="prev">
-      <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.">
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-11-04">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-11-27">
       <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, hypermedia information systems. This document defines the HTTP Authentication framework.">
@@ -517 +517 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">November 4, 2012</td>
+               <td class="right">November 27, 2012</td>
             </tr>
             <tr>
-               <td class="left">Expires: May 8, 2013</td>
+               <td class="left">Expires: May 31, 2013</td>
                <td class="right"></td>
             </tr>
@@ -546 +546 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on May 8, 2013.</p>
+      <p>This Internet-Draft will expire on May 31, 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>
@@ -799 +799 @@
          such as credentials that vary according to a challenge value or using synchronized clocks).
       </p>
-      <p id="rfc.section.4.1.p.4">When a shared cache (see <a href="p6-cache.html#shared.and.non-shared.caches">Section 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) receives a request containing an Authorization field, it <em class="bcp14">MUST NOT</em> return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:
-      </p>
-      <p id="rfc.section.4.1.p.5"> </p>
-      <ol>
-         <li>If the response includes the "s-maxage" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache <em class="bcp14">MUST</em> first revalidate it with the origin server, using the header fields from the new request to allow the origin server to authenticate
-            the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy <em class="bcp14">MUST</em> always revalidate it before re-using it.
-         </li>
-         <li>If the response includes the "must-revalidate" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But if the response is stale, all caches <em class="bcp14">MUST</em> first revalidate it with the origin server, using the header fields from the new request to allow the origin server to authenticate
-            the new request.
-         </li>
-         <li>If the response includes the "public" cache-control directive, it <em class="bcp14">MAY</em> be returned in reply to any subsequent request.
-         </li>
-      </ol>
+      <p id="rfc.section.4.1.p.4">See <a href="p6-cache.html#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for details of and requirements pertaining to handling of the Authorization field by HTTP caches.
+      </p>
       <div id="rfc.iref.p.2"></div>
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
@@ -1181 +1170 @@
                   </li>
                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a>, <a href="#Part6"><b>8.1</b></a><ul>
-                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a></li>
+                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a></li>
                      </ul>
                   </li>

draft-ietf-httpbis/latest/p7-auth.xml

@@ -28 +28 @@
   <!ENTITY end-to-end.and-hop-by-hop    "<xref target='Part1' x:rel='#end-to-end.and.hop-by-hop.header-fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status.403                   "<xref target='Part2' x:rel='#status.403' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY caching-authenticated-responses "<xref target='Part6' x:rel='#caching.authenticated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
 ]>
 <?rfc toc="yes" ?>
@@ -482 +482 @@
 </t>
 <t>
-      When a shared cache (see &shared-and-non-shared-caches;) receives a request
-      containing an Authorization field, it &MUST-NOT; return the
-      corresponding response as a reply to any other request, unless one
-      of the following specific exceptions holds:
-</t>
-<t>
-  <list style="numbers">
-      <t>If the response includes the "s-maxage" cache-control
-         directive, the cache &MAY; use that response in replying to a
-         subsequent request. But (if the specified maximum age has
-         passed) a proxy cache &MUST; first revalidate it with the origin
-         server, using the header fields from the new request to allow
-         the origin server to authenticate the new request. (This is the
-         defined behavior for s-maxage.) If the response includes "s-maxage=0",
-         the proxy &MUST; always revalidate it before re-using
-         it.</t>
-
-      <t>If the response includes the "must-revalidate" cache-control
-         directive, the cache &MAY; use that response in replying to a
-         subsequent request. But if the response is stale, all caches
-         &MUST; first revalidate it with the origin server, using the
-         header fields from the new request to allow the origin server
-         to authenticate the new request.</t>
-
-      <t>If the response includes the "public" cache-control directive,
-         it &MAY; be returned in reply to any subsequent request.</t>
-  </list>
+   See &caching-authenticated-responses; for details of and requirements
+   pertaining to handling of the Authorization field by HTTP caches.
 </t>
 </section>