Changeset 2077 for draft-ietf-httpbis
- Timestamp:
- 01/01/13 05:58:52 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2076 r2077 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 applications have historically allowed three different formats for date/time stamps. However, the preferred format is2807 a fixed-lengthsubset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: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 2808 </p> 2809 2809 <div id="rfc.figure.u.42"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 … … 2811 2811 <div id="rfc.figure.u.43"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 2812 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/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. 2814 </p> 2815 <p id="rfc.section.7.1.1.1.p.6">All HTTP date/time stamps are represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is 2816 exactly equal to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as 2817 the three-letter abbreviation for time zone, and is assumed when reading the asctime format. HTTP-date is case sensitive. 2818 A sender <em class="bcp14">MUST NOT</em> generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar. 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. 2819 2815 </p> 2820 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> 2821 2817 </pre><div id="preferred.date.format"> 2822 <p id="rfc.section.7.1.1.1.p. 8"> Preferred format:</p>2818 <p id="rfc.section.7.1.1.1.p.7"> Preferred format:</p> 2823 2819 </div> 2824 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> … … 2860 2856 <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#imported.abnf" class="smpl">DIGIT</a> 2861 2857 <a href="#preferred.date.format" class="smpl">second</a> = 2<a href="#imported.abnf" class="smpl">DIGIT</a> 2862 </pre><p id="rfc.section.7.1.1.1.p. 10">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>).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>). 2863 2859 </p> 2864 2860 <div id="obsolete.date.formats"> 2865 <p id="rfc.section.7.1.1.1.p.1 1"> Obsolete formats:</p>2861 <p id="rfc.section.7.1.1.1.p.10"> Obsolete formats:</p> 2866 2862 </div> 2867 2863 <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> … … 2880 2876 <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> )) 2881 2877 ; month day (e.g., Jun 2) 2882 </pre><div class="note" id="rfc.section.7.1.1.1.p.15"> 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. 2881 </p> 2882 <div class="note" id="rfc.section.7.1.1.1.p.16"> 2883 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 2884 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 2885 2885 </p> 2886 2886 </div> 2887 <div class="note" id="rfc.section.7.1.1.1.p.1 6">2887 <div class="note" id="rfc.section.7.1.1.1.p.17"> 2888 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 2889 are not required to use these formats for user presentation, request logging, etc. -
draft-ietf-httpbis/latest/p2-semantics.xml
r2076 r2077 3512 3512 <x:anchor-alias value="HTTP-date"/> 3513 3513 <t> 3514 HTTP applications havehistorically allowed three different formats3514 HTTP has historically allowed three different formats 3515 3515 for date/time stamps. However, the preferred format is a fixed-length subset 3516 3516 of that defined by <xref target="RFC1123"/>: … … 3528 3528 </artwork></figure> 3529 3529 <t> 3530 HTTP/1.1 clients and servers that parse a date value &MUST; accept 3531 all three formats (for compatibility with HTTP/1.0), though they &MUST; 3532 only generate the RFC 1123 format for representing HTTP-date values 3533 in header fields. 3534 </t> 3535 <t> 3536 All HTTP date/time stamps are represented in Greenwich Mean Time 3537 (GMT), without exception. For the purposes of HTTP, GMT is exactly 3538 equal to UTC (Coordinated Universal Time). This is indicated in the 3539 first two formats by the inclusion of "GMT" as the three-letter 3540 abbreviation for time zone, and is assumed when reading the 3541 asctime format. HTTP-date is case sensitive. A sender &MUST-NOT; generate 3542 additional whitespace in an HTTP-date beyond that specifically included as 3543 SP in the grammar. 3530 HTTP always represents dates as an instance of Coordinated Universal Time 3531 (UTC), without exception; the first two formats indicate UTC as "GMT" in 3532 the three-letter abbreviation for time zone. Recipients &MAY; assume UTC 3533 even if the time zone abbreviation is missing, invalid, or might indicate 3534 some other time zone. 3544 3535 </t> 3545 3536 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/> … … 3636 3627 ; month day (e.g., Jun 2) 3637 3628 </artwork></figure> 3629 <t> 3630 HTTP-date is case sensitive. 3631 A sender &MUST-NOT; generate additional whitespace in an HTTP-date beyond 3632 that specifically included as SP in the grammar. 3633 </t> 3634 <t> 3635 Recipients that parse a date value &MUST; accept all three formats (for 3636 compatibility with HTTP/1.0). A sender &MUST; only generate the RFC 1123 3637 format when sending HTTP-date values in header fields. 3638 </t> 3638 3639 <x:note> 3639 3640 <t>
Note: See TracChangeset
for help on using the changeset viewer.