Changeset 1781 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- Jul 14, 2012, 7:55:39 PM (7 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r1778 r1781 188 188 distributed, collaborative, hypertext information systems. HTTP has been in 189 189 use by the World Wide Web global information initiative since 1990. This 190 document is Part 2 of the s even-part specification that defines the protocol191 referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.192 </t> 193 <t> 194 Part 2 defines the semantics of HTTP messages as expressed by request190 document is Part 2 of the six-part specification that defines the protocol 191 referred to as "HTTP/1.1". 192 </t> 193 <t> 194 Part 2 defines the semantics of HTTP messages, as expressed by request 195 195 methods, request header fields, response status codes, and response header 196 fields . Furthermore, it defines HTTP message content, metadata, and content197 negotiation.196 fields, the payload of messages as metadata and body content, and the 197 mechanisms for content negotiation. 198 198 </t> 199 199 </abstract> … … 219 219 <section title="Introduction" anchor="introduction"> 220 220 <t> 221 This document defines HTTP/1.1 request and response semantics. Each HTTP 222 message, as defined in &messaging;, is in the form of either a request or 223 a response. An HTTP server listens on a connection for HTTP requests and 224 responds to each request, in the order received on that connection, with 225 one or more HTTP response messages. This document defines the commonly 226 agreed upon semantics of the HTTP uniform interface, the intentions defined 227 by each request method, and the various response messages that might be 228 expected as a result of applying that method to the target resource. 229 </t> 230 <t> 231 Furthermore, it defines HTTP/1.1 message payloads (a.k.a., content), the 232 associated metadata header fields that define how the payload is intended 233 to be interpreted by a recipient, the request header fields that 234 might influence content selection, and the various selection algorithms 235 that are collectively referred to as HTTP content negotiation. 236 </t> 237 <t> 221 This document defines HTTP/1.1 request and response semantics in terms of 222 the architecture, syntax notation, and conformance criteria defined in 223 &architecture;. Each HTTP message is either a request or a response. 224 A server listens on a connection for a request, parses each message 225 received, interprets the message semantics in relation to the identified 226 request target, and responds to that request with one or more response 227 messages. 228 </t> 229 <t> 230 HTTP provides a uniform interface for interacting with resources regardless 231 of their type, nature, or implementation. HTTP semantics includes the 232 intentions defined by each request method, extensions to those semantics 233 that might be described in request header fields, the meaning of status 234 codes to indicate a machine-readable response, and additional control data 235 and resource metadata that might be given in response header fields. 236 </t> 237 <t><iref item="content negotiation"/> 238 In addition, this document defines the payload of messages (a.k.a., 239 content), the associated metadata header fields that define how the payload 240 is intended to be interpreted by a recipient, the request header fields 241 that might influence content selection, and the various selection 242 algorithms that are collectively referred to as 243 "<x:dfn>content negotiation</x:dfn>". 244 </t> 245 <x:note><t> 238 246 This document is currently disorganized in order to minimize the changes 239 247 between drafts and enable reviewers to see the smaller errata changes. … … 245 253 reflects how widely dispersed these topics and associated requirements 246 254 had become in <xref target="RFC2616"/>. 247 </t> 248 249 <section title="Terminology" anchor="terminology"> 250 <t> 251 This specification uses a number of terms to refer to the roles 252 played by participants in, and objects of, the HTTP communication. 253 </t> 254 <t> 255 <iref item="content negotiation"/> 256 <x:dfn>content negotiation</x:dfn> 257 <list> 258 <t> 259 The mechanism for selecting the appropriate representation when 260 servicing a request. The representation in any response 261 can be negotiated (including error responses). 262 </t> 263 </list> 264 </t> 265 <t> 266 <iref primary="true" item="selected representation"/> 267 <x:dfn>selected representation</x:dfn> 268 <list> 269 <t> 270 The current representation of the target resource that would have been 271 selected in a successful response if the same request had used the 272 method GET and excluded any conditional request header fields. 273 </t> 274 </list> 275 </t> 276 </section> 277 278 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 279 <t> 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 282 document are to be interpreted as described in <xref target="RFC2119"/>. 283 </t> 284 <t> 285 This specification targets conformance criteria according to the role of 286 a participant in HTTP communication. Hence, HTTP requirements are placed 287 on senders, recipients, clients, servers, user agents, intermediaries, 288 origin servers, proxies, gateways, or caches, depending on what behavior 289 is being constrained by the requirement. See &architecture; for definitions 290 of these terms. 291 </t> 292 <t> 293 The verb "generate" is used instead of "send" where a requirement 294 differentiates between creating a protocol element and merely forwarding a 295 received element downstream. 296 </t> 297 <t> 298 An implementation is considered conformant if it complies with all of the 299 requirements associated with the roles it partakes in HTTP. Note that 300 SHOULD-level requirements are relevant here, unless one of the documented 301 exceptions is applicable. 302 </t> 303 <t> 304 This document also uses ABNF to define valid protocol elements 305 (<xref target="notation"/>). 306 In addition to the prose requirements placed upon them, senders &MUST-NOT; 307 generate protocol elements that do not match the grammar defined by the 308 ABNF rules for those protocol elements that are applicable to the sender's 309 role. If a received protocol element is processed, the recipient &MUST; be 310 able to parse any value that would match the ABNF rules for that protocol 311 element, excluding only those rules not applicable to the recipient's role. 312 </t> 313 <t> 314 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 315 protocol element from an invalid construct. HTTP does not define 316 specific error handling mechanisms except when they have a direct impact 317 on security, since different applications of the protocol require 318 different error handling strategies. For example, a Web browser might 319 wish to transparently recover from a response where the 320 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 321 whereas a systems control client might consider any form of error recovery 322 to be dangerous. 323 </t> 324 </section> 325 326 <section title="Syntax Notation" anchor="notation"> 327 <x:anchor-alias value="ALPHA"/> 328 <x:anchor-alias value="CR"/> 329 <x:anchor-alias value="DIGIT"/> 330 <x:anchor-alias value="LF"/> 331 <x:anchor-alias value="OCTET"/> 332 <x:anchor-alias value="SP"/> 333 <x:anchor-alias value="VCHAR"/> 334 <t> 335 This specification uses the Augmented Backus-Naur Form (ABNF) notation 336 of <xref target="RFC5234"/> with the list rule extension defined in 337 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 338 with the list rule expanded. 339 </t> 340 <t> 341 The following core rules are included by 342 reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: 343 ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), 344 DIGIT (decimal 0-9), DQUOTE (double quote), 345 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), 346 OCTET (any 8-bit sequence of data), SP (space), and 347 VCHAR (any visible US-ASCII character). 348 </t> 349 350 <section title="Core Rules" anchor="core.rules"> 351 <x:anchor-alias value="quoted-string"/> 352 <x:anchor-alias value="token"/> 353 <x:anchor-alias value="word"/> 354 <x:anchor-alias value="BWS"/> 355 <x:anchor-alias value="OWS"/> 356 <x:anchor-alias value="RWS"/> 357 <t> 358 The core rules below are defined in <xref target="Part1"/>: 359 </t> 360 <figure><artwork type="abnf2616"> 361 <x:ref>BWS</x:ref> = <BWS, defined in &whitespace;> 362 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 363 <x:ref>RWS</x:ref> = <RWS, defined in &whitespace;> 364 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field-components;> 365 <x:ref>token</x:ref> = <token, defined in &field-components;> 366 <x:ref>word</x:ref> = <word, defined in &field-components;> 367 </artwork></figure> 368 </section> 369 370 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> 371 <x:anchor-alias value="absolute-URI"/> 372 <x:anchor-alias value="comment"/> 373 <x:anchor-alias value="partial-URI"/> 374 <x:anchor-alias value="qvalue"/> 375 <x:anchor-alias value="URI-reference"/> 376 <t> 377 The ABNF rules below are defined in other parts: 378 </t> 379 <figure><!--Part1--><artwork type="abnf2616"> 380 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> 381 <x:ref>comment</x:ref> = <comment, defined in &field-components;> 382 <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;> 383 <x:ref>qvalue</x:ref> = <qvalue, defined in &qvalue;> 384 <x:ref>URI-reference</x:ref> = <URI-reference, defined in &uri;> 385 </artwork></figure> 386 </section> 387 </section> 255 </t></x:note> 388 256 </section> 389 257 … … 2781 2649 <c>Expires</c> <c>&header-expires;</c> 2782 2650 </texttable> 2651 <t><iref primary="true" item="selected representation"/> 2652 We use the term "<x:dfn>selected representation</x:dfn>" to refer to the 2653 the current representation of a target resource that would have been 2654 selected in a successful response if the same request had used the 2655 method GET and excluded any conditional request header fields. 2656 </t> 2783 2657 <t> 2784 2658 Additional header fields define metadata about the selected … … 3797 3671 &Note; Some recipients attempt to recover from Location fields 3798 3672 that are not valid URI references. This specification does not mandate or 3799 define such processing, but does allow it (see <xref target="intro.conformance.and.error.handling"/>).3673 define such processing, but does allow it. 3800 3674 </t> 3801 3675 </x:note> … … 4462 4336 </section> 4463 4337 4338 <section title="ABNF Rules Defined Elsewhere" anchor="abnf.dependencies"> 4339 <x:anchor-alias value="ALPHA"/> 4340 <x:anchor-alias value="CR"/> 4341 <x:anchor-alias value="DIGIT"/> 4342 <x:anchor-alias value="LF"/> 4343 <x:anchor-alias value="OCTET"/> 4344 <x:anchor-alias value="SP"/> 4345 <x:anchor-alias value="VCHAR"/> 4346 <x:anchor-alias value="BWS"/> 4347 <x:anchor-alias value="OWS"/> 4348 <x:anchor-alias value="RWS"/> 4349 <x:anchor-alias value="absolute-URI"/> 4350 <x:anchor-alias value="comment"/> 4351 <x:anchor-alias value="partial-URI"/> 4352 <x:anchor-alias value="qvalue"/> 4353 <x:anchor-alias value="URI-reference"/> 4354 <x:anchor-alias value="quoted-string"/> 4355 <x:anchor-alias value="token"/> 4356 <x:anchor-alias value="word"/> 4357 <t> 4358 This specification uses the Augmented Backus-Naur Form (ABNF) notation 4359 of <xref target="RFC5234"/> with the list rule extension defined in 4360 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 4361 with the list rule expanded. 4362 </t> 4363 <t> 4364 The following core rules are included by 4365 reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: 4366 ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), 4367 DIGIT (decimal 0-9), DQUOTE (double quote), 4368 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), 4369 OCTET (any 8-bit sequence of data), SP (space), and 4370 VCHAR (any visible US-ASCII character). 4371 </t> 4372 <t> 4373 The ABNF rules below are defined in other parts: 4374 </t> 4375 <figure><artwork type="abnf2616"> 4376 <x:ref>BWS</x:ref> = <BWS, defined in &whitespace;> 4377 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 4378 <x:ref>RWS</x:ref> = <RWS, defined in &whitespace;> 4379 <x:ref>URI-reference</x:ref> = <URI-reference, defined in &uri;> 4380 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> 4381 <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;> 4382 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field-components;> 4383 <x:ref>qvalue</x:ref> = <qvalue, defined in &qvalue;> 4384 <x:ref>token</x:ref> = <token, defined in &field-components;> 4385 <x:ref>word</x:ref> = <word, defined in &field-components;> 4386 <x:ref>comment</x:ref> = <comment, defined in &field-components;> 4387 </artwork></figure> 4388 </section> 4389 4464 4390 <section title="Security Considerations" anchor="security.considerations"> 4465 4391 <t> … … 4871 4797 <seriesInfo name="RFC" value="2046"/> 4872 4798 </reference> 4873 4799 <!-- 4874 4800 <reference anchor="RFC2119"> 4875 4801 <front> … … 4884 4810 <seriesInfo name="RFC" value="2119"/> 4885 4811 </reference> 4886 4812 --> 4887 4813 <reference anchor="RFC3986"> 4888 4814 <front>
Note: See TracChangeset
for help on using the changeset viewer.