Changeset 2065 for draft-ietf-httpbis
- Timestamp:
- 29/12/12 08:22:04 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 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> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2064 r2065 2585 2585 <iref primary="true" item="Status Codes Classes" subitem="1xx Informational" x:for-anchor=""/> 2586 2586 <t> 2587 This class of status code indicates a provisionalresponse,2587 This class of status code indicates an interim response, 2588 2588 consisting only of the status-line and optional header fields, and is 2589 2589 terminated by an empty line. There are no required header fields for this … … 3628 3628 the message was originated, having the same semantics as the Origination 3629 3629 Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>. 3630 The field value is an HTTP-date, as defined in <xref target="http.date"/> ;3631 it &MUST; be sent inrfc1123-date format.3630 The field value is an HTTP-date, as defined in <xref target="http.date"/>, 3631 though a sender &MUST; generate a Date value in the rfc1123-date format. 3632 3632 </t> 3633 3633 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/> … … 3641 3641 </artwork></figure> 3642 3642 <t> 3643 Origin servers &MUST; include a Date header field in all responses, 3644 except in these cases: 3645 <list style="numbers"> 3646 <t>If the response status code is <x:ref>100 (Continue)</x:ref> or 3647 <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a 3648 Date header field, at the server's option.</t> 3649 3650 <t>If the response status code conveys a server error, e.g., <x:ref>500 3651 (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>, 3652 and it is inconvenient or impossible to generate a valid Date.</t> 3653 3654 <t>If the server does not have a clock that can provide a 3655 reasonable approximation of the current time, its responses 3656 &MUST-NOT; include a Date header field.</t> 3657 </list> 3658 </t> 3659 <t> 3660 A received message that does not have a Date header field &MUST; be 3661 assigned one by the recipient if the message will be cached by that 3662 recipient. 3663 </t> 3664 <t> 3665 Clients can use the Date header field as well; in order to keep request 3666 messages small, they are advised not to include it when it doesn't convey 3667 any useful information (as is usually the case for requests that do not 3668 contain a payload). 3669 </t> 3670 <t> 3671 The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and 3672 time subsequent to the generation of the message. It &SHOULD; represent 3673 the best available approximation of the date and time of message 3674 generation, unless the implementation has no means of generating a 3675 reasonably accurate date and time. In theory, the date ought to 3676 represent the moment just before the payload is generated. In 3677 practice, the date can be generated at any time during the message 3678 origination without affecting its semantic value. 3643 When a Date header field is generated, the sender &SHOULD; generate its 3644 field value as the best available approximation of the date and time of 3645 message generation. In theory, the date ought to represent the moment just 3646 before the payload is generated. In practice, the date can be generated at 3647 any time during message origination. 3648 </t> 3649 <t> 3650 An origin server &MUST-NOT; send a Date header field if it does not have a 3651 clock capable of providing a reasonable approximation of the current time. 3652 An origin server &MAY; send a Date header field if the response is in the 3653 <x:ref>1xx (Informational)</x:ref> or <x:ref>5xx (Server Error)</x:ref> 3654 class of status codes. 3655 An origin server &MUST; send a Date header field in all other cases. 3656 </t> 3657 <t> 3658 A recipient with a clock that receives a response message without a Date 3659 header field &MUST; record the time it was received and append a 3660 corresponding Date header field to the message's header block if it is 3661 cached or forwarded downstream. 3662 </t> 3663 <t> 3664 A user agent &MAY; send a Date header field in a request, though generally 3665 will not do so unless it is believed to convey useful information to the 3666 server. For example, custom applications of HTTP might convey a Date if 3667 the server is expected to adjust its interpretation of the user's request 3668 based on differences between the user agent and server clocks. 3679 3669 </t> 3680 3670 </section>
Note: See TracChangeset
for help on using the changeset viewer.