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