Changeset 2082 for draft-ietf-httpbis
- Timestamp:
- 04/01/13 10:29:06 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 5 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/httpbis.abnf
r1966 r2082 27 27 GMT = %x47.4D.54 ; GMT 28 28 29 HTTP-date = rfc1123-date / obs-date29 HTTP-date = IMF-fixdate / obs-date 30 30 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ] 31 31 HTTP-name = %x48.54.54.50 ; HTTP … … 33 33 HTTP-version = HTTP-name "/" DIGIT "." DIGIT 34 34 Host = uri-host [ ":" port ] 35 IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT 35 36 If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS entity-tag ] ) ) 36 37 If-Modified-Since = HTTP-date … … 201 202 request-line = method SP request-target SP HTTP-version CRLF 202 203 request-target = origin-form / absolute-form / authority-form / asterisk-form 203 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT204 204 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 205 205 second = 2DIGIT -
draft-ietf-httpbis/latest/p2-semantics.html
r2080 r2082 449 449 } 450 450 @bottom-center { 451 content: "Expires July 6, 2013";451 content: "Expires July 8, 2013"; 452 452 } 453 453 @bottom-right { … … 495 495 <meta name="dct.creator" content="Reschke, J. F."> 496 496 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 497 <meta name="dct.issued" scheme="ISO8601" content="2013-01-0 2">497 <meta name="dct.issued" scheme="ISO8601" content="2013-01-04"> 498 498 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 499 499 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 523 523 <tr> 524 524 <td class="left">Intended status: Standards Track</td> 525 <td class="right">January 2, 2013</td>525 <td class="right">January 4, 2013</td> 526 526 </tr> 527 527 <tr> 528 <td class="left">Expires: July 6, 2013</td>528 <td class="left">Expires: July 8, 2013</td> 529 529 <td class="right"></td> 530 530 </tr> … … 554 554 in progress”. 555 555 </p> 556 <p>This Internet-Draft will expire on July 6, 2013.</p>556 <p>This Internet-Draft will expire on July 8, 2013.</p> 557 557 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 558 558 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2804 2804 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="origination.date" href="#origination.date">Origination Date</a></h3> 2805 2805 <h4 id="rfc.section.7.1.1.1"><a href="#rfc.section.7.1.1.1">7.1.1.1</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h4> 2806 <p id="rfc.section.7.1.1.1.p.1">HTTP has historically allowed three different formats for date/time stamps. However, the preferred format is a fixed-length 2807 subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: 2808 </p> 2809 <div id="rfc.figure.u.42"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 2810 </pre><p id="rfc.section.7.1.1.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p> 2811 <div id="rfc.figure.u.43"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 2812 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 2813 </pre><p id="rfc.section.7.1.1.1.p.5">HTTP always represents dates as an instance of Coordinated Universal Time (UTC), without exception; the first two formats 2814 indicate UTC as "GMT" in the three-letter abbreviation for time zone. Recipients <em class="bcp14">MAY</em> assume UTC even if the time zone abbreviation is missing, invalid, or might indicate some other time zone. 2815 </p> 2816 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.39"></span> <a href="#http.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 2817 </pre><div id="preferred.date.format"> 2806 <p id="rfc.section.7.1.1.1.p.1">Prior to 1995, there were three different formats commonly used by servers to communicate timestamps. For compatibility with 2807 old implementations, all three are defined here. The preferred format is a fixed-length and single-zone subset of the date 2808 and time specification used by the Internet Message Format <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. 2809 </p> 2810 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.39"></span> <a href="#http.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">IMF-fixdate</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 2811 </pre><div id="rfc.figure.u.43"></div> 2812 <p>An example of the preferred format is</p><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate 2813 </pre><div id="rfc.figure.u.44"></div> 2814 <p>Examples of the two obsolete formats are</p><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 2815 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 2816 </pre><p id="rfc.section.7.1.1.1.p.5">A recipient that parses a timestamp value in an HTTP header field <em class="bcp14">MUST</em> accept all three formats. A sender <em class="bcp14">MUST</em> generate the IMF-fixdate format when sending an HTTP-date value in a header field. 2817 </p> 2818 <p id="rfc.section.7.1.1.1.p.6">An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC). The first two formats indicate UTC 2819 by the three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; values in the asctime format 2820 are assumed to be in UTC. A sender that generates HTTP-date values from a local clock ought to 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 its clock to UTC. 2821 </p> 2822 <div id="preferred.date.format"> 2818 2823 <p id="rfc.section.7.1.1.1.p.7"> Preferred format:</p> 2819 2824 </div> 2820 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span> <a href="#preferred.date.format" class="smpl"> rfc1123-date</a>= <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#imported.abnf" class="smpl">SP</a> date1 <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>2821 ; fixed length subset of the format defined in2822 ; <a href="http://tools.ietf.org/html/rfc 1123#section-5.2.14">Section 5.2.14</a> of <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>2825 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span> <a href="#preferred.date.format" class="smpl">IMF-fixdate</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#imported.abnf" class="smpl">SP</a> date1 <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 2826 ; fixed length/zone subset of the format defined in 2827 ; <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a> 2823 2828 2824 2829 <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; "Mon", case-sensitive … … 2848 2853 <a href="#preferred.date.format" class="smpl">year</a> = 4<a href="#imported.abnf" class="smpl">DIGIT</a> 2849 2854 2850 <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; "GMT", case-sensitive2855 <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; "GMT", case-sensitive 2851 2856 2852 2857 <a href="#preferred.date.format" class="smpl">time-of-day</a> = <a href="#preferred.date.format" class="smpl">hour</a> ":" <a href="#preferred.date.format" class="smpl">minute</a> ":" <a href="#preferred.date.format" class="smpl">second</a> 2853 ; 00:00:00 - 23:59:592858 ; 00:00:00 - 23:59:60 (leap second) 2854 2859 2855 2860 <a href="#preferred.date.format" class="smpl">hour</a> = 2<a href="#imported.abnf" class="smpl">DIGIT</a> 2856 2861 <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#imported.abnf" class="smpl">DIGIT</a> 2857 2862 <a href="#preferred.date.format" class="smpl">second</a> = 2<a href="#imported.abnf" class="smpl">DIGIT</a> 2858 </pre><p id="rfc.section.7.1.1.1.p.9">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>). 2859 </p> 2860 <div id="obsolete.date.formats"> 2861 <p id="rfc.section.7.1.1.1.p.10"> Obsolete formats:</p> 2863 </pre><div id="obsolete.date.formats"> 2864 <p id="rfc.section.7.1.1.1.p.9"> Obsolete formats:</p> 2862 2865 </div> 2863 2866 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 2864 2867 </pre><div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#imported.abnf" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 2865 2868 <a href="#obsolete.date.formats" class="smpl">date2</a> = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#imported.abnf" class="smpl">DIGIT</a> 2866 ; day-month-year (e.g., 02-Jun-82)2867 2868 <a href="#obsolete.date.formats" class="smpl">day-name-l</a> = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive2869 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive2869 ; e.g., 02-Jun-82 2870 2871 <a href="#obsolete.date.formats" class="smpl">day-name-l</a> = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 2872 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 2870 2873 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 2871 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive2872 / %x46.72.69.64.61.79 ; "Friday", case-sensitive2873 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive2874 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive2874 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 2875 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 2876 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 2877 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 2875 2878 </pre><div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 2876 2879 <a href="#obsolete.date.formats" class="smpl">date3</a> = <a href="#preferred.date.format" class="smpl">month</a> <a href="#imported.abnf" class="smpl">SP</a> ( 2<a href="#imported.abnf" class="smpl">DIGIT</a> / ( <a href="#imported.abnf" class="smpl">SP</a> 1<a href="#imported.abnf" class="smpl">DIGIT</a> )) 2877 ; month day (e.g., Jun 2) 2878 </pre><p id="rfc.section.7.1.1.1.p.14">HTTP-date is case sensitive. A sender <em class="bcp14">MUST NOT</em> generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar. 2879 </p> 2880 <p id="rfc.section.7.1.1.1.p.15">Recipients that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0). A sender <em class="bcp14">MUST</em> only generate the RFC 1123 format when sending HTTP-date values in header fields. 2880 ; e.g., Jun 2 2881 </pre><p id="rfc.section.7.1.1.1.p.13">HTTP-date is case sensitive. A sender <em class="bcp14">MUST NOT</em> generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar. The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the Internet Message Format constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>). 2882 </p> 2883 <p id="rfc.section.7.1.1.1.p.14">Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, <em class="bcp14">SHOULD</em> interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past 2884 that had the same last two digits. 2885 </p> 2886 <p id="rfc.section.7.1.1.1.p.15">Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by the field 2887 definition. For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the 2888 date and time specifications defined by the Internet Message Format. 2881 2889 </p> 2882 2890 <div class="note" id="rfc.section.7.1.1.1.p.16"> 2883 <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications, 2884 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 2885 </p> 2886 </div> 2887 <div class="note" id="rfc.section.7.1.1.1.p.17"> 2888 <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers 2889 are not required to use these formats for user presentation, request logging, etc. 2891 <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Implementations are 2892 not required to use these formats for user presentation, request logging, etc. 2890 2893 </p> 2891 2894 </div> … … 2893 2896 <h4 id="rfc.section.7.1.1.2"><a href="#rfc.section.7.1.1.2">7.1.1.2</a> <a id="header.date" href="#header.date">Date</a></h4> 2894 2897 <p id="rfc.section.7.1.1.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the 2895 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322. 4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section 7.1.1.1</a>, though a sender <em class="bcp14">MUST</em> generate a Date value in the rfc1123-date format.2898 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.6"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section 7.1.1.1</a>. 2896 2899 </p> 2897 2900 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a> … … 2902 2905 message origination. 2903 2906 </p> 2904 <p id="rfc.section.7.1.1.2.p.6">An origin server <em class="bcp14">MUST NOT</em> send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current time.2905 An origin server <em class="bcp14">MAY</em> send a Date header field if the response is in the <a href="#status.1xx" class="smpl">1xx (Informational)</a> or <a href="#status.5xx" class="smpl">5xx (Server Error)</a> class of status codes. An origin server <em class="bcp14">MUST</em> send a Date header field in all other cases.2907 <p id="rfc.section.7.1.1.2.p.6">An origin server <em class="bcp14">MUST NOT</em> send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instance 2908 in Coordinated Universal Time. An origin server <em class="bcp14">MAY</em> send a Date header field if the response is in the <a href="#status.1xx" class="smpl">1xx (Informational)</a> or <a href="#status.5xx" class="smpl">5xx (Server Error)</a> class of status codes. An origin server <em class="bcp14">MUST</em> send a Date header field in all other cases. 2906 2909 </p> 2907 2910 <p id="rfc.section.7.1.1.2.p.7">A recipient with a clock that receives a response message without a Date header field <em class="bcp14">MUST</em> record the time it was received and append a corresponding Date header field to the message's header block if it is cached … … 3951 3954 </tr> 3952 3955 <tr> 3953 <td class="reference"><b id="RFC1 123">[RFC1123]</b></td>3954 <td class="top"><a href="mailto: Braden@ISI.EDU" title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD 3, RFC 1123, October 1989.3956 <td class="reference"><b id="RFC1305">[RFC1305]</b></td> 3957 <td class="top"><a href="mailto:mills@udel.edu" title="University of Delaware, Electrical Engineering Department">Mills, D.</a>, “<a href="http://tools.ietf.org/html/rfc1305">Network Time Protocol (Version 3) Specification, Implementation</a>”, RFC 1305, March 1992. 3955 3958 </td> 3956 3959 </tr> … … 4056 4059 </div> 4057 4060 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1> 4058 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322. 5"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message body to be transmitted in an open variety of representations and with extensible mechanisms. However,4061 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.7"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message body to be transmitted in an open variety of representations and with extensible mechanisms. However, 4059 4062 RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were 4060 4063 carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, … … 4252 4255 <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; GMT 4253 4256 4254 <a href="#http.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date 4257 <a href="#http.date" class="smpl">HTTP-date</a> = IMF-fixdate / obs-date 4258 4259 <a href="#preferred.date.format" class="smpl">IMF-fixdate</a> = day-name "," SP date1 SP time-of-day SP GMT 4255 4260 4256 4261 <a href="#header.location" class="smpl">Location</a> = URI-reference … … 4346 4351 <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 4347 4352 4348 <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT4349 4353 <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT 4350 4354 … … 4519 4523 <li><tt>hour</tt> <a href="#rfc.iref.g.43"><b>7.1.1.1</b></a></li> 4520 4524 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.39"><b>7.1.1.1</b></a></li> 4525 <li><tt>IMF-fixdate</tt> <a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li> 4521 4526 <li><tt>language-range</tt> <a href="#rfc.iref.g.33"><b>5.3.5</b></a></li> 4522 4527 <li><tt>language-tag</tt> <a href="#rfc.iref.g.12"><b>3.1.3.1</b></a></li> … … 4536 4541 <li><tt>Referer</tt> <a href="#rfc.iref.g.35"><b>5.5.2</b></a></li> 4537 4542 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.57"><b>7.1.3</b></a></li> 4538 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li>4539 4543 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.53"><b>7.1.1.1</b></a></li> 4540 4544 <li><tt>second</tt> <a href="#rfc.iref.g.45"><b>7.1.1.1</b></a></li> … … 4658 4662 <li><em>REST</em> <a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>11.2</b></a></li> 4659 4663 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">6.6.4</a>, <a href="#rfc.xref.header.retry-after.2">7.1</a>, <a href="#rfc.iref.r.3"><b>7.1.3</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3.2</a></li> 4660 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">7.1.1.1</a>, <a href="#rfc.xref.RFC1123.2">7.1.1.1</a>, <a href="#RFC1123"><b>11.2</b></a><ul> 4661 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">7.1.1.1</a></li> 4662 </ul> 4663 </li> 4664 <li><em>RFC1305</em> <a href="#rfc.xref.RFC1305.1">7.1.1.1</a>, <a href="#RFC1305"><b>11.2</b></a></li> 4664 4665 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">6.4</a>, <a href="#RFC1945"><b>11.2</b></a>, <a href="#rfc.xref.RFC1945.2">B</a><ul> 4665 4666 <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1">6.4</a></li> … … 4722 4723 </ul> 4723 4724 </li> 4724 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.4">7.1.1. 2</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.5">A</a><ul>4725 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322. 3">7.1.1.1</a></li>4725 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.6">7.1.1.2</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.7">A</a><ul> 4726 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a></li> 4726 4727 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a></li> 4727 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322. 4">7.1.1.2</a></li>4728 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.6">7.1.1.2</a></li> 4728 4729 </ul> 4729 4730 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2080 r2082 3516 3516 <x:anchor-alias value="HTTP-date"/> 3517 3517 <t> 3518 HTTP has historically allowed three different formats 3519 for date/time stamps. However, the preferred format is a fixed-length subset 3520 of that defined by <xref target="RFC1123"/>: 3521 </t> 3522 <figure><artwork type="example" x:indent-with=" "> 3523 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 3518 Prior to 1995, there were three different formats commonly used by servers 3519 to communicate timestamps. For compatibility with old implementations, all 3520 three are defined here. The preferred format is a fixed-length and 3521 single-zone subset of the date and time specification used by the 3522 Internet Message Format <xref target="RFC5322"/>. 3523 </t> 3524 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/> 3525 <x:ref>HTTP-date</x:ref> = <x:ref>IMF-fixdate</x:ref> / <x:ref>obs-date</x:ref> 3524 3526 </artwork></figure> 3525 <t> 3526 The other formats are described here only for compatibility with obsolete 3527 implementations. 3528 </t> 3529 <figure><artwork type="example" x:indent-with=" "> 3530 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 3531 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 3527 <figure><preamble>An example of the preferred format is</preamble><artwork type="example" x:indent-with=" "> 3528 Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate 3532 3529 </artwork></figure> 3533 <t> 3534 HTTP always represents dates as an instance of Coordinated Universal Time 3535 (UTC), without exception; the first two formats indicate UTC as "GMT" in 3536 the three-letter abbreviation for time zone. Recipients &MAY; assume UTC 3537 even if the time zone abbreviation is missing, invalid, or might indicate 3538 some other time zone. 3539 </t> 3540 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/> 3541 <x:ref>HTTP-date</x:ref> = <x:ref>rfc1123-date</x:ref> / <x:ref>obs-date</x:ref> 3530 <figure><preamble>Examples of the two obsolete formats are</preamble><artwork type="example" x:indent-with=" "> 3531 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 3532 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 3542 3533 </artwork></figure> 3534 <t> 3535 A recipient that parses a timestamp value in an HTTP header field &MUST; 3536 accept all three formats. A sender &MUST; generate the IMF-fixdate 3537 format when sending an HTTP-date value in a header field. 3538 </t> 3539 <t> 3540 An HTTP-date value represents time as an instance of Coordinated Universal 3541 Time (UTC). The first two formats indicate UTC by the three-letter 3542 abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; 3543 values in the asctime format are assumed to be in UTC. 3544 A sender that generates HTTP-date values from a local clock ought to use 3545 NTP (<xref target="RFC1305"/>) or some similar protocol to synchronize its 3546 clock to UTC. 3547 </t> 3543 3548 <t anchor="preferred.date.format"> 3544 <x:anchor-alias value=" rfc1123-date"/>3549 <x:anchor-alias value="IMF-fixdate"/> 3545 3550 <x:anchor-alias value="time-of-day"/> 3546 3551 <x:anchor-alias value="hour"/> … … 3554 3559 Preferred format: 3555 3560 </t> 3556 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem=" rfc1123-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/>3557 <x:ref> rfc1123-date</x:ref>= <x:ref>day-name</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>3558 ; fixed length subset of the format defined in3559 ; <xref target="RFC 1123" x:fmt="of" x:sec="5.2.14"/>3561 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="IMF-fixdate"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/> 3562 <x:ref>IMF-fixdate</x:ref> = <x:ref>day-name</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref> 3563 ; fixed length/zone subset of the format defined in 3564 ; <xref target="RFC5322" x:fmt="of" x:sec="3.3"/> 3560 3565 3561 3566 <x:ref>day-name</x:ref> = <x:abnf-char-sequence>"Mon"</x:abnf-char-sequence> ; "Mon", case-sensitive … … 3585 3590 <x:ref>year</x:ref> = 4<x:ref>DIGIT</x:ref> 3586 3591 3587 <x:ref>GMT</x:ref> = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive3592 <x:ref>GMT</x:ref> = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive 3588 3593 3589 3594 <x:ref>time-of-day</x:ref> = <x:ref>hour</x:ref> ":" <x:ref>minute</x:ref> ":" <x:ref>second</x:ref> 3590 ; 00:00:00 - 23:59:593595 ; 00:00:00 - 23:59:60 (leap second) 3591 3596 3592 3597 <x:ref>hour</x:ref> = 2<x:ref>DIGIT</x:ref> … … 3594 3599 <x:ref>second</x:ref> = 2<x:ref>DIGIT</x:ref> 3595 3600 </artwork></figure> 3596 <t>3597 The semantics of <x:ref>day-name</x:ref>, <x:ref>day</x:ref>,3598 <x:ref>month</x:ref>, <x:ref>year</x:ref>, and <x:ref>time-of-day</x:ref> are the3599 same as those defined for the RFC 5322 constructs3600 with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>).3601 </t>3602 3601 <t anchor="obsolete.date.formats"> 3603 3602 <x:anchor-alias value="obs-date"/> … … 3616 3615 <x:ref>rfc850-date</x:ref> = <x:ref>day-name-l</x:ref> "," <x:ref>SP</x:ref> <x:ref>date2</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref> 3617 3616 <x:ref>date2</x:ref> = <x:ref>day</x:ref> "-" <x:ref>month</x:ref> "-" 2<x:ref>DIGIT</x:ref> 3618 ; day-month-year (e.g., 02-Jun-82)3619 3620 <x:ref>day-name-l</x:ref> = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence> ; "Monday", case-sensitive3621 / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive3617 ; e.g., 02-Jun-82 3618 3619 <x:ref>day-name-l</x:ref> = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence> ; "Monday", case-sensitive 3620 / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive 3622 3621 / <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive 3623 / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive3624 / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive3625 / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive3626 / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive3622 / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive 3623 / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive 3624 / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive 3625 / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive 3627 3626 </artwork></figure> 3628 3627 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="asctime-date"/> 3629 3628 <x:ref>asctime-date</x:ref> = <x:ref>day-name</x:ref> <x:ref>SP</x:ref> <x:ref>date3</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref> 3630 3629 <x:ref>date3</x:ref> = <x:ref>month</x:ref> <x:ref>SP</x:ref> ( 2<x:ref>DIGIT</x:ref> / ( <x:ref>SP</x:ref> 1<x:ref>DIGIT</x:ref> )) 3631 ; month day (e.g., Jun 2)3630 ; e.g., Jun 2 3632 3631 </artwork></figure> 3633 3632 <t> … … 3635 3634 A sender &MUST-NOT; generate additional whitespace in an HTTP-date beyond 3636 3635 that specifically included as SP in the grammar. 3637 </t> 3638 <t> 3639 Recipients that parse a date value &MUST; accept all three formats (for 3640 compatibility with HTTP/1.0). A sender &MUST; only generate the RFC 1123 3641 format when sending HTTP-date values in header fields. 3642 </t> 3643 <x:note> 3644 <t> 3645 &Note; Recipients of date values are encouraged to be robust in 3646 accepting date values that might have been sent by non-HTTP 3647 applications, as is sometimes the case when retrieving or posting 3648 messages via proxies/gateways to SMTP or NNTP. 3649 </t> 3650 </x:note> 3636 The semantics of <x:ref>day-name</x:ref>, <x:ref>day</x:ref>, 3637 <x:ref>month</x:ref>, <x:ref>year</x:ref>, and <x:ref>time-of-day</x:ref> 3638 are the same as those defined for the Internet Message Format constructs 3639 with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>). 3640 </t> 3641 <t> 3642 Recipients of a timestamp value in rfc850-date format, which uses a 3643 two-digit year, &SHOULD; interpret a timestamp that appears to be more 3644 than 50 years in the future as representing the most recent year in the 3645 past that had the same last two digits. 3646 </t> 3647 <t> 3648 Recipients of timestamp values are encouraged to be robust in parsing 3649 timestamps unless otherwise restricted by the field definition. 3650 For example, messages are occasionally forwarded over HTTP from a non-HTTP 3651 source that might generate any of the date and time specifications defined 3652 by the Internet Message Format. 3653 </t> 3651 3654 <x:note> 3652 3655 <t> 3653 3656 &Note; HTTP requirements for the date/time stamp format apply only 3654 to their usage within the protocol stream. Clients and servers are3657 to their usage within the protocol stream. Implementations are 3655 3658 not required to use these formats for user presentation, request 3656 3659 logging, etc. … … 3666 3669 the message was originated, having the same semantics as the Origination 3667 3670 Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>. 3668 The field value is an HTTP-date, as defined in <xref target="http.date"/>, 3669 though a sender &MUST; generate a Date value in the rfc1123-date format. 3671 The field value is an HTTP-date, as defined in <xref target="http.date"/>. 3670 3672 </t> 3671 3673 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/> … … 3687 3689 <t> 3688 3690 An origin server &MUST-NOT; send a Date header field if it does not have a 3689 clock capable of providing a reasonable approximation of the current time. 3691 clock capable of providing a reasonable approximation of the current 3692 instance in Coordinated Universal Time. 3690 3693 An origin server &MAY; send a Date header field if the response is in the 3691 3694 <x:ref>1xx (Informational)</x:ref> or <x:ref>5xx (Server Error)</x:ref> … … 5198 5201 </reference> 5199 5202 5200 <reference anchor="RFC1123"> 5201 <front> 5202 <title>Requirements for Internet Hosts - Application and Support</title> 5203 <author initials="R." surname="Braden" fullname="Robert Braden"> 5204 <organization>University of Southern California (USC), Information Sciences Institute</organization> 5205 <address><email>Braden@ISI.EDU</email></address> 5206 </author> 5207 <date month="October" year="1989"/> 5208 </front> 5209 <seriesInfo name="STD" value="3"/> 5210 <seriesInfo name="RFC" value="1123"/> 5203 <reference anchor="RFC1305"> 5204 <front> 5205 <title>Network Time Protocol (Version 3) Specification, Implementation</title> 5206 <author fullname="David L. Mills" initials="D." surname="Mills"> 5207 <organization>University of Delaware, Electrical Engineering Department</organization> 5208 <address><email>mills@udel.edu</email></address> 5209 </author> 5210 <date month="March" year="1992" /> 5211 </front> 5212 <seriesInfo name="RFC" value="1305" /> 5211 5213 </reference> 5212 5214 … … 5993 5995 <x:ref>GMT</x:ref> = %x47.4D.54 ; GMT 5994 5996 5995 <x:ref>HTTP-date</x:ref> = rfc1123-date / obs-date 5997 <x:ref>HTTP-date</x:ref> = IMF-fixdate / obs-date 5998 5999 <x:ref>IMF-fixdate</x:ref> = day-name "," SP date1 SP time-of-day SP GMT 5996 6000 5997 6001 <x:ref>Location</x:ref> = URI-reference … … 6087 6091 <x:ref>qvalue</x:ref> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 6088 6092 6089 <x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT6090 6093 <x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT 6091 6094 -
draft-ietf-httpbis/latest/p6-cache.html
r2080 r2082 452 452 } 453 453 @bottom-center { 454 content: "Expires July 6, 2013";454 content: "Expires July 8, 2013"; 455 455 } 456 456 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2013-01-0 2">500 <meta name="dct.issued" scheme="ISO8601" content="2013-01-04"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <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."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: July 6, 2013</td>526 <td class="left">Expires: July 8, 2013</td> 527 527 <td class="right">J. Reschke, Editor</td> 528 528 </tr> … … 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">January 2, 2013</td>535 <td class="right">January 4, 2013</td> 536 536 </tr> 537 537 </tbody> … … 559 559 in progress”. 560 560 </p> 561 <p>This Internet-Draft will expire on July 6, 2013.</p>561 <p>This Internet-Draft will expire on July 8, 2013.</p> 562 562 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 563 563 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 894 894 which response to use. 895 895 </p> 896 <p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard.896 <p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use. 897 897 </p> 898 898 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="expiration.model" href="#expiration.model">Freshness Model</a></h2> … … 957 957 </div> 958 958 <h3 id="rfc.section.4.1.3"><a href="#rfc.section.4.1.3">4.1.3</a> <a id="age.calculations" href="#age.calculations">Calculating Age</a></h3> 959 <p id="rfc.section.4.1.3.p.1"> HTTP/1.1 uses the <a href="#header.age" class="smpl">Age</a> header field to convey the estimated age of the response message when obtained from a cache. The Age field value is the cache's960 estimate of the amount of time since the response was generated or validated by the origin server. In essence, the Age value961 is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus962 the amount of time it has been in transit along network paths.959 <p id="rfc.section.4.1.3.p.1">The <a href="#header.age" class="smpl">Age</a> header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is 960 the cache's estimate of the number of seconds since the response was generated or validated by the origin server. In essence, 961 the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin 962 server, plus the amount of time it has been in transit along network paths. 963 963 </p> 964 964 <p id="rfc.section.4.1.3.p.2">The following data is used for the age calculation:</p> … … 972 972 </p> 973 973 <ul class="empty"> 974 <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" 975 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 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 974 <li>The term "date_value" 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 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 976 975 </li> 977 976 </ul> … … 979 978 </p> 980 979 <ul class="empty"> 981 <li>The term "now" means "the current value of the clock at the host performing the calculation". A cache <em class="bcp14">SHOULD</em> use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.2"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize its clocks to a globally accurate time standard.980 <li>The term "now" means "the current value of the clock at the host performing the calculation". A host ought to 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 its clocks to Coordinated Universal Time. 982 981 </li> 983 982 </ul> … … 1017 1016 <p id="rfc.section.4.1.3.p.15"> </p> 1018 1017 <ul> 1019 <li>Recipients <em class="bcp14">SHOULD</em> assume that an RFC-850 date appearing to be more than 50 years in the future is in fact in the past (this helps solve the 1020 "year 2000" problem). 1021 </li> 1022 <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively. 1023 </li> 1024 <li>An implementation <em class="bcp14">MAY</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value. 1025 </li> 1026 <li>Recipients <em class="bcp14">MUST</em> perform all expiration-related calculations in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time. 1027 </li> 1028 <li>Caches <em class="bcp14">SHOULD</em> consider dates with time zones other than "GMT" invalid. 1018 <li>Although all date formats are specified to be case-sensitive, cache recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively. 1019 </li> 1020 <li>If a cache recipient's internal implementation of time has less resolution than the value of an HTTP-date, the recipient <em class="bcp14">MUST</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as the nearest time equal to or earlier than the received value. 1021 </li> 1022 <li>Cache recipients <em class="bcp14">MUST NOT</em> allow local time zones to influence the calculation or comparison of an age or expiration time. 1023 </li> 1024 <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration. 1029 1025 </li> 1030 1026 </ul> … … 1423 1419 that time. 1424 1420 </p> 1425 <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 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.1421 <p id="rfc.section.7.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. 1426 1422 </p> 1427 1423 <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> 1428 1424 </pre><div id="rfc.figure.u.10"></div> 1429 1425 <p>For example</p> <pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 1430 </pre><p id="rfc.section.7.3.p.6">A cache <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). 1431 </p> 1432 <div class="note" id="rfc.section.7.3.p.7"> 1433 <p> <b>Note:</b> If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (see <a href="#cache-response-directive.max-age" title="max-age">Section 7.2.2.7</a>), that directive overrides the Expires field. Likewise, the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section 7.2.2.8</a>) overrides the <a href="#header.expires" class="smpl">Expires</a> header field in shared caches. 1434 </p> 1435 </div> 1436 <p id="rfc.section.7.3.p.8">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes 1426 </pre><p id="rfc.section.7.3.p.6">A cache recipient <em class="bcp14">MUST</em> interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired"). 1427 </p> 1428 <p id="rfc.section.7.3.p.7">If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (<a href="#cache-response-directive.max-age" title="max-age">Section 7.2.2.7</a>), a recipient <em class="bcp14">MUST</em> ignore the Expires field. Likewise, if a response includes the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section 7.2.2.8</a>), a shared cache recipient <em class="bcp14">MUST</em> ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented 1429 the Cache-Control field. 1430 </p> 1431 <p id="rfc.section.7.3.p.8">An origin server without a clock <em class="bcp14">MUST NOT</em> generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated 1432 with the resource by a system or user with a reliable clock. 1433 </p> 1434 <p id="rfc.section.7.3.p.9">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes 1437 1435 are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use 1438 1436 of 32-bit integers for time values), and many caches will evict a response far sooner than that. 1439 </p>1440 <p id="rfc.section.7.3.p.9">An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires values to a response unless these values were associated with the resource by a system or user with a reliable1441 clock. It <em class="bcp14">MAY</em> assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration"1442 of responses without storing separate Expires values for each resource).1443 1437 </p> 1444 1438 <div id="rfc.iref.p.5"></div> … … 2175 2169 </li> 2176 2170 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 2177 <li><em>RFC1305</em> <a href="#rfc.xref.RFC1305.1">4 </a>, <a href="#rfc.xref.RFC1305.2">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>2171 <li><em>RFC1305</em> <a href="#rfc.xref.RFC1305.1">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li> 2178 2172 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.3</a>, <a href="#RFC2119"><b>12.1</b></a></li> 2179 2173 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">4.1.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r2080 r2082 527 527 <t> 528 528 A cache that does not have a clock available &MUST-NOT; use stored 529 responses without revalidating them on every use. A cache, especially a 530 shared cache, &SHOULD; use a mechanism, such as NTP <xref 531 target="RFC1305"/>, to synchronize its clock with a reliable external 532 standard. 529 responses without revalidating them on every use. 533 530 </t> 534 531 … … 659 656 <section anchor="age.calculations" title="Calculating Age"> 660 657 <t> 661 HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey theestimated658 The <x:ref>Age</x:ref> header field is used to convey an estimated 662 659 age of the response message when obtained from a cache. The Age field value 663 is the cache's estimate of the amount of timesince the response was660 is the cache's estimate of the number of seconds since the response was 664 661 generated or validated by the origin server. In essence, the Age value is 665 662 the sum of the time that the response has been resident in each of the … … 684 681 <list> 685 682 <t> 686 HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header 687 field, if possible, with every response, giving the time at which the 688 response was generated. The term "date_value" denotes the value of 683 The term "date_value" denotes the value of 689 684 the Date header field, in a form appropriate for arithmetic 690 685 operations. See &header-date; for the definition of the Date header … … 698 693 <t> 699 694 The term "now" means "the current value of the clock at the host 700 performing the calculation". A cache &SHOULD;use NTP (<xref695 performing the calculation". A host ought to use NTP (<xref 701 696 target="RFC1305"/>) or some similar protocol to synchronize its 702 clocks to a globally accurate time standard.697 clocks to Coordinated Universal Time. 703 698 </t> 704 699 </list> … … 766 761 <t> 767 762 <list style="symbols"> 768 <t>Recipients &SHOULD; assume that an RFC-850 date769 appearing to be more than 50 years in the future is in fact770 in the past (this helps solve the "year 2000" problem).</t>771 772 763 <t>Although all date formats are specified to be case-sensitive, 773 recipients &SHOULD; match day, week and timezone names764 cache recipients &SHOULD; match day, week and timezone names 774 765 case-insensitively.</t> 775 766 776 <t>An implementation &MAY; internally represent a parsed 777 <x:ref>Expires</x:ref> date as earlier than the proper value, but 778 &MUST-NOT; internally represent a parsed Expires date as later than the 779 proper value.</t> 780 781 <t>Recipients &MUST; perform all expiration-related calculations in GMT. 782 The local time zone &MUST-NOT; influence the calculation or comparison 783 of an age or expiration time.</t> 784 785 <t>Caches &SHOULD; consider dates with time zones other than "GMT" 786 invalid.</t> 767 <t>If a cache recipient's internal implementation of time has less 768 resolution than the value of an HTTP-date, the recipient &MUST; 769 internally represent a parsed <x:ref>Expires</x:ref> date as the 770 nearest time equal to or earlier than the received value.</t> 771 772 <t>Cache recipients &MUST-NOT; allow local time zones to influence the 773 calculation or comparison of an age or expiration time.</t> 774 775 <t>Cache recipients &SHOULD; consider a date with a zone abbreviation 776 other than "GMT" to be invalid for calculating expiration.</t> 787 777 </list> 788 778 </t> … … 1592 1582 </t> 1593 1583 <t> 1594 The field-value is an absolute date and time as defined by HTTP-date in 1595 &http-date;; a sender &MUST; use the rfc1123-date format. 1584 The Expires value is an HTTP-date timestamp, as defined in &http-date;. 1596 1585 </t> 1597 1586 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/> … … 1604 1593 </artwork></figure> 1605 1594 <t> 1606 A cache &MUST; treat other invalid date formats, 1607 especially including the value "0", as in the past (i.e., "already 1608 expired"). 1609 </t> 1610 <x:note> 1611 <t> 1612 &Note; If a response includes a <x:ref>Cache-Control</x:ref> field with 1613 the max-age directive (see <xref target="cache-response-directive.max-age" />), 1614 that directive overrides the Expires field. Likewise, the s-maxage 1615 directive (<xref target="cache-response-directive.s-maxage" />) overrides 1616 the <x:ref>Expires</x:ref> header field in shared caches. 1617 </t> 1618 </x:note> 1595 A cache recipient &MUST; interpret invalid date formats, especially the 1596 value "0", as representing a time in the past (i.e., "already expired"). 1597 </t> 1598 <t> 1599 If a response includes a <x:ref>Cache-Control</x:ref> field with 1600 the max-age directive (<xref target="cache-response-directive.max-age"/>), 1601 a recipient &MUST; ignore the Expires field. 1602 Likewise, if a response includes the s-maxage directive 1603 (<xref target="cache-response-directive.s-maxage" />), a shared cache 1604 recipient &MUST; ignore the Expires field. In both these cases, the value 1605 in Expires is only intended for recipients that have not yet implemented 1606 the Cache-Control field. 1607 </t> 1608 <t> 1609 An origin server without a clock &MUST-NOT; generate an Expires field 1610 unless its value represents a fixed time in the past (always expired) 1611 or its value has been associated with the resource by a system or user 1612 with a reliable clock. 1613 </t> 1619 1614 <t> 1620 1615 Historically, HTTP required the Expires field-value to be no more than a … … 1624 1619 time values), and many caches will evict a response far sooner than 1625 1620 that. 1626 </t>1627 <t>1628 An origin server without a clock &MUST-NOT; assign Expires1629 values to a response unless these values were associated1630 with the resource by a system or user with a reliable clock. It &MAY;1631 assign an Expires value that is known, at or before server1632 configuration time, to be in the past (this allows "pre-expiration"1633 of responses without storing separate Expires values for each1634 resource).1635 1621 </t> 1636 1622 </section>
Note: See TracChangeset
for help on using the changeset viewer.