![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1875 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 10/09/12 02:46:17 (10 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p6-cache.html (modified) (4 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1873 r1875 585 585 <li><a href="#rfc.section.1.1">1.1</a> <a href="#intro.purpose">Purpose</a></li> 586 586 <li><a href="#rfc.section.1.2">1.2</a> <a href="#intro.terminology">Terminology</a></li> 587 <li><a href="#rfc.section.1.3">1.3</a> <a href="# intro.conformance.and.error.handling">Conformance and Error Handling</a></li>587 <li><a href="#rfc.section.1.3">1.3</a> <a href="#conformance">Conformance and Error Handling</a></li> 588 588 <li><a href="#rfc.section.1.4">1.4</a> <a href="#notation">Syntax Notation</a><ul> 589 589 <li><a href="#rfc.section.1.4.1">1.4.1</a> <a href="#delta-seconds">Delta Seconds</a></li> … … 776 776 </li> 777 777 </ul> 778 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id=" intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>778 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="conformance" href="#conformance">Conformance and Error Handling</a></h2> 779 779 <p id="rfc.section.1.3.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 780 780 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 781 781 </p> 782 <p id="rfc.section.1.3.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 783 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 784 or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms. 785 </p> 786 <p id="rfc.section.1.3.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 787 forwarding a received element downstream. 788 </p> 789 <p id="rfc.section.1.3.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 790 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 791 </p> 792 <p id="rfc.section.1.3.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.4</a>). In addition to the prose requirements placed upon them, senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 793 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 794 to the recipient's role. 795 </p> 796 <p id="rfc.section.1.3.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 797 except when they have a direct impact on security, since different applications of the protocol require different error handling 798 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 799 to be dangerous. 782 <p id="rfc.section.1.3.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 800 783 </p> 801 784 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 1038 1021 <p id="rfc.section.4.1.3.p.15"> </p> 1039 1022 <ul> 1040 <li> HTTP/1.1 clients and caches <em class="bcp14">SHOULD</em> assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve1023 <li>Recipients <em class="bcp14">SHOULD</em> assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve 1041 1024 the "year 2000" problem). 1042 1025 </li> 1043 1026 <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively. 1044 1027 </li> 1045 <li>An HTTP/1.1implementation <em class="bcp14">MAY</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value.1046 </li> 1047 <li> All expiration-related calculations <em class="bcp14">MUST</em> be donein GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.1028 <li>An implementation <em class="bcp14">MAY</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value. 1029 </li> 1030 <li>Recipients <em class="bcp14">MUST</em> perform all expiration-related calculations in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time. 1048 1031 </li> 1049 1032 <li>Caches <em class="bcp14">SHOULD</em> consider dates with time zones other than "GMT" invalid. … … 2186 2169 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.4</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.10">B</a>, <a href="#rfc.xref.Part1.11">B</a>, <a href="#rfc.xref.Part1.12">B</a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a><ul> 2187 2170 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.4</a></li> 2188 <li><em>Section 2 </em> <a href="#rfc.xref.Part1.1">1.3</a></li>2171 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.1">1.3</a></li> 2189 2172 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.17">B</a></li> 2190 2173 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.12">B</a></li>
Note: See TracChangeset
for help on using the changeset viewer.
