Changeset 1858 for draft-ietf-httpbis


Ignore:
Timestamp:
03/09/12 21:29:18 (9 years ago)
Author:
fielding@…
Message:

(editorial) change of terms for content negotiation:

server-driven => proactive (UA sends Accept* fields)
agent-driven => reactive (UA waits for 300/Alternatives)

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

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

    r1857 r1858  
    597597               <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
    598598               <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
    599                      <li><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
    600                      <li><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
     599                     <li><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li>
     600                     <li><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li>
    601601                  </ul>
    602602               </li>
    … …  
    11181118         more than one is available.
    11191119      </p>
    1120       <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
    1121          based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations
    1122          for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an
    1123          "active content" pattern, where the server returns active content which runs on the client and, based on client available
    1124          parameters, selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
     1120      <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based
     1121         upon the client's stated preferences, and "reactive" negotiation, where the server provides a list of representations for
     1122         the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an "active
     1123         content" pattern, where the server returns active content which runs on the client and, based on client available parameters,
     1124         selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
    11251125      </p>
    11261126      <p id="rfc.section.3.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
    11271127         of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
    1128          a user-agent), server-driven negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
    1129          to choose from is very large, agent-driven negotiation might not be appropriate.
     1128         a user-agent), proactive negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
     1129         to choose from is very large, reactive negotiation might not be appropriate.
    11301130      </p>
    11311131      <p id="rfc.section.3.5.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might
    11321132         be considered to be the "same information".
    11331133      </p>
    1134       <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;<a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h3>
    1135       <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven
     1134      <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
     1135      <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive
    11361136         negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g.,
    11371137         language, content-coding, etc.) and the contents of particular header fields in the request message or on other information
    11381138         pertaining to the request (such as the network address of the client).
    11391139      </p>
    1140       <p id="rfc.section.3.5.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
     1140      <p id="rfc.section.3.5.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
    11411141         to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
    11421142         (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
    11431143         improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response.
    11441144      </p>
    1145       <p id="rfc.section.3.5.1.p.3">Server-driven negotiation has disadvantages: </p>
     1145      <p id="rfc.section.3.5.1.p.3">Proactive negotiation has disadvantages: </p>
    11461146      <ol>
    11471147         <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require
    … …  
    11551155         <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    11561156      </ol>
    1157       <p id="rfc.section.3.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor
    1158          them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response
    1159          that doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
     1157      <p id="rfc.section.3.5.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.
     1158         For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that
     1159         doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
    11601160            (Not Acceptable)</a> response.
    11611161      </p>
    1162       <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
     1162      <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
    11631163         and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;6.3.2</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.3.3</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;6.3.4</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.3.5</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;6.5.3</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    11641164         within extension header fields not defined by this specification.
    … …  
    11681168         </p>
    11691169      </div>
    1170       <p id="rfc.section.3.5.1.p.7">The <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header field (<a href="p6-cache.html#header.vary" title="Vary">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
    1171       </p>
    1172       <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h3>
    1173       <p id="rfc.section.3.5.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
     1170      <p id="rfc.section.3.5.1.p.7">The <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header field (<a href="p6-cache.html#header.vary" title="Vary">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation.
     1171      </p>
     1172      <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;<a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>
     1173      <p id="rfc.section.3.5.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving
    11741174         an initial response from the origin server. Selection is based on a list of the available representations of the response
    11751175         included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
    … …  
    11771177         user selecting from a generated (possibly hypertext) menu.
    11781178      </p>
    1179       <p id="rfc.section.3.5.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,
    1180          or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
     1179      <p id="rfc.section.3.5.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
     1180         encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
    11811181         when public caches are used to distribute server load and reduce network usage.
    11821182      </p>
    1183       <p id="rfc.section.3.5.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
     1183      <p id="rfc.section.3.5.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
    11841184         This second request is only efficient when caching is used. In addition, this specification does not define any mechanism
    11851185         for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension
    11861186         and used within HTTP/1.1.
    11871187      </p>
    1188       <p id="rfc.section.3.5.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using
    1189          server-driven negotiation.
     1188      <p id="rfc.section.3.5.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using
     1189         proactive negotiation.
    11901190      </p>
    11911191      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="payload" href="#payload">Payload</a></h1>
    … …  
    17141714      </div>
    17151715      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
    1716       <p id="rfc.section.6.3.1.p.1">Many of the request header fields for server-driven content negotiation use a common parameter, named "q", to assign a relative
     1716      <p id="rfc.section.6.3.1.p.1">Many of the request header fields for proactive content negotiation use a common parameter, named "q", to assign a relative
    17171717         "weight" to the preference for that associated kind of content. This weight is referred to as a "quality value" (or "qvalue")
    17181718         because the same parameter name is often used within server configurations to assign a weight to the relative quality of the
    … …  
    24172417         </li>
    24182418         <li>
    2419             <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="#agent-driven.negotiation" title="Agent-driven Negotiation">Section&nbsp;3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
     2419            <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section&nbsp;3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
    24202420            </p>
    24212421         </li>
    … …  
    24462446      <div id="rfc.iref.s.14"></div>
    24472447      <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
    2448       <p id="rfc.section.7.4.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information
     2448      <p id="rfc.section.7.4.1.p.1">The target resource has more than one representation, each with its own specific location, and reactive negotiation information
    24492449         (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.5</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
    24502450         location.

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

    r1857 r1858  
    2727  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2828  <!ENTITY content-negotiation        "<xref target='content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    29   <!ENTITY agent-driven-negotiation   "<xref target='agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     29  <!ENTITY reactive-negotiation       "<xref target='reactive.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3030  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3131  <!ENTITY whitespace                 "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    703703<t>
    704704   This specification defines two patterns of content negotiation;
    705    "server-driven", where the server selects the representation based
    706    upon the client's stated preferences, and "agent-driven" negotiation,
     705   "proactive", where the server selects the representation based
     706   upon the client's stated preferences, and "reactive" negotiation,
    707707   where the server provides a list of representations for the client to
    708708   choose from, based upon their metadata. In addition,  there are
    … …  
    717717   and practicality. In particular, when the number of preferences or
    718718   capabilities to be expressed by a client are large (such as when many
    719    different formats are supported by a user-agent), server-driven
     719   different formats are supported by a user-agent), proactive
    720720   negotiation becomes unwieldy, and might not be appropriate. Conversely,
    721721   when the number of representations to choose from is very large,
    722    agent-driven negotiation might not be appropriate.
     722   reactive negotiation might not be appropriate.
    723723</t>
    724724<t>
    … …  
    728728</t>
    729729
    730 <section title="Server-driven Negotiation" anchor="server-driven.negotiation">
     730<section title="Proactive Negotiation" anchor="proactive.negotiation">
    731731<t>
    732732   If the selection of the best representation for a response is made by
    733    an algorithm located at the server, it is called server-driven
     733   an algorithm located at the server, it is called proactive
    734734   negotiation. Selection is based on the available representations of
    735735   the response (the dimensions over which it can vary; e.g., language,
    … …  
    739739</t>
    740740<t>
    741    Server-driven negotiation is advantageous when the algorithm for
     741   Proactive negotiation is advantageous when the algorithm for
    742742   selecting from among the available representations is difficult to
    743743   describe to the user agent, or when the server desires to send its
    … …  
    750750</t>
    751751<t>
    752    Server-driven negotiation has disadvantages:
     752   Proactive negotiation has disadvantages:
    753753  <list style="numbers">
    754754    <t>
    … …  
    776776</t>
    777777<t>
    778    Server-driven negotiation allows the user agent to specify its preferences,
     778   Proactive negotiation allows the user agent to specify its preferences,
    779779   but it cannot expect responses to always honor them. For example, the origin
    780    server might not implement server-driven negotiation, or it might decide that
     780   server might not implement proactive negotiation, or it might decide that
    781781   sending a response that doesn't conform to them is better than sending a <x:ref>406
    782782   (Not Acceptable)</x:ref> response.
    … …  
    784784<t>
    785785   HTTP/1.1 includes the following header fields for enabling
    786    server-driven negotiation through description of user agent
     786   proactive negotiation through description of user agent
    787787   capabilities and user preferences: <x:ref>Accept</x:ref>
    788788   (<xref target="header.accept"/>), <x:ref>Accept-Charset</x:ref>
    … …  
    805805   The <x:ref>Vary</x:ref> header field (&header-vary;) can be used to express
    806806   the parameters the server uses to select a representation that is subject to
    807    server-driven negotiation.
    808 </t>
    809 </section>
    810 
    811 <section title="Agent-driven Negotiation" anchor="agent-driven.negotiation">
    812 <t>
    813    With agent-driven negotiation, selection of the best representation
     807   proactive negotiation.
     808</t>
     809</section>
     810
     811<section title="Reactive Negotiation" anchor="reactive.negotiation">
     812<t>
     813   With reactive negotiation, selection of the best representation
    814814   for a response is performed by the user agent after receiving an
    815815   initial response from the origin server. Selection is based on a list
    … …  
    822822</t>
    823823<t>
    824    Agent-driven negotiation is advantageous when the response would vary
     824   Reactive negotiation is advantageous when the response would vary
    825825   over commonly-used dimensions (such as type, language, or encoding),
    826826   when the origin server is unable to determine a user agent's
    … …  
    829829</t>
    830830<t>
    831    Agent-driven negotiation suffers from the disadvantage of needing a
     831   Reactive negotiation suffers from the disadvantage of needing a
    832832   second request to obtain the best alternate representation. This
    833833   second request is only efficient when caching is used. In addition,
    … …  
    839839<t>
    840840   This specification defines the <x:ref>300 (Multiple Choices)</x:ref> and
    841    <x:ref>406 (Not Acceptable)</x:ref> status codes for enabling agent-driven
     841   <x:ref>406 (Not Acceptable)</x:ref> status codes for enabling reactive
    842842   negotiation when the server is unwilling or unable to provide a varying
    843    response using server-driven negotiation.
     843   response using proactive negotiation.
    844844</t>
    845845</section>
    … …  
    17101710  <x:anchor-alias value="qvalue"/>
    17111711<t>
    1712    Many of the request header fields for server-driven content negotiation
     1712   Many of the request header fields for proactive content negotiation
    17131713   use a common parameter, named "q", to assign a relative "weight" to the
    17141714   preference for that associated kind of content.
    … …  
    25932593        <t>
    25942594          Redirection offering a choice of matching resources for use by
    2595           agent-driven content negotiation (&agent-driven-negotiation;). This
     2595          reactive content negotiation (&reactive-negotiation;). This
    25962596          is status code <x:ref>300 (Multiple Choices)</x:ref>.
    25972597        </t>
    … …  
    26522652<t>
    26532653   The target resource has more than one
    2654    representation, each with its own specific location, and agent-driven
     2654   representation, each with its own specific location, and reactive
    26552655   negotiation information (&content-negotiation;) is being provided so that
    26562656   the user (or user agent) can select a preferred representation by

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

    r1845 r1858  
    452452  }
    453453  @bottom-center {
    454        content: "Expires March 5, 2013";
     454       content: "Expires March 7, 2013";
    455455  }
    456456  @bottom-right {
    … …  
    499499      <meta name="dct.creator" content="Reschke, J. F.">
    500500      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    501       <meta name="dct.issued" scheme="ISO8601" content="2012-09-01">
     501      <meta name="dct.issued" scheme="ISO8601" content="2012-09-03">
    502502      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    503503      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: March 5, 2013</td>
     527               <td class="left">Expires: March 7, 2013</td>
    528528               <td class="right">M. Nottingham, Editor</td>
    529529            </tr>
    … …  
    542542            <tr>
    543543               <td class="left"></td>
    544                <td class="right">September 1, 2012</td>
     544               <td class="right">September 3, 2012</td>
    545545            </tr>
    546546         </tbody>
    … …  
    568568         in progress”.
    569569      </p>
    570       <p>This Internet-Draft will expire on March 5, 2013.</p>
     570      <p>This Internet-Draft will expire on March 7, 2013.</p>
    571571      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    572572      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    912912      <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
    913913      </p>
    914       <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 3.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
     914      <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
    915915         and having received a corresponding response.
    916916      </p>
    … …  
    966966      <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3>
    967967      <p id="rfc.section.4.1.2.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness
    968          to be used (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial
     968         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial
    969969            Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved
    970970            Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
    … …  
    999999      <ul class="empty">
    10001000         <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value"
    1001             denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 10.10</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     1001            denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    10021002         </li>
    10031003      </ul>
    … …  
    11811181      </ul>
    11821182      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h1>
    1183       <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 3.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
     1183      <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
    11841184         to keep their contents up-to-date.
    11851185      </p>
    … …  
    14681468         that time.
    14691469      </p>
    1470       <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
     1470      <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
    14711471      </p>
    14721472      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    … …  
    15301530      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.vary" class="smpl">Vary</a> = "*" / 1#<a href="#imported.abnf" class="smpl">field-name</a>
    15311531</pre><p id="rfc.section.7.5.p.5">The set of header fields named by the Vary field value is known as the selecting header fields.</p>
    1532       <p id="rfc.section.7.5.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
     1532      <p id="rfc.section.7.5.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to proactive negotiation. Doing so allows a cache
    15331533         to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
    1534          resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide
     1534         resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to proactive negotiation, since this might provide
    15351535         the user agent with useful information about the dimensions over which the response varies at the time of the response.
    15361536      </p>
    … …  
    19881988  <a href="#imported.abnf" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    19891989</pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p>
    1990       <div id="rfc.figure.u.16"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a>&gt;
     1990      <div id="rfc.figure.u.16"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 9.1</a>&gt;
    19911991</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    19921992      <div id="rfc.figure.u.17"></div> <pre class="inline"><a href="#header.age" class="smpl">Age</a> = delta-seconds
    … …  
    22202220                  </li>
    22212221                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">4.1.3</a>, <a href="#rfc.xref.Part2.5">6</a>, <a href="#rfc.xref.Part2.6">7.3</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.7">B</a><ul>
    2222                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.5">6</a></li>
    2223                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a></li>
    2224                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">7.3</a>, <a href="#rfc.xref.Part2.7">B</a></li>
    2225                         <li><em>Section 10.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.3</a></li>
     2222                        <li><em>Section 5.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4</a>, <a href="#rfc.xref.Part2.5">6</a></li>
     2223                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a></li>
     2224                        <li><em>Section 8.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.3</a></li>
     2225                        <li><em>Section 9.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">7.3</a>, <a href="#rfc.xref.Part2.7">B</a></li>
    22262226                     </ul>
    22272227                  </li>

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

    r1845 r1858  
    17951795<t>
    17961796   A server &SHOULD; include a Vary header field with any cacheable response
    1797    that is subject to server-driven negotiation. Doing so allows a cache to
     1797   that is subject to proactive negotiation. Doing so allows a cache to
    17981798   properly interpret future requests on that resource and informs the user
    17991799   agent about the presence of negotiation on that resource. A server &MAY;
    18001800   include a Vary header field with a non-cacheable response that is subject
    1801    to server-driven negotiation, since this might provide the user agent with
     1801   to proactive negotiation, since this might provide the user agent with
    18021802   useful information about the dimensions over which the response varies at
    18031803   the time of the response.
Note: See TracChangeset for help on using the changeset viewer.