Changeset 779 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 09/03/10 13:11:58 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r778 r779 852 852 path from the origin server, plus the amount of time it has been in transit along network paths. 853 853 </p> 854 <p id="rfc.section.2.3.2.p.2">The term "age_value" denotes the value of the Age header, in a form appropriate for arithmetic operations.</p> 855 <p id="rfc.section.2.3.2.p.3">HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response 856 was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations. 857 </p> 858 <p id="rfc.section.2.3.2.p.4">The term "now" means "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially 859 hosts running origin servers and caches, <em class="bcp14">SHOULD</em> use NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a> or some similar protocol to synchronize their clocks to a globally accurate time standard. 860 </p> 861 <p id="rfc.section.2.3.2.p.5">A response's age can be calculated in two entirely independent ways: </p> 854 <p id="rfc.section.2.3.2.p.2">The following data is used for the age calculation:</p> 855 <p id="rfc.section.2.3.2.p.3"> <dfn>age_value</dfn> 856 </p> 857 <ul class="empty"> 858 <li>The term "age_value" denotes the value of the Age header, in a form appropriate for arithmetic operation; or 0, if not available.</li> 859 </ul> 860 <p id="rfc.section.2.3.2.p.4"> <dfn>date_value</dfn> 861 </p> 862 <ul class="empty"> 863 <li>HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response 864 was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations. See <a href="p1-messaging.html#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for requirements regarding responses without a Date response header.<span class="comment" id="TODO-checkref">[<a href="#TODO-checkref" class="smpl">TODO-checkref</a>: correct reference? --jre]</span> 865 </li> 866 </ul> 867 <p id="rfc.section.2.3.2.p.5"> <dfn>now</dfn> 868 </p> 869 <ul class="empty"> 870 <li>The term "now" means "the current value of the clock at the host performing the calculation". Hosts that use HTTP, but especially 871 hosts running origin servers and caches, <em class="bcp14">SHOULD</em> use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize their clocks to a globally accurate time standard. 872 </li> 873 </ul> 874 <p id="rfc.section.2.3.2.p.6"> <dfn>request_time</dfn> 875 </p> 876 <ul class="empty"> 877 <li>The current value of the clock at the host at the time the request resulting in the stored response was made.</li> 878 </ul> 879 <p id="rfc.section.2.3.2.p.7"> <dfn>response_time</dfn> 880 </p> 881 <ul class="empty"> 882 <li>The current value of the clock at the host at the time the response was received.</li> 883 </ul> 884 <p id="rfc.section.2.3.2.p.8">A response's age can be calculated in two entirely independent ways: </p> 862 885 <ol> 863 886 <li>now minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative, … … 868 891 <div id="rfc.figure.u.4"></div> 869 892 <p>These are combined as</p> <pre class="text"> corrected_received_age = max(now - date_value, age_value) 870 </pre><p id="rfc.section.2.3.2.p. 7">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.893 </pre><p id="rfc.section.2.3.2.p.10">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received. 871 894 </p> 872 895 <div id="rfc.figure.u.5"></div><pre class="text"> corrected_initial_age = corrected_received_age 873 896 + (now - request_time) 874 </pre><p id="rfc.section.2.3.2.p. 9">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>875 <p id="rfc.section.2.3.2.p.1 0">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response897 </pre><p id="rfc.section.2.3.2.p.12">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p> 898 <p id="rfc.section.2.3.2.p.13">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response 876 899 was last validated by the origin server to the corrected_initial_age. 877 900 </p> 878 <p id="rfc.section.2.3.2.p.11">In summary:</p>879 <p id="rfc.section.2.3.2.p.12">age_value </p>880 <ul class="empty">881 <li>Age header field-value received with the response.</li>882 </ul>883 <p id="rfc.section.2.3.2.p.13">date_value </p>884 <ul class="empty">885 <li>Date header field-value received with the response.</li>886 </ul>887 <p id="rfc.section.2.3.2.p.14">request_time </p>888 <ul class="empty">889 <li>Local time when the cache made the request resulting in the stored response.</li>890 </ul>891 <p id="rfc.section.2.3.2.p.15">response_time </p>892 <ul class="empty">893 <li>Local time when the cache received the response.</li>894 </ul>895 <p id="rfc.section.2.3.2.p.16">now </p>896 <ul class="empty">897 <li>Current local time.</li>898 </ul>899 901 <div id="rfc.figure.u.6"></div> 900 902 <p>With these definitions, the current_age can be calculated as per:</p> <pre class="text"> apparent_age = max(0, response_time - date_value); … … 972 974 <ul> 973 975 <li>adding or removing whitespace, where allowed in the header's syntax</li> 974 <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)976 <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 975 977 </li> 976 978 <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification … … 1247 1249 that time. 1248 1250 </p> 1249 <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.1251 <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1250 1252 </p> 1251 1253 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.expires" class="smpl">Expires</a> = "Expires" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expires" class="smpl">Expires-v</a> … … 1913 1915 </li> 1914 1916 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 1915 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2. 6</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a><ul class="ind">1917 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.6</a>, <a class="iref" href="#rfc.xref.Part1.14">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a><ul class="ind"> 1916 1918 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a></li> 1917 1919 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a></li> 1918 1920 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a></li> 1919 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.1 2">2.6</a></li>1920 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.1 3">3.3</a></li>1921 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.6</a></li> 1922 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.14">3.3</a></li> 1921 1923 <li class="indline1"><em>Section 9.3</em> <a class="iref" href="#rfc.xref.Part1.11">2.3.2</a></li> 1924 <li class="indline1"><em>Section 9.3.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.3.2</a></li> 1922 1925 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a></li> 1923 1926 </ul>
Note: See TracChangeset
for help on using the changeset viewer.