Changeset 1452 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 23/10/11 20:20:31 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r1449 r1452 15 15 <!ENTITY ID-MONTH "October"> 16 16 <!ENTITY ID-YEAR "2011"> 17 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 17 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 388 389 </section> 389 390 390 <section anchor="intro.requirements" title="Requirements">391 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 391 392 <t> 392 393 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 395 396 </t> 396 397 <t> 397 An implementation is not compliant if it fails to satisfy one or more of 398 the "MUST" or "REQUIRED" level requirements for the protocols it 399 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 400 level and all the "SHOULD" level requirements for its protocols is said to 401 be "unconditionally compliant"; one that satisfies all the "MUST" level 402 requirements but not all the "SHOULD" level requirements for its protocols 403 is said to be "conditionally compliant". 398 This document defines conformance criteria for several roles in HTTP 399 communication, including Senders, Recipients, Clients, Servers, User-Agents, 400 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 401 for definitions of these terms. 402 </t> 403 <t> 404 An implementation is considered conformant if it complies with all of the 405 requirements associated with its role(s). Note that SHOULD-level requirements 406 are relevant here, unless one of the documented exceptions is applicable. 407 </t> 408 <t> 409 This document also uses ABNF to define valid protocol elements 410 (<xref target="notation"/>). In addition to the prose requirements placed 411 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 412 </t> 413 <t> 414 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 415 protocol element from an invalid construct. However, HTTP does not define 416 specific error handling mechanisms, except in cases where it has direct 417 impact on security. This is because different uses of the protocol require 418 different error handling strategies; for example, a Web browser may wish to 419 transparently recover from a response where the Location header field 420 doesn't parse according to the ABNF, whereby in a systems control protocol 421 using HTTP, this type of error recovery could lead to dangerous consequences. 404 422 </t> 405 423 </section> … … 2895 2913 <list style="symbols"> 2896 2914 <t> 2915 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 2916 "Document HTTP's error-handling philosophy" 2917 </t> 2918 <t> 2897 2919 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/317"/>: 2898 2920 "Cache-Control directive case sensitivity"
Note: See TracChangeset
for help on using the changeset viewer.