Changeset 1875 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 10/09/12 02:46:17 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1873 r1875 573 573 <ul class="toc"> 574 574 <li><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a><ul> 575 <li><a href="#rfc.section.1.1">1.1</a> <a href="# intro.conformance.and.error.handling">Conformance and Error Handling</a></li>575 <li><a href="#rfc.section.1.1">1.1</a> <a href="#conformance">Conformance and Error Handling</a></li> 576 576 <li><a href="#rfc.section.1.2">1.2</a> <a href="#notation">Syntax Notation</a></li> 577 577 </ul> … … 651 651 selected representation. 652 652 </p> 653 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id=" intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>653 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="conformance" href="#conformance">Conformance and Error Handling</a></h2> 654 654 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 655 655 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>. 656 656 </p> 657 <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 658 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 659 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.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for definitions of these terms. 660 </p> 661 <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 662 forwarding a received element downstream. 663 </p> 664 <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 665 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 666 </p> 667 <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</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 668 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 669 to the recipient's role. 670 </p> 671 <p id="rfc.section.1.1.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 672 except when they have a direct impact on security, since different applications of the protocol require different error handling 673 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 674 to be dangerous. 657 <p id="rfc.section.1.1.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.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 675 658 </p> 676 659 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 1463 1446 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2.3.3</a>, <a href="#rfc.xref.Part1.5">7</a>, <a href="#rfc.xref.Part1.6">8</a>, <a href="#Part1"><b>9.1</b></a>, <a href="#rfc.xref.Part1.7">B</a>, <a href="#rfc.xref.Part1.8">B</a>, <a href="#rfc.xref.Part1.9">B</a><ul> 1464 1447 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 1465 <li><em>Section 2 </em> <a href="#rfc.xref.Part1.2">1.1</a></li>1448 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 1466 1449 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.8">B</a></li> 1467 1450 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.9">B</a></li>
Note: See TracChangeset
for help on using the changeset viewer.