Changeset 2065 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 29/12/12 08:22:04 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2064 r2065 449 449 } 450 450 @bottom-center { 451 content: "Expires July 1, 2013";451 content: "Expires July 2, 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="2012-12-2 8">497 <meta name="dct.issued" scheme="ISO8601" content="2012-12-29"> 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">December 2 8, 2012</td>525 <td class="right">December 29, 2012</td> 526 526 </tr> 527 527 <tr> 528 <td class="left">Expires: July 1, 2013</td>528 <td class="left">Expires: July 2, 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 1, 2013.</p>556 <p>This Internet-Draft will expire on July 2, 2013.</p> 557 557 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 558 558 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2356 2356 <div id="rfc.iref.70"></div> 2357 2357 <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 did2360 notdefine 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. 2361 2361 </p> 2362 2362 <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 … … 2874 2874 <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> 2875 2875 <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 7.1.1.1</a> ; it <em class="bcp14">MUST</em> be sent inrfc1123-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 7.1.1.1</a>, though a sender <em class="bcp14">MUST</em> generate a Date value in the rfc1123-date format. 2877 2877 </p> 2878 2878 <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> 2879 2879 </pre><p id="rfc.section.7.1.1.2.p.3">An example is</p> 2880 2880 <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. 2901 2894 </p> 2902 2895 <div id="rfc.iref.l.1"></div>
Note: See TracChangeset
for help on using the changeset viewer.