Changeset 1770 for draft-ietf-httpbis/latest/p5-range.xml
- Timestamp:
- 14/07/12 12:41:41 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.xml
r1767 r1770 165 165 </t> 166 166 <t> 167 This document defines conformance criteria for several roles in HTTP 168 communication, including Senders, Recipients, Clients, Servers, User-Agents, 169 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 170 for definitions of these terms. 167 This specification targets conformance criteria according to the role of 168 a participant in HTTP communication. Hence, HTTP requirements are placed 169 on senders, recipients, clients, servers, user agents, intermediaries, 170 origin servers, proxies, gateways, or caches, depending on what behavior 171 is being constrained by the requirement. See &architecture; for definitions 172 of these terms. 173 </t> 174 <t> 175 The verb "generate" is used instead of "send" where a requirement 176 differentiates between creating a protocol element and merely forwarding a 177 received element downstream. 171 178 </t> 172 179 <t> 173 180 An implementation is considered conformant if it complies with all of the 174 requirements associated with its role(s). Note that SHOULD-level requirements 175 are relevant here, unless one of the documented exceptions is applicable. 181 requirements associated with the roles it partakes in HTTP. Note that 182 SHOULD-level requirements are relevant here, unless one of the documented 183 exceptions is applicable. 176 184 </t> 177 185 <t> 178 186 This document also uses ABNF to define valid protocol elements 179 (<xref target="notation"/>). In addition to the prose requirements placed 180 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 181 </t> 182 <t> 183 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 184 elements matching the ABNF rules defined for them and &MAY; take steps to 185 recover a usable protocol element from an invalid construct. However, HTTP does not define 186 specific error handling mechanisms, except in cases where it has direct 187 impact on security. This is because different uses of the protocol require 188 different error handling strategies; for example, a Web browser might wish to 189 transparently recover from a response where the <x:ref>Location</x:ref> 190 header field doesn't parse according to the ABNF, whereby in a systems 191 control protocol using HTTP, this type of error recovery could lead to 192 dangerous consequences. 187 (<xref target="notation"/>). 188 In addition to the prose requirements placed upon them, senders &MUST-NOT; 189 generate protocol elements that do not match the grammar defined by the 190 ABNF rules for those protocol elements that are applicable to the sender's 191 role. If a received protocol element is processed, the recipient &MUST; be 192 able to parse any value that would match the ABNF rules for that protocol 193 element, excluding only those rules not applicable to the recipient's role. 194 </t> 195 <t> 196 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 197 protocol element from an invalid construct. HTTP does not define 198 specific error handling mechanisms except when they have a direct impact 199 on security, since different applications of the protocol require 200 different error handling strategies. For example, a Web browser might 201 wish to transparently recover from a response where the 202 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 203 whereas a systems control client might consider any form of error recovery 204 to be dangerous. 193 205 </t> 194 206 </section>
Note: See TracChangeset
for help on using the changeset viewer.