Changeset 1641 for draft-ietf-httpbis/latest/p3-payload.xml
- Timestamp:
- Mar 30, 2012, 7:44:42 AM (8 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p3-payload.xml
r1640 r1641 127 127 </t> 128 128 129 <section title="Terminology" anchor="terminology">130 <t>131 This specification uses a number of terms to refer to the roles132 played by participants in, and objects of, the HTTP communication.133 </t>134 <t>135 <iref item="content negotiation"/>136 <x:dfn>content negotiation</x:dfn>137 <list>138 <t>139 The mechanism for selecting the appropriate representation when140 servicing a request. The representation in any response141 can be negotiated (including error responses).142 </t>143 </list>144 </t>145 <t>146 <iref primary="true" item="selected representation"/>147 <x:dfn>selected representation</x:dfn>148 <list>149 <t>150 The current representation of the target resource that would have been151 selected in a successful response if the same request had used the152 method GET and excluded any conditional request header fields.153 </t>154 </list>155 </t>156 </section>157 158 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">159 <t>160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this162 document are to be interpreted as described in <xref target="RFC2119"/>.163 </t>164 <t>165 This document defines conformance criteria for several roles in HTTP166 communication, including Senders, Recipients, Clients, Servers, User-Agents,167 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;168 for definitions of these terms.169 </t>170 <t>171 An implementation is considered conformant if it complies with all of the172 requirements associated with its role(s). Note that SHOULD-level requirements173 are relevant here, unless one of the documented exceptions is applicable.174 </t>175 <t>176 This document also uses ABNF to define valid protocol elements177 (<xref target="notation"/>). In addition to the prose requirements placed178 upon them, Senders &MUST-NOT; generate protocol elements that are invalid.179 </t>180 <t>181 Unless noted otherwise, Recipients &MAY; take steps to recover a usable182 protocol element from an invalid construct. However, HTTP does not define183 specific error handling mechanisms, except in cases where it has direct184 impact on security. This is because different uses of the protocol require185 different error handling strategies; for example, a Web browser may wish to186 transparently recover from a response where the Location header field187 doesn't parse according to the ABNF, whereby in a systems control protocol188 using HTTP, this type of error recovery could lead to dangerous consequences.189 </t>190 </section>191 192 129 <section title="Syntax Notation" anchor="notation"> 193 130 <x:anchor-alias value="ALPHA"/> … … 1677 1614 </reference> 1678 1615 1679 <reference anchor="RFC2119">1680 <front>1681 <title>Key words for use in RFCs to Indicate Requirement Levels</title>1682 <author initials="S." surname="Bradner" fullname="Scott Bradner">1683 <organization>Harvard University</organization>1684 <address><email>sob@harvard.edu</email></address>1685 </author>1686 <date month="March" year="1997"/>1687 </front>1688 <seriesInfo name="BCP" value="14"/>1689 <seriesInfo name="RFC" value="2119"/>1690 </reference>1691 1692 1616 <reference anchor='RFC4647'> 1693 1617 <front>
Note: See TracChangeset
for help on using the changeset viewer.