Changeset 1390 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 08/08/11 19:37:45 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1384 r1390 430 430 431 431 <section title="Basic Rules" anchor="basic.rules"> 432 <t anchor="rule.CRLF">433 <x:anchor-alias value="CRLF"/>434 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all435 protocol elements other than the message-body436 (see <xref target="tolerant.applications"/> for tolerant applications).437 </t>438 432 <t anchor="rule.LWS"> 439 433 This specification uses three rules to denote the use of linear … … 1230 1224 the server is reading the protocol stream at the beginning of a 1231 1225 message and receives a CRLF first, it &SHOULD; ignore the CRLF. 1226 Likewise, although the line terminator for the start-line and header 1227 fields is the sequence CRLF, we recommend that recipients recognize a 1228 single LF as a line terminator and ignore any CR. 1232 1229 </t> 1233 1230 <t> … … 1584 1581 as incomplete. A response that terminates in the middle of the header 1585 1582 block (before the empty line is received) cannot be assumed to convey the 1586 full semantics of the response and &MUST -NOT; be stored by a cache.1583 full semantics of the response and &MUST; be treated as an error. 1587 1584 </t> 1588 1585 <t> … … 2035 2032 all three formats (for compatibility with HTTP/1.0), though they &MUST; 2036 2033 only generate the RFC 1123 format for representing HTTP-date values 2037 in header fields. See <xref target="tolerant.applications"/> for further information.2034 in header fields. 2038 2035 </t> 2039 2036 <t> … … 2934 2931 respond with a 417 (Expectation Failed) status code. 2935 2932 </t> 2936 <t> Proxies &SHOULD; maintain a cache recordingthe HTTP version2933 <t> Proxies &SHOULD; maintain a record of the HTTP version 2937 2934 numbers received from recently-referenced next-hop servers. 2938 2935 </t> … … 4886 4883 4887 4884 4888 <section title="Tolerant Applications" anchor="tolerant.applications">4889 <t>4890 Although this document specifies the requirements for the generation4891 of HTTP/1.1 messages, not all applications will be correct in their4892 implementation. We therefore recommend that operational applications4893 be tolerant of deviations whenever those deviations can be4894 interpreted unambiguously.4895 </t>4896 <t>4897 The line terminator for header fields is the sequence CRLF.4898 However, we recommend that applications, when parsing such headers fields,4899 recognize a single LF as a line terminator and ignore the leading CR.4900 </t>4901 <t>4902 The character encoding of a representation &SHOULD; be labeled as the lowest4903 common denominator of the character codes used within that representation, with4904 the exception that not labeling the representation is preferred over labeling4905 the representation with the labels US-ASCII or ISO-8859-1. See &payload;.4906 </t>4907 <t>4908 Additional rules for requirements on parsing and encoding of dates4909 and other potential problems with date encodings include:4910 </t>4911 <t>4912 <list style="symbols">4913 <t>HTTP/1.1 clients and caches &SHOULD; assume that an RFC-850 date4914 which appears to be more than 50 years in the future is in fact4915 in the past (this helps solve the "year 2000" problem).</t>4916 4917 <t>Although all date formats are specified to be case-sensitive,4918 recipients &SHOULD; match day, week and timezone names4919 case-insensitively.</t>4920 4921 <t>An HTTP/1.1 implementation &MAY; internally represent a parsed4922 Expires date as earlier than the proper value, but &MUST-NOT;4923 internally represent a parsed Expires date as later than the4924 proper value.</t>4925 4926 <t>All expiration-related calculations &MUST; be done in GMT. The4927 local time zone &MUST-NOT; influence the calculation or comparison4928 of an age or expiration time.</t>4929 4930 <t>If an HTTP header field incorrectly carries a date value with a time4931 zone other than GMT, it &MUST; be converted into GMT using the4932 most conservative possible conversion.</t>4933 </list>4934 </t>4935 </section>4936 4937 4885 <section title="HTTP Version History" anchor="compatibility"> 4938 4886 <t>
Note: See TracChangeset
for help on using the changeset viewer.