Changeset 2266 for draft-ietf-httpbis/latest

Timestamp:

20/05/13 21:51:33 (7 years ago)

Author:

julian.reschke@…

Message:

header -> header field

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (2 diffs)
• p6-cache.xml (modified) (2 diffs)

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

@@ -1087 +1087 @@
       <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 headers), 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>.
+         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>
       <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
@@ -1757 +1757 @@
       <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
-         headers.
+         header fields.
       </p>
       <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>

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

@@ -926 +926 @@
    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
-   <x:ref>Accept</x:ref> and similar request headers), that mechanism &MAY; be
+   <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
    response (as determined by the <x:ref>Date</x:ref> header field) is used, as
@@ -2055 +2055 @@
    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 headers.
+   Cache-Control response header fields.
 </t>