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