idnits 2.17.1 draft-snell-http-prefer-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2012) is 4200 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2026' is defined on line 683, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-21 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft October 24, 2012 4 Intended status: Standards Track 5 Expires: April 27, 2013 7 Prefer Header for HTTP 8 draft-snell-http-prefer-16 10 Abstract 12 This specification defines an HTTP header field that can be used by a 13 client to request that certain behaviors be employed by a server 14 while processing a request. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 27, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 52 2. The Prefer Request Header Field . . . . . . . . . . . . . . . 4 53 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3. The Preference-Applied Response Header Field . . . . . . . . . 7 55 4. Preference Definitions . . . . . . . . . . . . . . . . . . . . 8 56 4.1. The "respond-async" Preference . . . . . . . . . . . . . . 8 57 4.2. The "return=representation" and "return=minimal" 58 Preferences . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.3. The "wait" Preference . . . . . . . . . . . . . . . . . . 11 60 4.4. The "handling=strict" and "handling=lenient" 61 Processing Preferences . . . . . . . . . . . . . . . . . . 12 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 5.1. The Registry of Preferences . . . . . . . . . . . . . . . 13 64 5.2. Initial Registry Contents . . . . . . . . . . . . . . . . 14 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 Within the course of processing an HTTP request there are typically a 74 range of required and optional behaviors that a server or 75 intermediary can employ. These often manifest in a variety of subtle 76 and not-so-subtle ways within the response. 78 For example, when using the HTTP PUT method to modify a resource -- 79 similar to that defined for the Atom Publishing Protocol [RFC5023] -- 80 the server is given the option of returning either a complete 81 representation of a modified resource or a minimal response that 82 indicates only the successful completion of the operation. The 83 selection of which type of response to return to the client generally 84 has no bearing on the successful processing of the request but could, 85 for instance, have an impact on what actions the client must take 86 after receiving the response. That is, returning a representation of 87 the modified resource within the response can allow the client to 88 avoid sending an additional subsequent GET request. 90 Similarly, servers that process requests are often faced with 91 decisions about how to process requests that may be technically 92 invalid or incorrect but are still understandable. It might be the 93 case that the server is able to overlook the technical errors in the 94 request but still successfully process the request. Depending on the 95 specific requirements of the application and the nature of the 96 request being made, the client might or might not consider such 97 lenient processing of its request to be appropriate. 99 While the decision of exactly which behaviors to apply in these cases 100 lies with the server processing the request, the server might wish to 101 defer to the client to specify which optional behavior is preferred. 103 Currently, HTTP offers no explicitly defined means of expressing the 104 client's preferences regarding the optional aspects of handling of a 105 given request. While HTTP does provide the Expect header -- which 106 can be used to identify mandatory expectations for the processing of 107 a request -- use of the field to communicate optional preferences is 108 problematic: 109 1. The semantics of the Expect header field are such that 110 intermediaries and servers are required to reject any request 111 that states unrecognized or unsupported expectations. 112 2. While the Expect header field is end-to-end, the HTTP 113 specification requires that the header be processed hop-by-hop. 114 That is, every interceding intermediary that handles a request 115 between the client and the origin server is required to process 116 an expectation and determine whether it is capable of 117 appropriately handling it. 119 The rigid, must-understand semantics of the Expect header, therefore, 120 make it a poor choice for the general expression of optional 121 preferences that may be specific to an individual application and are 122 therefore unknown to an intermediary or are otherwise irrelevant to 123 the intermediaries successful handling of the request and response. 125 Another option available to clients is to utilize Request URI query- 126 string parameters to express preferences. Doing so, however, results 127 in a variety of issues affecting the cacheability of responses. 129 As an alternative, this specification defines a new HTTP request 130 header field that can be used by clients to request that optional 131 behaviors be applied by a server during the processing the request. 132 Additionally, a handful of initial preference tokens for use with the 133 new header are defined. 135 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 136 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 137 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 139 1.1. Syntax Notation 141 This specification uses the Augmented Backus-Naur Form (ABNF) 142 notation of [RFC5234] and includes, by reference, the "token", 143 "word", "OWS", "BWS" rules and the #rule extension as defined within 144 Sections 3.2.1 and 3.2.4 of [I-D.ietf-httpbis-p1-messaging]. 146 2. The Prefer Request Header Field 148 The Prefer request header field is used to indicate that particular 149 server behaviors are preferred by the client, but not required for 150 successful completion of the request. Prefer is similar in nature to 151 the Expect header field defined by Section 6.1.2 of 152 [I-D.ietf-httpbis-p2-semantics] with the exception that servers are 153 allowed to ignore stated preferences. 155 ABNF: 157 Prefer = "Prefer" ":" 1#preference 158 preference = token [ BWS "=" BWS word ] 159 *( OWS ";" [ OWS parameter ] ) 160 parameter = token [ BWS "=" BWS word ] 162 This header field is defined with an extensible syntax to allow for 163 future values included in the Registry of Preferences (Section 5.1). 164 A server that does not recognize or is unable to comply with 165 particular preference tokens in the Prefer header field of a request 166 MUST ignore those tokens and continue processing instead of 167 signalling an error. 169 A preference token can contain a value. Empty, or zero length values 170 on both the preference token and within parameters are equivalent to 171 no value being specified at all. The following, then, are equivalent 172 examples of a "foo" preference with a single "bar" parameter. 174 Prefer: foo; bar 175 Prefer: foo; bar="" 176 Prefer: foo=""; bar 178 An optional set of parameters can be specified for any preference 179 token. The meaning and application of such parameters is dependent 180 on the definition of each preference token and the server's 181 implementation thereof. There is no significance given to the 182 ordering of parameters on any given preference. 184 For both preference token names and parameter names, comparison is 185 case-insensitive while values are case-sensitive regardless of 186 whether token or quoted-string values are used. 188 The Prefer header field is end-to-end and MUST be forwarded by a 189 proxy if the request is forwarded unless Prefer is explicitly 190 identified as being hop-by-hop using the Connection header field 191 defined by [I-D.ietf-httpbis-p1-messaging], Section 6.1. 193 In various situations, a proxy might determine that it is capable of 194 honoring a preference independently of the server to which the 195 request has been directed. For instance, an intervening proxy might 196 be capable of providing asynchronous handling of a request using 202 197 Accepted responses independently of the origin server. Such proxies 198 can choose to honor the "respond-async" preference on their own 199 despite whether the origin is capable or willing to do so. 201 Individual preference tokens MAY define their own requirements and 202 restrictions as to whether and how intermediaries can apply the 203 preference to a request independently of the origin server. 205 A client MAY use multiple instances of the Prefer header field in a 206 single message, or it MAY use a single Prefer header field with 207 multiple comma-separated preference tokens. If multiple Prefer 208 header fields are used, it is equivalent to a single Prefer header 209 filed with the comma-separated concatentation of all of the tokens. 210 For example, the following are equivalent: 212 Multiple Prefer header fields defining three distinct preference 213 tokens: 215 POST /foo HTTP/1.1 216 Host: example.org 217 Prefer: respond-async, wait=100 218 Prefer: handling=lenient 219 Date: Tue, 20 Dec 2011 12:34:56 GMT 221 A single Prefer header field defining the same three preference 222 tokens: 224 POST /foo HTTP/1.1 225 Host: example.org 226 Prefer: handling=lenient, wait=100, respond-async 227 Date: Tue, 20 Dec 2011 12:34:56 GMT 229 To avoid any possible ambiguity, individual preference tokens SHOULD 230 NOT appear multiple times within a single request. If any preference 231 is specified more than once, only the first instance is to be 232 considered. All subsequent occurrences SHOULD be ignored without 233 signaling an error or otherwise altering the processing of the 234 request. This is the only case in which the ordering of preferences 235 within a request is considered to be significant. 237 Due to the inherent complexities involved with properly implementing 238 server-driven content negotiation, effective caching, and the 239 application of optional preferences, implementors are urged to 240 exercise caution when using preferences in a way that impacts the 241 caching of a response and SHOULD NOT use the Prefer header mechanism 242 for content negotiation. If a server supports the optional 243 application of a preference that might result in a variance to a 244 cache's handling of a response entity, a Vary header field MUST be 245 included in the response listing the Prefer header field regardless 246 of whether the client actually used Prefer in the request. 247 Alternatively, the server MAY include a Vary header with the special 248 value "*" as defined by [I-D.ietf-httpbis-p2-semantics], Section 249 8.2.1. Note, however, that use of the "Vary: *" header will make it 250 impossible for a proxy to cache the response. 252 2.1. Examples 254 The following examples illustrate the use of various preferences 255 defined by this specification, as well as undefined extensions for 256 strictly illustrative purposes: 258 1. Return a "202 Accepted" response for asynchronous processing if 259 the request cannot be processed within 10 seconds. An undefined 260 "priority" preference is also specified: 262 POST /some-resource HTTP/1.1 263 Host: example.org 264 Content-Type: text/plain 265 Prefer: respond-async, wait=10 266 Prefer: priority=5 268 {...} 270 2. Use lenient processing: 272 POST /some-resource HTTP/1.1 273 Host: example.org 274 Content-Type: text/plain 275 Prefer: Lenient 277 {...} 279 3. Use of an optional, undefined parameter on the return=minimal 280 preference: 282 POST /some-resource HTTP/1.1 283 Host: example.org 284 Content-Type: text/plain 285 Prefer: return=minimal; foo="some parameter" 287 {...} 289 3. The Preference-Applied Response Header Field 291 The Preference-Applied response header MAY be included within a 292 response message as an indication as to which Prefer tokens were 293 honored by the server and applied to the processing of a request. 295 ABNF: 297 Preference-Applied = "Preference-Applied" ":" 1#token 299 The syntax of the Preference-Applied header differs from that of the 300 Prefer header in that token values and parameters are not included. 302 Use of the Preference-Applied header is only necessary when it is not 303 readily and obviously apparent that a server applied a given 304 preference and such ambiguity might have an impact on the client's 305 handling of the response. For instance, when using either the 306 "return=representation" or "return=minimal" preferences, a client 307 application might not be capable of reliably determining if the 308 preference was (or was not) applied simply by examining the payload 309 of the response. In such case the Preference-Applied header field 310 can be used. 312 Request: 314 PATCH /my-document HTTP/1.1 315 Host: example.org 316 Content-Type: application/json-patch 317 Prefer: return=representation 319 [{"op": "add", "path": "/a", "value": 1}] 321 Response: 323 HTTP/1.1 200 OK 324 Content-Type: application/json 325 Preference-Applied: return=representation 326 Content-Location: /my-document 328 {"a": 1} 330 4. Preference Definitions 332 The following subsections define an initial set of preferences. 333 Additional preferences can be registered for convenience and/or to 334 promote reuse by other applications. This specification establishes 335 an IANA registry of such relation types (see Section 5.1). 337 4.1. The "respond-async" Preference 339 The "respond-async" preference indicates that the client prefers the 340 server to respond asynchronously to a response. For instance, in the 341 case when the length of time it takes to generate a response will 342 exceed some arbitrary threshold established by the server, the server 343 can honor the respond-async preference by returning a "202 Accepted" 344 response. 346 ABNF: 348 respond-async = "respond-async" 350 The key motivation for the "respond-async" preference is to 351 facilitate the operation of asynchronous request handling by allowing 352 the client to indicate to a server its capability and preference for 353 handling asynchronous responses. 355 An example request specifying the "respond-async" preference: 357 POST /collection HTTP/1.1 358 Host: example.org 359 Content-Type: text/plain 360 Prefer: respond-async 362 {Data} 364 An example asynchronous response using "202 Accepted": 366 HTTP/1.1 202 Accepted 367 Location: http://example.org/collection/123 369 While the "202 Accepted" response status is defined by 370 [I-D.ietf-httpbis-p2-semantics], little guidance is given on how and 371 when to use the response code and the process for determining the 372 subsequent final result of the operation is left entirely undefined. 373 Therefore, whether and how any given server supports asynchronous 374 responses is an implementation specific detail that is considered to 375 be out of the scope of this specification. 377 4.2. The "return=representation" and "return=minimal" Preferences 379 The "return=representation" preference indicates that the client 380 prefers that the server include an entity representing the current 381 state of the resource in the response to a successful request. 383 The "return=minimal" preference, on the other hand, indicates that 384 the client wishes the server to return only a minimal response to a 385 successful request. Typically, such responses would utilize the "204 386 No Content" status, but other codes MAY be used as appropriate, such 387 as a "200" status with a zero-length response entity. The 388 determination of what constitutes an appropriate minimal response is 389 solely at the discretion of the server. 391 ABNF: 393 return = "return" BWS "=" BWS ("representation" / "minimal") 395 When honoring the "return=representation" preference, the returned 396 representation might not be a representation of the effective request 397 URI when the request is affecting another resource. In such cases, 398 the Content-Location header can be used to identify the URI of the 399 returned representation. 401 The "return=representation" preference is intended to provide a means 402 of optimizing communication between the client and server by 403 eliminating the need for a subsequent GET request to retrieve the 404 current representation of the resource following a modification. 406 After successfully processing a modification request such as a POST 407 or PUT, a server can choose to return either an entity describing the 408 status of the operation or a representation of the modified resource 409 itself. While the selection of which type of entity to return, if 410 any at all, is solely at the discretion of the server, the 411 "return=representation" preference -- along with the "return=minimal" 412 preference defined below -- allow the server to take the client's 413 preferences into consideration while constructing the response. 415 An example request specifying the "return=representation" preference: 417 PATCH /item/123 HTTP/1.1 418 Host: example.org 419 Content-Type: text/patch 420 Prefer: return=representation 422 1c1 423 < ABCDEFGHIJKLMNOPQRSTUVWXYZ 424 --- 425 > BCDFGHJKLMNPQRSTVWXYZ 427 An example response containing the resource representation: 429 HTTP/1.1 200 OK 430 Content-Location: http://example.org/item/123 431 Content-Type: text/plain 432 ETag: "d3b07384d113edec49eaa6238ad5ff00" 434 BCDFGHJKLMNPQRSTVWXYZ 436 In contrast, the "return=minimal" preference can reduce the amount of 437 data the server is required to return to the client following a 438 request. This can be particularly useful, for instance, when 439 communicating with limited-bandwidth mobile devices or when the 440 client simply does not require any further information about the 441 result of a request beyond knowing if it was successfully processed. 443 An example request specifying the "return=minimal" preference: 445 POST /collection HTTP/1.1 446 Host: example.org 447 Content-Type: text/plain 448 Prefer: return=minimal 450 {Data} 452 An example minimal response: 454 HTTP/1.1 201 Created 455 Location: http://example.org/collection/123 457 The "return=minimal" and "return=representation" preferences are 458 mutually exclusive directives. It is anticipated that there will 459 never be a situation where it will make sense for a single request to 460 include both preferences. Any such requests will likely be the 461 result of a coding error within the client. As such, a request 462 containing both preferences can be treated as though neither were 463 specified. 465 4.3. The "wait" Preference 467 The "wait" preference can be used to establish an upper bound on the 468 length of time, in seconds, the client expects it will take the 469 server to process the request once it has been received. In the case 470 that generating a response will take longer than the time specified, 471 the server, or proxy, can choose to utilize an asynchronous 472 processing model by returning -- for example -- a "202 Accepted" 473 response. 475 ABNF: 477 wait = "wait" BWS "=" BWS delta-seconds 479 It is important to consider that HTTP messages spend some time 480 traversing the network and being processed by intermediaries. This 481 increases the length of time that a client will wait for a response 482 in addition to the time the server takes to process the request. A 483 client that has strict timing requirements can estimate these factors 484 and adjust the wait value accordingly. 486 As with other preferences, the "wait" preference could be ignored. 487 Clients can abandon requests that take longer than they are prepared 488 to wait. 490 For example, a server receiving the following request might choose to 491 respond asynchronously if processing the request will take longer 492 than 10 seconds: 494 POST /collection HTTP/1.1 495 Host: example.org 496 Content-Type: text/plain 497 Prefer: respond-async, wait=10 499 {Data} 501 4.4. The "handling=strict" and "handling=lenient" Processing 502 Preferences 504 The "handling=strict" and "handling=lenient" preferences indicate, at 505 the server's discretion, how the client wishes the server to handle 506 potential error conditions that can arise in the processing of a 507 request. For instance, if the payload of a request contains various 508 minor syntactical or semantic errors, but the server is still capable 509 of comprehending and successfully processing the request, a decision 510 must be made to either reject the request with an appropriate "4xx" 511 error response or go ahead with processing. The "handling=strict" 512 preference can be used to indicate that, while any particular error 513 may be recoverable, the client would prefer that the server reject 514 the request. The "handling=lenient" preference, on the other hand, 515 indicates that the client wishes the server to attempt to process the 516 request. 518 ABNF: 520 handling = "handling" BWS "=" BWS ("strict" / "lenient") 522 An example request specifying the "strict" preference: 524 POST /collection HTTP/1.1 525 Host: example.org 526 Content-Type: text/plain 527 Prefer: handling=strict 529 The "handling=strict" and "handling=lenient" preferences are mutually 530 exclusive directives. It is anticipated that there will never be a 531 situation where it will make sense for a single request to include 532 both preferences. Any such requests will likely be the result of a 533 coding error within the client. As such, a request containing both 534 preferences can be treated as though neither were specified. 536 5. IANA Considerations 538 The 'Prefer' and 'Preference-Applied' header fields should be added 539 to the Permanent Message Header Fields registry defined in [RFC3864] 540 (http://www.iana.org/assignments/message-headers/perm-headers.html). 542 Header field name: Prefer 543 Applicable Protocol: HTTP 544 Status: Standard 545 Author: James M Snell 546 Change controller: IETF 547 Specification document: this specification, Section 2 549 Header field name: Preference-Applied 550 Applicable Protocol: HTTP 551 Status: Standard 552 Author: James M Snell 553 Change controller: IETF 554 Specification document: this specification, Section 3 556 5.1. The Registry of Preferences 558 IANA is asked to create a new registry, "HTTP Preferences", under the 559 Hypertext Transfer Protocol (HTTP) Parameters group. New 560 registrations will use the Specification Required policy [RFC5226]. 561 The requirements for registered preferences are described in 562 Section 4. 564 Registration requests consist of the completed registration template 565 below, typically published in the required specification. However, 566 to allow for the allocation of values prior to publication, the 567 Designated Expert can approve registration based on a separately 568 submitted template once they are satisfied that a specification will 569 be published. Preferences can be registered by third parties if the 570 Designated Expert determines that an unregistered preference is 571 widely deployed and not likely to be registered in a timely manner. 573 The registration template is: 575 o Preference: (A value for the Prefer request header field that 576 conforms to the syntax rule given in Section 2) 577 o Value: (An enumeration or description of possible values for the 578 preference token). 579 o Optional Parameters: (An enumeration of optional parameters, and 580 their values, associated with the the preference token). 581 o Description: 583 o Reference: 584 o Notes: [optional] 586 The "Value" and "Optional Parameters" fields MAY be omitted from the 587 registration template if the specific preference token definition 588 does not define either. 590 Registration requests should be sent to the ietf-http-wg@w3.org 591 mailing list, marked clearly in the subject line (e.g., "NEW 592 PREFERENCE - example" to register an "example" preference). Within 593 at most 14 days of the request, the Designated Expert(s) will either 594 approve or deny the registration request, communicating this decision 595 to the review list and IANA. Denials should include an explanation 596 and, if applicable, suggestions as to how to make the request 597 successful. 599 The Expert Reviewer shall ensure: 600 o That the requested preference name conforms to the token rule in 601 Section 2 and that it is not identical to any other registered 602 preference name; 603 o That any associated value, parameter names, and values conform to 604 the relevant ABNF grammar specifications in Section 2; 605 o That the name is appropriate to the specificity of the preference; 606 i.e., if the semantics are highly specific to a particular 607 application, the name should reflect that, so that more general 608 names remain available for less specific use. 609 o That requested preferences do not constrain servers, clients or 610 any intermediaries to any behavior required for successful 611 processing; and 612 o That the specification document defining the preference includes a 613 proper and complete discussion of any security considerations 614 relevant to the use of the preference. 616 5.2. Initial Registry Contents 618 The Preferences Registry's initial contents are: 620 o Preference: respond-async 621 o Description: Indicates that the client prefers the server to 622 respond asynchronously to a request. 623 o Reference: [this specification], Section 4.1 625 o Preference: return 626 o Value: One of either "minimal" or "representation" 627 o Description: When value is "minimal", indicates that the client 628 prefers the server return a minimal response to a request. When 629 value is "representation", indicates that the client prefers the 630 server to include a representation of the current state of the 631 resource in response to a request. 632 o Reference: [this specification], Section 4.2 634 o Preference: wait 635 o Description: Indicates an upper bound to the length of time the 636 client expects it will take the server to process the request once 637 it has been received. 638 o Reference: [this specification], Section 4.3 640 o Preference: handling 641 o Value: One of either "strict" or "lenient" 642 o Description: When value is "strict", indicates that the client 643 wishes the server to apply strict validation and error handling to 644 the processing of a request. When value is "lenient", indicates 645 that the client wishes the server to apply lenient validation and 646 error handling to the processing of the request. 647 o Reference: [this specification], Section 4.4 649 6. Security Considerations 651 Specific preferences requested by a client can introduce security 652 considerations and concerns beyond those discussed within HTTP/1.1 653 [I-D.ietf-httpbis-p1-messaging] and it's additional associated 654 specification documents. Implementers need to refer to the 655 specifications and descriptions of each preference to determine the 656 security considerations relevant to each. 658 A server could incur greater costs in attempting to comply with a 659 particular preference (for instance, the cost of providing a 660 representation in a response that would not ordinarily contain one; 661 or the commitment of resources necessary to track state for an 662 asynchronous response). Unconditional compliance from a server could 663 allow the use of preferences for denial of service. A server can 664 ignore an expressed preference to avoid expending resources that it 665 does not wish to commit. 667 7. References 669 7.1. Normative References 671 [I-D.ietf-httpbis-p1-messaging] 672 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 673 (HTTP/1.1): Message Syntax and Routing", 674 draft-ietf-httpbis-p1-messaging-21 (work in progress), 675 October 2012. 677 [I-D.ietf-httpbis-p2-semantics] 678 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 679 (HTTP/1.1): Semantics and Content", 680 draft-ietf-httpbis-p2-semantics-21 (work in progress), 681 October 2012. 683 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 684 3", BCP 9, RFC 2026, October 1996. 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 690 Procedures for Message Header Fields", BCP 90, RFC 3864, 691 September 2004. 693 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 694 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 695 May 2008. 697 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 698 Specifications: ABNF", STD 68, RFC 5234, January 2008. 700 7.2. Informative References 702 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 703 Protocol", RFC 5023, October 2007. 705 Author's Address 707 James M Snell 709 Email: jasnell@gmail.com