Changeset 1875 for draft-ietf-httpbis/latest/p5-range.xml
- Timestamp:
- 10/09/12 02:46:17 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.xml
r1867 r1875 17 17 <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>"> 18 18 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 <!ENTITY conformance "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 20 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 21 <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 153 154 </t> 154 155 155 <section title="Conformance and Error Handling" anchor=" intro.conformance.and.error.handling">156 <section title="Conformance and Error Handling" anchor="conformance"> 156 157 <t> 157 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 160 161 </t> 161 162 <t> 162 This specification targets conformance criteria according to the role of 163 a participant in HTTP communication. Hence, HTTP requirements are placed 164 on senders, recipients, clients, servers, user agents, intermediaries, 165 origin servers, proxies, gateways, or caches, depending on what behavior 166 is being constrained by the requirement. See &architecture; for definitions 167 of these terms. 168 </t> 169 <t> 170 The verb "generate" is used instead of "send" where a requirement 171 differentiates between creating a protocol element and merely forwarding a 172 received element downstream. 173 </t> 174 <t> 175 An implementation is considered conformant if it complies with all of the 176 requirements associated with the roles it partakes in HTTP. Note that 177 SHOULD-level requirements are relevant here, unless one of the documented 178 exceptions is applicable. 179 </t> 180 <t> 181 This document also uses ABNF to define valid protocol elements 182 (<xref target="notation"/>). 183 In addition to the prose requirements placed upon them, senders &MUST-NOT; 184 generate protocol elements that do not match the grammar defined by the 185 ABNF rules for those protocol elements that are applicable to the sender's 186 role. If a received protocol element is processed, the recipient &MUST; be 187 able to parse any value that would match the ABNF rules for that protocol 188 element, excluding only those rules not applicable to the recipient's role. 189 </t> 190 <t> 191 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 192 protocol element from an invalid construct. HTTP does not define 193 specific error handling mechanisms except when they have a direct impact 194 on security, since different applications of the protocol require 195 different error handling strategies. For example, a Web browser might 196 wish to transparently recover from a response where the 197 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 198 whereas a systems control client might consider any form of error recovery 199 to be dangerous. 163 Conformance criteria and considerations regarding error handling 164 are defined in &conformance;. 200 165 </t> 201 166 </section>
Note: See TracChangeset
for help on using the changeset viewer.