Ignore:
Timestamp:
Dec 29, 2012, 12:22:04 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) rephrase Date for better targeting of subject requirements

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2064 r2065  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 1, 2013";
     451       content: "Expires July 2, 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="2012-12-28">
     497      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
    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">December 28, 2012</td>
     525               <td class="right">December 29, 2012</td>
    526526            </tr>
    527527            <tr>
    528                <td class="left">Expires: July 1, 2013</td>
     528               <td class="left">Expires: July 2, 2013</td>
    529529               <td class="right"></td>
    530530            </tr>
    … …  
    554554         in progress”.
    555555      </p>
    556       <p>This Internet-Draft will expire on July 1, 2013.</p>
     556      <p>This Internet-Draft will expire on July 2, 2013.</p>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    23562356      <div id="rfc.iref.70"></div>
    23572357      <div id="rfc.iref.s.2"></div>
    2358       <p id="rfc.section.6.2.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields,
    2359          and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did
    2360          not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
     2358      <p id="rfc.section.6.2.p.1">This class of status code indicates an interim response, consisting only of the status-line and optional header fields, and
     2359         is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did not
     2360         define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    23612361      </p>
    23622362      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a <a href="#status.100" class="smpl">100
    … …  
    28742874      <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>
    28752875      <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
    2876          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>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
     2876         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.
    28772877      </p>
    28782878      <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>
    28792879</pre><p id="rfc.section.7.1.1.2.p.3">An example is</p>
    28802880      <div id="rfc.figure.u.50"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    2881 </pre><p id="rfc.section.7.1.1.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
    2882       </p>
    2883       <ol>
    2884          <li>If the response status code is <a href="#status.100" class="smpl">100 (Continue)</a> or <a href="#status.101" class="smpl">101 (Switching Protocols)</a>, the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
    2885          </li>
    2886          <li>If the response status code conveys a server error, e.g., <a href="#status.500" class="smpl">500
    2887                (Internal Server Error)</a> or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date.
    2888          </li>
    2889          <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field.
    2890          </li>
    2891       </ol>
    2892       <p id="rfc.section.7.1.1.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
    2893       </p>
    2894       <p id="rfc.section.7.1.1.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
    2895          when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload).
    2896       </p>
    2897       <p id="rfc.section.7.1.1.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    2898          of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    2899          is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
    2900          value.
     2881</pre><p id="rfc.section.7.1.1.2.p.5">When a Date header field is generated, the sender <em class="bcp14">SHOULD</em> generate its field value as the best available approximation of the date and time of message generation. In theory, the date
     2882         ought to represent the moment just before the payload is generated. In practice, the date can be generated at any time during
     2883         message origination.
     2884      </p>
     2885      <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.
     2886         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.
     2887      </p>
     2888      <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
     2889         or forwarded downstream.
     2890      </p>
     2891      <p id="rfc.section.7.1.1.2.p.8">A user agent <em class="bcp14">MAY</em> send a Date header field in a request, though generally will not do so unless it is believed to convey useful information
     2892         to the server. For example, custom applications of HTTP might convey a Date if the server is expected to adjust its interpretation
     2893         of the user's request based on differences between the user agent and server clocks.
    29012894      </p>
    29022895      <div id="rfc.iref.l.1"></div>
Note: See TracChangeset for help on using the changeset viewer.