Changeset 2268 for draft-ietf-httpbis/latest

Timestamp:

21/05/13 17:18:06 (10 years ago)

Author:

julian.reschke@…

Message:

"header" -> "header field" (plus a two paragraphs in changes from 2616 collapsed)

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (4 diffs)
• p6-cache.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p6-cache.html

@@ -1086 +1086 @@
       </p>
       <p id="rfc.section.4.3.p.5">The stored response with matching selecting header fields is known as the selected response.</p>
-      <p id="rfc.section.4.3.p.6">If multiple selected responses are available (potentially including responses without a Vary header), the cache will need
-         to choose one to use. When a selecting header has a known mechanism for doing so (e.g., qvalues on <a href="p2-semantics.html#header.accept" class="smpl">Accept</a> and similar request header fields), that mechanism <em class="bcp14">MAY</em> be used to select preferred responses; of the remainder, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used, as per <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;4</a>.
+      <p id="rfc.section.4.3.p.6">If multiple selected responses are available (potentially including responses without a Vary header field), the cache will
+         need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on <a href="p2-semantics.html#header.accept" class="smpl">Accept</a> and similar request header fields), that mechanism <em class="bcp14">MAY</em> be used to select preferred responses; of the remainder, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used, as per <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;4</a>.
       </p>
       <p id="rfc.section.4.3.p.7">If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin
@@ -1755 +1755 @@
          (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.
       </p>
-      <p id="rfc.section.10.p.6">Note that the Set-Cookie response header <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> does not inhibit caching; a cacheable response with a Set-Cookie header can be (and often is) used to satisfy subsequent requests
-         to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response
-         header fields.
+      <p id="rfc.section.10.p.6">Note that the Set-Cookie response header field <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent
+         requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control
+         response header fields.
       </p>
       <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
@@ -1889 +1889 @@
       <p id="rfc.section.A.p.17">Caches are now allow to calculate heuristic freshness for URLs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>)
       </p>
-      <p id="rfc.section.A.p.18">Some requirements regarding production of the <a href="#header.warning" class="smpl">Warning</a> header have been relaxed, as it is not widely implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;7.5</a>)
-      </p>
-      <p id="rfc.section.A.p.19">The <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor allows multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.7" title="Warning">Section&nbsp;7.5</a>)
-      </p>
-      <p id="rfc.section.A.p.20">This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives.
+      <p id="rfc.section.A.p.18">Some requirements regarding production of the <a href="#header.warning" class="smpl">Warning</a> header fields have been relaxed, as it is not widely implemented. Furthermore, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor allows multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;7.5</a>)
+      </p>
+      <p id="rfc.section.A.p.19">This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives.
          (<a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a> and <a href="#warn.code.extensions" title="Warn Code Extensions">Section&nbsp;7.5.8</a>)
       </p>
@@ -2182 +2180 @@
             </li>
             <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul>
-                  <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.1.4</a>, <a href="#rfc.xref.header.warning.3">4.2.1</a>, <a href="#rfc.xref.header.warning.4">5</a>, <a href="#rfc.iref.w.1"><b>7.5</b></a>, <a href="#rfc.xref.header.warning.5">9.3</a>, <a href="#rfc.xref.header.warning.6">A</a>, <a href="#rfc.xref.header.warning.7">A</a></li>
+                  <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.1.4</a>, <a href="#rfc.xref.header.warning.3">4.2.1</a>, <a href="#rfc.xref.header.warning.4">5</a>, <a href="#rfc.iref.w.1"><b>7.5</b></a>, <a href="#rfc.xref.header.warning.5">9.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li>
                </ul>
             </li>

draft-ietf-httpbis/latest/p6-cache.xml

@@ -924 +924 @@
 <t>
    If multiple selected responses are available (potentially including
-   responses without a Vary header), the cache will need to choose one to use.
-   When a selecting header has a known mechanism for doing so (e.g., qvalues on
+   responses without a Vary header field), the cache will need to choose one to use.
+   When a selecting header field has a known mechanism for doing so (e.g., qvalues on
    <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be
    used to select preferred responses; of the remainder, the most recent
@@ -2051 +2051 @@
 </t>
 <t>
-   Note that the Set-Cookie response header <xref target="RFC6265"/> does not
-   inhibit caching; a cacheable response with a Set-Cookie header can be (and
+   Note that the Set-Cookie response header field <xref target="RFC6265"/> does not
+   inhibit caching; a cacheable response with a Set-Cookie header field can be (and
    often is) used to satisfy subsequent requests to caches. Servers who wish
    to control caching of these responses are encouraged to emit appropriate
@@ -2432 +2432 @@
 <t>
   Some requirements regarding production of the <x:ref>Warning</x:ref> 
-  header have been relaxed, as it is not widely implemented.
-  (<xref target="header.warning" />)
-</t>
-<t>
-  The <x:ref>Warning</x:ref> header field no longer uses RFC 2047 encoding,
+  header fields have been relaxed, as it is not widely implemented.
+  Furthermore, the <x:ref>Warning</x:ref> header field no longer uses RFC 2047 encoding,
   nor allows multiple languages, as these aspects were not implemented.
   (<xref target="header.warning" />)