Changeset 2082


Ignore:
Timestamp:
Jan 4, 2013, 2:29:06 AM (7 years ago)
Author:
fielding@…
Message:

Yet another attempt to explain HTTP-date, remove redundant requirements in sections that use HTTP-date, and correct some inconsistent requirements regarding time zones; related to #375 and [2077]

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/httpbis.abnf

    r1966 r2082  
    2727GMT = %x47.4D.54 ; GMT
    2828
    29 HTTP-date = rfc1123-date / obs-date
     29HTTP-date = IMF-fixdate / obs-date
    3030HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ]
    3131HTTP-name = %x48.54.54.50 ; HTTP
     
    3333HTTP-version = HTTP-name "/" DIGIT "." DIGIT
    3434Host = uri-host [ ":" port ]
     35IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
    3536If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS entity-tag ] ) )
    3637If-Modified-Since = HTTP-date
     
    201202request-line = method SP request-target SP HTTP-version CRLF
    202203request-target = origin-form / absolute-form / authority-form / asterisk-form
    203 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
    204204rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
    205205second = 2DIGIT
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2080 r2082  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 6, 2013";
     451       content: "Expires July 8, 2013";
    452452  }
    453453  @bottom-right {
     
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2013-01-02">
     497      <meta name="dct.issued" scheme="ISO8601" content="2013-01-04">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <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.">
     
    523523            <tr>
    524524               <td class="left">Intended status: Standards Track</td>
    525                <td class="right">January 2, 2013</td>
     525               <td class="right">January 4, 2013</td>
    526526            </tr>
    527527            <tr>
    528                <td class="left">Expires: July 6, 2013</td>
     528               <td class="left">Expires: July 8, 2013</td>
    529529               <td class="right"></td>
    530530            </tr>
     
    554554         in progress”.
    555555      </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>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    28042804      <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="origination.date" href="#origination.date">Origination Date</a></h3>
    28052805      <h4 id="rfc.section.7.1.1.1"><a href="#rfc.section.7.1.1.1">7.1.1.1</a>&nbsp;<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
     2815Sun 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">
    28182823         <p id="rfc.section.7.1.1.1.p.7">                    Preferred format:</p>
    28192824      </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 in
    2822   ; <a href="http://tools.ietf.org/html/rfc1123#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>
    28232828 
    28242829  <a href="#preferred.date.format" class="smpl">day-name</a>     = %x4D.6F.6E ; "Mon", case-sensitive
     
    28482853  <a href="#preferred.date.format" class="smpl">year</a>         = 4<a href="#imported.abnf" class="smpl">DIGIT</a>
    28492854
    2850   <a href="#preferred.date.format" class="smpl">GMT</a>   = %x47.4D.54 ; "GMT", case-sensitive
     2855  <a href="#preferred.date.format" class="smpl">GMT</a>          = %x47.4D.54 ; "GMT", case-sensitive
    28512856
    28522857  <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:59
     2858               ; 00:00:00 - 23:59:60 (leap second)
    28542859                 
    28552860  <a href="#preferred.date.format" class="smpl">hour</a>         = 2<a href="#imported.abnf" class="smpl">DIGIT</a>               
    28562861  <a href="#preferred.date.format" class="smpl">minute</a>       = 2<a href="#imported.abnf" class="smpl">DIGIT</a>               
    28572862  <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>
    28622865      </div>
    28632866      <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>
    28642867</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>
    28652868  <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-sensitive
    2869          / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
     2869               ; 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
    28702873         / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
    2871          / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
    2872          / %x46.72.69.64.61.79 ; "Friday", case-sensitive
    2873          / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
    2874          / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
     2874         / %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
    28752878</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>
    28762879  <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.
    28812889      </p>
    28822890      <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.
    28902893         </p>
    28912894      </div>
     
    28932896      <h4 id="rfc.section.7.1.1.2"><a href="#rfc.section.7.1.1.2">7.1.1.2</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h4>
    28942897      <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&nbsp;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&nbsp;7.1.1.1</a>.
    28962899      </p>
    28972900      <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>
     
    29022905         message origination.
    29032906      </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.
    29062909      </p>
    29072910      <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
     
    39513954         </tr>
    39523955         <tr>
    3953             <td class="reference"><b id="RFC1123">[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&nbsp;3, RFC&nbsp;1123, October&nbsp;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&nbsp;1305, March&nbsp;1992.
    39553958            </td>
    39563959         </tr>
     
    40564059      </div>
    40574060      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<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,
    40594062         RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
    40604063         carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
     
    42524255<a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; GMT
    42534256
    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
    42554260
    42564261<a href="#header.location" class="smpl">Location</a> = URI-reference
     
    43464351<a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
    43474352
    4348 <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT
    43494353<a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT
    43504354
     
    45194523                        <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>7.1.1.1</b></a></li>
    45204524                        <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>7.1.1.1</b></a></li>
     4525                        <li><tt>IMF-fixdate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li>
    45214526                        <li><tt>language-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>5.3.5</b></a></li>
    45224527                        <li><tt>language-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>3.1.3.1</b></a></li>
     
    45364541                        <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>5.5.2</b></a></li>
    45374542                        <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>7.1.3</b></a></li>
    4538                         <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li>
    45394543                        <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>7.1.1.1</b></a></li>
    45404544                        <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>7.1.1.1</b></a></li>
     
    46584662                  <li><em>REST</em>&nbsp;&nbsp;<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>
    46594663                  <li>Retry-After header field&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">7.1.1.1</a></li>
    4662                      </ul>
    4663                   </li>
     4664                  <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">7.1.1.1</a>, <a href="#RFC1305"><b>11.2</b></a></li>
    46644665                  <li><em>RFC1945</em>&nbsp;&nbsp;<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>
    46654666                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a></li>
     
    47224723                     </ul>
    47234724                  </li>
    4724                   <li><em>RFC5322</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">7.1.1.1</a></li>
     4725                  <li><em>RFC5322</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a></li>
    47264727                        <li><em>Section 3.4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">7.1.1.2</a></li>
     4728                        <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.6">7.1.1.2</a></li>
    47284729                     </ul>
    47294730                  </li>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2080 r2082  
    35163516  <x:anchor-alias value="HTTP-date"/>
    35173517<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>
    35243526</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="  ">
     3528Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate
    35323529</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="  ">
     3531Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
     3532Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
    35423533</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>
    35433548<t anchor="preferred.date.format">
    3544   <x:anchor-alias value="rfc1123-date"/>
     3549  <x:anchor-alias value="IMF-fixdate"/>
    35453550  <x:anchor-alias value="time-of-day"/>
    35463551  <x:anchor-alias value="hour"/>
     
    35543559  Preferred format:
    35553560</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 in
    3559   ; <xref target="RFC1123" 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"/>
    35603565 
    35613566  <x:ref>day-name</x:ref>     = <x:abnf-char-sequence>"Mon"</x:abnf-char-sequence> ; "Mon", case-sensitive
     
    35853590  <x:ref>year</x:ref>         = 4<x:ref>DIGIT</x:ref>
    35863591
    3587   <x:ref>GMT</x:ref>   = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive
     3592  <x:ref>GMT</x:ref>          = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive
    35883593
    35893594  <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:59
     3595               ; 00:00:00 - 23:59:60 (leap second)
    35913596                 
    35923597  <x:ref>hour</x:ref>         = 2<x:ref>DIGIT</x:ref>               
     
    35943599  <x:ref>second</x:ref>       = 2<x:ref>DIGIT</x:ref>               
    35953600</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 the
    3599   same as those defined for the RFC 5322 constructs
    3600   with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>).
    3601 </t>
    36023601<t anchor="obsolete.date.formats">
    36033602  <x:anchor-alias value="obs-date"/>
     
    36163615  <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>
    36173616  <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-sensitive
    3621          / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive
     3617               ; 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
    36223621         / <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive
    3623          / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive
    3624          / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive
    3625          / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive
    3626          / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive
     3622         / <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
    36273626</artwork></figure>
    36283627<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="asctime-date"/>
    36293628  <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>
    36303629  <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
    36323631</artwork></figure>
    36333632<t>
     
    36353634   A sender &MUST-NOT; generate additional whitespace in an HTTP-date beyond
    36363635   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>
    36513654<x:note>
    36523655  <t>
    36533656    &Note; HTTP requirements for the date/time stamp format apply only
    3654     to their usage within the protocol stream. Clients and servers are
     3657    to their usage within the protocol stream. Implementations are
    36553658    not required to use these formats for user presentation, request
    36563659    logging, etc.
     
    36663669   the message was originated, having the same semantics as the Origination
    36673670   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"/>.
    36703672</t>
    36713673<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
     
    36873689<t>
    36883690   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.
    36903693   An origin server &MAY; send a Date header field if the response is in the
    36913694   <x:ref>1xx (Informational)</x:ref> or <x:ref>5xx (Server Error)</x:ref>
     
    51985201</reference>
    51995202
    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" />
    52115213</reference>
    52125214
     
    59935995<x:ref>GMT</x:ref> = %x47.4D.54 ; GMT
    59945996
    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
    59966000
    59976001<x:ref>Location</x:ref> = URI-reference
     
    60876091<x:ref>qvalue</x:ref> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
    60886092
    6089 <x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT
    60906093<x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT
    60916094
  • draft-ietf-httpbis/latest/p6-cache.html

    r2080 r2082  
    452452  }
    453453  @bottom-center {
    454        content: "Expires July 6, 2013";
     454       content: "Expires July 8, 2013";
    455455  }
    456456  @bottom-right {
     
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2013-01-02">
     500      <meta name="dct.issued" scheme="ISO8601" content="2013-01-04">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <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.">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 6, 2013</td>
     526               <td class="left">Expires: July 8, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
     
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">January 2, 2013</td>
     535               <td class="right">January 4, 2013</td>
    536536            </tr>
    537537         </tbody>
     
    559559         in progress”.
    560560      </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>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    894894         which response to use.
    895895      </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.
    897897      </p>
    898898      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
     
    957957      </div>
    958958      <h3 id="rfc.section.4.1.3"><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;<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's
    960          estimate of the amount of time since the response was generated or validated by the origin server. In essence, the Age value
    961          is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus
    962          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.
    963963      </p>
    964964      <p id="rfc.section.4.1.3.p.2">The following data is used for the age calculation:</p>
     
    972972      </p>
    973973      <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.
    976975         </li>
    977976      </ul>
     
    979978      </p>
    980979      <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.
    982981         </li>
    983982      </ul>
     
    10171016      <p id="rfc.section.4.1.3.p.15"> </p>
    10181017      <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.
    10291025         </li>
    10301026      </ul>
     
    14231419         that time.
    14241420      </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>.
    14261422      </p>
    14271423      <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>
    14281424</pre><div id="rfc.figure.u.10"></div>
    14291425      <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&nbsp;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&nbsp;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&nbsp;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&nbsp;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
    14371435         are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use
    14381436         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 reliable
    1441          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).
    14431437      </p>
    14441438      <div id="rfc.iref.p.5"></div>
     
    21752169            </li>
    21762170            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    2177                   <li><em>RFC1305</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>
    21782172                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.3</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    21792173                  <li><em>RFC2616</em>&nbsp;&nbsp;<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  
    527527<t>
    528528   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.
    533530</t>
    534531
     
    659656<section anchor="age.calculations" title="Calculating Age">
    660657<t>
    661    HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey the estimated
     658   The <x:ref>Age</x:ref> header field is used to convey an estimated
    662659   age of the response message when obtained from a cache. The Age field value
    663    is the cache's estimate of the amount of time since the response was
     660   is the cache's estimate of the number of seconds since the response was
    664661   generated or validated by the origin server. In essence, the Age value is
    665662   the sum of the time that the response has been resident in each of the
     
    684681   <list>
    685682      <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
    689684         the Date header field, in a form appropriate for arithmetic
    690685         operations. See &header-date; for the definition of the Date header
     
    698693      <t>
    699694         The term "now" means "the current value of the clock at the host
    700          performing the calculation". A cache &SHOULD; use NTP (<xref
     695         performing the calculation". A host ought to use NTP (<xref
    701696         target="RFC1305"/>) or some similar protocol to synchronize its
    702          clocks to a globally accurate time standard.
     697         clocks to Coordinated Universal Time.
    703698      </t>
    704699   </list>
     
    766761<t>
    767762  <list style="symbols">
    768      <t>Recipients &SHOULD; assume that an RFC-850 date
    769         appearing to be more than 50 years in the future is in fact
    770         in the past (this helps solve the "year 2000" problem).</t>
    771 
    772763     <t>Although all date formats are specified to be case-sensitive,
    773         recipients &SHOULD; match day, week and timezone names
     764        cache recipients &SHOULD; match day, week and timezone names
    774765        case-insensitively.</t>
    775766             
    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>
    787777  </list>
    788778</t>
     
    15921582</t>
    15931583<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;.
    15961585</t>
    15971586<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/>
     
    16041593</artwork></figure>
    16051594<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>
    16191614<t>
    16201615   Historically, HTTP required the Expires field-value to be no more than a
     
    16241619   time values), and many caches will evict a response far sooner than
    16251620   that.
    1626 </t>
    1627 <t>
    1628    An origin server without a clock &MUST-NOT; assign Expires
    1629    values to a response unless these values were associated
    1630    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 server
    1632    configuration time, to be in the past (this allows "pre-expiration"
    1633    of responses without storing separate Expires values for each
    1634    resource).
    16351621</t>
    16361622</section>
Note: See TracChangeset for help on using the changeset viewer.