Changeset 2108 for draft-ietf-httpbis/latest

Timestamp:

11/01/13 06:27:20 (10 years ago)

Author:

fielding@…

Message:

(editorial) Vary applies to any response content, not just the selected representation

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (2 diffs)
• p2-semantics.xml (modified) (2 diffs)

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

@@ -3017 +3017 @@
       <div id="rfc.figure.u.58"></div>
       <p>For example, a response that contains</p><pre class="text">  Vary: accept-encoding, accept-language
-</pre><p>indicates that the origin server might have used the request's <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> and <a href="#header.accept-language" class="smpl">Accept-Language</a> fields (or lack thereof) as determining factors while choosing this <a href="#selected.representation" class="smpl">selected representation</a>.
+</pre><p>indicates that the origin server might have used the request's <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> and <a href="#header.accept-language" class="smpl">Accept-Language</a> fields (or lack thereof) as determining factors while choosing the content for this response.
       </p>
       <p id="rfc.section.7.1.4.p.6">An origin server might send Vary with a list of fields for two purposes: </p>
@@ -3034 +3034 @@
       <p id="rfc.section.7.1.4.p.7">An origin server <em class="bcp14">SHOULD</em> send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message
          other than the method and request target, unless the variance cannot be crossed or the origin server has been deliberately
-         configured to prevent cache transparency. For example, there is no need to send the Authorization field name (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>) in Vary because reuse across users is constrained by the field definition. Likewise, Cache-Control directives (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) might be used to supplant the need for Vary, particularly when the variance is considered less significant than the performance
-         cost of Vary's impact on caching.
+         configured to prevent cache transparency. For example, there is no need to send the Authorization field name in Vary because
+         reuse across users is constrained by the field definition (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>). Likewise, an origin server might use Cache-Control directives (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching.
       </p>
       <div id="rfc.iref.s.7"></div>

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

@@ -3900 +3900 @@
 </artwork><postamble>indicates that the origin server might have used the
    request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref>
-   fields (or lack thereof) as determining factors while choosing this
-   <x:ref>selected representation</x:ref>.
+   fields (or lack thereof) as determining factors while choosing the content
+   for this response.
 </postamble></figure>
 <t>
@@ -3931 +3931 @@
    other than the method and request target, unless the variance cannot be
    crossed or the origin server has been deliberately configured to prevent
-   cache transparency. For example, there is no need to send the
-   Authorization field name (&header-authorization;) in Vary because
-   reuse across users is constrained by the field definition. Likewise,
-   Cache-Control directives (&header-cache-control;) might be used to supplant
-   the need for Vary, particularly when the variance is considered less
-   significant than the performance cost of Vary's impact on caching.
+   cache transparency. For example, there is no need to send the Authorization
+   field name in Vary because reuse across users is constrained by the field
+   definition (&header-authorization;). Likewise, an origin server might use
+   Cache-Control directives (&header-cache-control;) to supplant Vary if it
+   considers the variance less significant than the performance cost of Vary's
+   impact on caching.
 </t>
 </section>