Changeset 1875 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 10/09/12 02:46:17 (8 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r1867 r1875 18 18 <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>"> 19 19 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY conformance "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 21 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 22 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 298 299 </section> 299 300 300 <section title="Conformance and Error Handling" anchor=" intro.conformance.and.error.handling">301 <section title="Conformance and Error Handling" anchor="conformance"> 301 302 <t> 302 303 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 305 306 </t> 306 307 <t> 307 This specification targets conformance criteria according to the role of 308 a participant in HTTP communication. Hence, HTTP requirements are placed 309 on senders, recipients, clients, servers, user agents, intermediaries, 310 origin servers, proxies, gateways, or caches, depending on what behavior 311 is being constrained by the requirement. See &architecture; for definitions 312 of these terms. 313 </t> 314 <t> 315 The verb "generate" is used instead of "send" where a requirement 316 differentiates between creating a protocol element and merely forwarding a 317 received element downstream. 318 </t> 319 <t> 320 An implementation is considered conformant if it complies with all of the 321 requirements associated with the roles it partakes in HTTP. Note that 322 SHOULD-level requirements are relevant here, unless one of the documented 323 exceptions is applicable. 324 </t> 325 <t> 326 This document also uses ABNF to define valid protocol elements 327 (<xref target="notation"/>). 328 In addition to the prose requirements placed upon them, senders &MUST-NOT; 329 generate protocol elements that do not match the grammar defined by the 330 ABNF rules for those protocol elements that are applicable to the sender's 331 role. If a received protocol element is processed, the recipient &MUST; be 332 able to parse any value that would match the ABNF rules for that protocol 333 element, excluding only those rules not applicable to the recipient's role. 334 </t> 335 <t> 336 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 337 protocol element from an invalid construct. HTTP does not define 338 specific error handling mechanisms except when they have a direct impact 339 on security, since different applications of the protocol require 340 different error handling strategies. For example, a Web browser might 341 wish to transparently recover from a response where the 342 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 343 whereas a systems control client might consider any form of error recovery 344 to be dangerous. 308 Conformance criteria and considerations regarding error handling 309 are defined in &conformance;. 345 310 </t> 346 311 </section> … … 816 781 <t> 817 782 <list style="symbols"> 818 <t> HTTP/1.1 clients and caches &SHOULD; assume that an RFC-850 date783 <t>Recipients &SHOULD; assume that an RFC-850 date 819 784 which appears to be more than 50 years in the future is in fact 820 785 in the past (this helps solve the "year 2000" problem).</t> … … 824 789 case-insensitively.</t> 825 790 826 <t>An HTTP/1.1implementation &MAY; internally represent a parsed791 <t>An implementation &MAY; internally represent a parsed 827 792 <x:ref>Expires</x:ref> date as earlier than the proper value, but 828 793 &MUST-NOT; internally represent a parsed Expires date as later than the 829 794 proper value.</t> 830 795 831 <t> All expiration-related calculations &MUST; be done in GMT. The832 local time zone &MUST-NOT; influence the calculation or comparison796 <t>Recipients &MUST; perform all expiration-related calculations in GMT. 797 The local time zone &MUST-NOT; influence the calculation or comparison 833 798 of an age or expiration time.</t> 834 799
Note: See TracChangeset
for help on using the changeset viewer.