idnits 2.17.1 draft-dusseault-http-patch-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (November 25, 2009) is 5267 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Dusseault 3 Internet-Draft Linden Lab 4 Intended status: Standards Track J. Snell 5 Expires: May 29, 2010 November 25, 2009 7 PATCH Method for HTTP 8 draft-dusseault-http-patch-16 10 Abstract 12 Several applications extending the Hypertext Transfer Protocol (HTTP) 13 require a feature to do partial resource modification. The existing 14 HTTP PUT method only allows a complete replacement of a document. 15 This proposal adds a new HTTP method, PATCH, to modify an existing 16 HTTP resource. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 29, 2010. 41 Copyright Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. The PATCH Method . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. A simple PATCH example . . . . . . . . . . . . . . . . . . 5 61 2.2. Error handling . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Advertising Support in OPTIONS . . . . . . . . . . . . . . . . 7 63 3.1. The Accept-Patch Header . . . . . . . . . . . . . . . . . 7 64 3.2. Example OPTIONS Request and Response . . . . . . . . . . . 7 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. The 'Accept-Patch' Response Header . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 72 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 10 73 B.1. Changes from -00 . . . . . . . . . . . . . . . . . . . . . 10 74 B.2. Changes from -01 . . . . . . . . . . . . . . . . . . . . . 10 75 B.3. Changes from -02 . . . . . . . . . . . . . . . . . . . . . 10 76 B.4. Changes from -03 . . . . . . . . . . . . . . . . . . . . . 11 77 B.5. Changes from -04 . . . . . . . . . . . . . . . . . . . . . 11 78 B.6. Changes from -05 . . . . . . . . . . . . . . . . . . . . . 11 79 B.7. Changes from -06 . . . . . . . . . . . . . . . . . . . . . 11 80 B.8. Changes from -07 . . . . . . . . . . . . . . . . . . . . . 11 81 B.9. Changes from -08 . . . . . . . . . . . . . . . . . . . . . 12 82 B.10. Changes from -09 . . . . . . . . . . . . . . . . . . . . . 12 83 B.11. Changes from -10 . . . . . . . . . . . . . . . . . . . . . 12 84 B.12. Changes from -11 . . . . . . . . . . . . . . . . . . . . . 13 85 B.13. Changes from -12 . . . . . . . . . . . . . . . . . . . . . 13 86 B.14. Changes from -13 . . . . . . . . . . . . . . . . . . . . . 13 87 B.15. Changes from -14 . . . . . . . . . . . . . . . . . . . . . 13 88 B.16. Changes from -15 . . . . . . . . . . . . . . . . . . . . . 14 89 Appendix C. Notes to RFC Editor . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 This specification defines the new HTTP/1.1 [RFC2616] method PATCH 95 that is used to apply partial modifications to a resource. 97 A new method is necessary to improve interoperability and prevent 98 errors. The PUT method is already defined to overwrite a resource 99 with a complete new body, and can not be reused to do partial 100 changes. Otherwise, proxies and caches and even clients and servers 101 may get confused as to the result of the operation. POST is already 102 used but without broad interoperability (for one, there is no 103 standard way to discover patch format support). PATCH was mentioned 104 in earlier HTTP specifications, but not completely defined. 106 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 108 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 110 Furthermore, this document uses the ABNF syntax defined in Section 111 2.1 of [RFC2616]. 113 2. The PATCH Method 115 The PATCH method requests that a set of changes described in the 116 request entity be applied to the resource identified by the Request- 117 URI. The set of changes is represented in a format called a "patch 118 document" identified by a media type. If the Request-URI does not 119 point to an existing resource, the server MAY create a new resource, 120 depending on the patch document type (whether it can logically modify 121 a null resource) and permissions etc. 123 The difference between the PUT and PATCH requests is reflected in the 124 way the server processes the enclosed entity to modify the resource 125 identified by the Request-URI. In a PUT request, the enclosed entity 126 is considered to be a modified version of the resource stored on the 127 origin server and the client is requesting that the stored version be 128 replaced. With PATCH, however, the enclosed entity contains a set of 129 instructions describing how a resource currently residing on the 130 origin server should be modified to produce a new version. The PATCH 131 method affects the resource identified by the Request-URI, and also 132 MAY have side effects on other resources; i.e., new resources may be 133 created, or existing ones modified, by the application of a PATCH. 135 PATCH is neither safe or idempotent as defined by [RFC2616], Section 136 9.1. 138 A PATCH request can be issued in such a way as to be idempotent, 139 which also helps prevent bad outcomes from collisions between two 140 PATCH requests on the same resource in a similar timeframe. 141 Collisions from multiple PATCH requests may be more dangerous than 142 PUT collisions, because some patch formats need to operate from a 143 known base point or else corrupt the resource. Clients using this 144 kind of patch application SHOULD acquire a strong ETag [RFC2616] for 145 the resource to be modified, and use that ETag in the If-Match header 146 on the PATCH request to verify that the resource is still unchanged. 147 If a strong ETag is not available for a given resource, the client 148 can use If-Unmodified-Since as a less-reliable safeguard. 150 There are also cases where patch formats do not need to operate from 151 a known base-point (e.g. appending text lines to log files, or non- 152 colliding rows to database tables), in which case the same care in 153 client requests is not needed. 155 The server MUST apply the entire set of changes atomically and never 156 provide (e.g. in response to a GET during this operation) a 157 partially-modified representation. If the entire patch document 158 cannot be successfully applied then the server MUST NOT apply any of 159 the changes. The determination of what constitutes a successful 160 PATCH can vary depending on the patch document and the type of 161 resource(s) being modified. For example, the common 'diff' utility 162 can generate a patch document that applies to multiple files in a 163 directory hierarchy. The atomicity requirement holds for all 164 directly affected files. See Error Handling in Section 2.2 for 165 details on status codes and possible error conditions. 167 If the request passes through a cache and the Request-URI identifies 168 one or more currently cached entities, those entries SHOULD be 169 treated as stale. A response to this method is only cacheable if it 170 contains explicit freshness information (such as an Expires header or 171 "Cache-Control: max-age" directive) as well as the Content-Location 172 header matching the request-URI, indicating that the PATCH response 173 body is a resource representation. A cached PATCH response can only 174 be used to respond to subsequent GET and HEAD requests; it MUST NOT 175 be used to respond to other methods (in particular, PATCH). 177 Note that entity-headers contained in the request apply only to the 178 contained patch document and MUST NOT be applied to the resource 179 being modified. Thus, a Content-Language header could be present on 180 the request but it would only mean (for whatever that's worth) that 181 the patch document had a language. Servers SHOULD NOT store such 182 headers except as trace information, and SHOULD NOT use such header 183 values the same way they might be used on PUT requests. Therefore, 184 this document does not specify a way to modify a document's Content- 185 Type or Content-Language value through headers, though a mechanism 186 could well be designed to achieve this goal through a patch document. 188 There is no guarantee that a resource can be modified with PATCH. 189 Further, it is expected that different patch document formats will be 190 appropriate for different types of resources and that no single 191 format will be appropriate for all types of resources. Therefore, 192 there is no single default patch document format that implementations 193 are required to support. Servers MUST ensure that a received patch 194 document is appropriate for the type of resource identified by the 195 Request-URI. 197 Clients need to choose when to use PATCH rather than PUT. For 198 example, if the patch document size is larger than the size of the 199 new resource data that would be used in a PUT, then it might make 200 sense to use PUT instead of PATCH. A comparison to POST is even more 201 difficult, because POST is used in widely varying ways and can 202 encompass PUT and PATCH-like operations if the server chooses. If 203 the operation does not modify the resource identified by the Request- 204 URI in a predictable way, POST should be considered instead of PATCH 205 or PUT. 207 2.1. A simple PATCH example 209 PATCH /file.txt HTTP/1.1 210 Host: www.example.com 211 Content-Type: application/example 212 If-Match: "e0023aa4e" 213 Content-Length: 100 215 [description of changes] 217 This example illustrates use of a hypothetical patch document on an 218 existing resource. The 204 response code is used because the 219 response does not have a body (a response with the 200 code would 220 have a body) but other success codes can be used if appropriate. 222 Successful PATCH response to existing text file 224 HTTP/1.1 204 No Content 225 Content-Location: /file.txt 226 ETag: "e0023aa4f" 228 2.2. Error handling 230 There are several known conditions under which a PATCH request can 231 fail. 233 Malformed patch document: When the server determines that the patch 234 document provided by the client is not properly formatted, it 235 SHOULD return a 400 (Bad Request) response. The definition of 236 badly formatted depends on the patch document chosen. 237 Unsupported patch document: Can be specified using a 415 238 (Unsupported Media Type) when the client sends a patch document 239 format that the server does not support for the resource 240 identified by the Request-URI. Such a response SHOULD include an 241 Accept-Patch response header as described in Section 3.1 to notify 242 the client what patch document media types are supported. 243 Unprocessable request: Can be specified with a 422 (Unprocessable 244 Entity) ([RFC4918], Section 11.2) when the server understands the 245 patch document and the syntax of the patch document appears valid, 246 but the server is incapable of processing the request. This might 247 include attempts to modify a resource in a way that would cause 248 the resource to become invalid: for instance, a modification to a 249 well-formed XML document that would cause it to no longer be well- 250 formed. There may also be more specific errors like "Conflicting 251 State" that could be signaled with this status code, but the more 252 specific error would generally be more helpful. 253 Resource Not Found: Can be specified with a 404 (Not Found) status 254 code, when the client attempted to apply a patch document to a 255 non-existent resource, but the patch document chosen cannot be 256 applied to a non-existent resource. 257 Conflicting State: Can be specified with a 409 (Conflict) when the 258 request cannot be applied given the state of the resource. For 259 example, if the client attempted to apply a structural 260 modification and the structures assumed to exist did not exist 261 (with XML, a patch might specify changing element 'foo' to element 262 'bar' but element 'foo' might not exist). 263 Conflicting modification: When a client uses either the If-Match or 264 If-Unmodified-Since header to define a precondition, and that 265 precondition failed, then the 412 (Precondition Failed) error is 266 most helpful to the client. However, that response makes no sense 267 if there was no precondition on the request. In cases when the 268 server detects a possible conflicting modification and no 269 precondition was defined in the request, the server can return a 270 409 (Conflict) response. 271 Concurrent modification: Some applications of PATCH might require 272 the server to process requests in the order in which they are 273 received. If a server is operating under those restrictions, and 274 it receives concurrent requests to modify the same resource, but 275 is unable to queue those requests, the server can usefully 276 indicate this error by using a 409 (Conflict) response. 278 Note that the 409 Conflict response gives reasonably consistent 279 information to clients. Depending on the application and the nature 280 of the patch format, the client might be able to reissue the request 281 as is (e.g. an instruction to append a line to a log file), or it 282 might have to retrieve the resource content to recalculate a patch, 283 or it might have to fail the operation. 285 Other HTTP status codes can also be used under the appropriate 286 circumstances. 288 The entity body of error responses SHOULD contain enough information 289 to communicate the nature of the error to the client. The content- 290 type of the response entity can vary across implementations. 292 3. Advertising Support in OPTIONS 294 A server can advertise its support for the PATCH method by adding it 295 to the listing of allowed methods in the "Allow" OPTIONS response 296 header defined in HTTP/1.1. The PATCH method MAY appear in the 297 "Allow" header even if the Accept-Patch header is absent, in which 298 case the list of allowed patch documents is not advertised. 300 3.1. The Accept-Patch Header 302 This specification introduces a new response header "Accept-Patch" 303 used to specify the patch document formats accepted by the server. 304 "Accept-Patch" SHOULD appear in the OPTIONS response for any resource 305 that supports the use of the PATCH method. The presence of the 306 "Accept-Patch" header in response to any method is an implicit 307 indication that PATCH is allowed on the resource identified by the 308 Request-URI. The presence of a specific patch document format in 309 this header indicates that specific format is allowed on the resource 310 identified by the Request-URI. 312 Accept-Patch = "Accept-Patch" ":" 1#media-type 314 The Accept-Patch header specifies a comma separated listing of media- 315 types as defined by [RFC2616], Section 3.7. 317 3.2. Example OPTIONS Request and Response 319 [request] 321 OPTIONS /example/buddies.xml HTTP/1.1 322 Host: www.example.com 324 [response] 326 HTTP/1.1 200 OK 327 Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH 328 Accept-Patch: application/example, text/example 330 The examples show a server that supports PATCH generally using two 331 hypothetical patch document formats. 333 4. IANA Considerations 335 4.1. The 'Accept-Patch' Response Header 337 The 'Accept-Patch' response header should be added to the permanent 338 registry (see [RFC3864]). 340 Header field name: Accept-Patch 341 Applicable Protocol: HTTP 342 Author/Change controller: IETF 343 Specification document: this specification 345 5. Security Considerations 347 The security considerations for PATCH are nearly identical to the 348 security considerations for PUT ([RFC2616], Section 9.6). These 349 include authorizing requests (possibly through access control and/or 350 authentication) and ensuring that data is not corrupted through 351 transport errors or through accidental overwrites. Whatever 352 mechanisms are used for PUT can be used for PATCH as well. The 353 following considerations apply specially to PATCH. 355 A document that is patched might be more likely to be corrupted than 356 a document that is overridden in entirety, but that concern can be 357 addressed through the use of mechanisms such as conditional requests 358 using ETags and the If-Match request header as described in 359 Section 2. If a PATCH request fails, the client can issue a GET 360 request to the resource to see what state it is in. In some cases, 361 the client might be able to check the contents of the resource to see 362 if the PATCH request can be resent, but in other cases the attempt 363 will just fail and/or a user will have to verify intent. In the case 364 of a failure of the underlying transport channel, where a PATCH 365 response is not received before the channel fails or some other 366 timeout happens, the client might have to issue a GET request to see 367 whether the request was applied. The client might want to ensure 368 that the GET request bypasses caches using mechanisms described in 369 HTTP specifications (see for example Section 13.1.6 of [RFC2616]). 371 Sometimes an HTTP intermediary might try to detect viruses being sent 372 via HTTP by checking the body of the PUT/POST request or GET 373 response. The PATCH method complicates such watch-keeping because 374 neither the source document nor the patch document might be a virus, 375 yet the result could be. This security consideration is not 376 materially different from those already introduced by byte-range 377 downloads, downloading patch documents, uploading zipped (compressed) 378 files and so on. 380 Individual patch documents will have their own specific security 381 considerations that will likely vary depending on the types of 382 resources being patched. The considerations for patched binary 383 resources, for instance, will be different than those for patched XML 384 documents. Servers MUST take adequate precautions to ensure that 385 malicious clients cannot consume excessive server resources (e.g., 386 CPU, disk I/O) through the client's use of PATCH. 388 6. References 390 6.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 396 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 397 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 399 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 400 Procedures for Message Header Fields", BCP 90, RFC 3864, 401 September 2004. 403 6.2. Informative References 405 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 406 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 408 Appendix A. Acknowledgements 410 PATCH is not a new concept, it first appeared in HTTP in drafts of 411 version 1.1 written by Roy Fielding and Henrik Frystyk and also 412 appears in Section 19.6.1.1 of RFC 2068. 414 Thanks to Adam Roach, Chris Sharp, Julian Reschke, Geoff Clemm, Scott 415 Lawrence, Jeffrey Mogul, Roy Fielding, Greg Stein, Jim Luther, Alex 416 Rousskov, Jamie Lokier, Joe Hildebrand, Mark Nottingham, Michael 417 Balloni, Cyrus Daboo, Brian Carpenter, John Klensin, Eliot Lear and 418 SM for review and advice on this document. 420 Appendix B. Changes 422 B.1. Changes from -00 424 OPTIONS support: removed "Patch" header definition and used Allow and 425 new "Accept-Patch" headers instead. 427 Supported delta encodings: removed vcdiff and diffe as these do not 428 have defined MIME types and did not seem to be strongly desired. 430 PATCH method definition: Clarified cache behavior. 432 B.2. Changes from -01 434 Removed references to XCAP - not yet a RFC. 436 Fixed use of MIME types (this "fix" now obsolete) 438 Explained how to use MOVE or COPY in conjunction with PATCH, to 439 create a new resource based on an existing resource in a different 440 location. 442 B.3. Changes from -02 444 Clarified that MOVE and COPY are really independent of PATCH. 446 Clarified when an ETag must change, and when Last-Modified must be 447 used. 449 Clarified what server should do if both Content-Type and IM headers 450 appear in PATCH request. 452 Filled in missing reference to DeltaV and ACL RFCs. 454 Stopped using 501 Unsupported for unsupported delta encodings. 456 Clarified what a static resource is. 458 Refixed use of MIME types for patch formats. 460 Limited the scope of some restrictions to apply only to usage of 461 required diff format. 463 B.4. Changes from -03 465 Various typographical, terminology consistency, and other minor 466 clarifications or fixes. 468 B.5. Changes from -04 470 Moved paragraphs on ACL and RFC3229 interoperability to new section. 472 Added security considerations. 474 Added IANA considerations, registration of new namespace, and 475 discontinued use of "DAV:" namespace for new elements. 477 Added example of error response. 479 B.6. Changes from -05 481 Due to various concerns it didn't seem likely the application/gdiff 482 registration could go through so switching to vcdiff as required diff 483 format, and to RFC3229's approach to specifying diff formats, 484 including use of the IM header. 486 Clarified what header server MUST use to return MD5 hash. 488 Reverted to using 501 Unsupported for unsupported delta encodings. 490 B.7. Changes from -06 492 The reliance on RFC 3229 defined patch documents has been factored 493 out in favor of delta encodings identified by MIME media type. 495 The required use of DeltaV-based error reporting has been removed in 496 favor of using basic HTTP status codes to report error conditions. 498 The Accept-Patch response header has been redefined as a listing of 499 media-ranges, similar to the Accept request header. 501 Added James Snell as a co-author. 503 B.8. Changes from -07 505 Terminology change from "delta encoding" to "patch document" 507 Added clarification on the safety and idempotency of PATCH 509 Updated the caching rules of PATCH responses 510 200 responses MUST include a representation of the modified resource. 511 204 responses are used to indicate successful response without 512 returning a representation. 514 Suggest using 422 Unprocessable Entity to indicate that a properly 515 formatted patch document cannot be processed 517 Clarify the use of 412 and 409 to indicate concurrent and conflicting 518 resource modifications. 520 Added registration for the Accept-Patch header. 522 Relaxed the requirements for the use of If-Match and If-Unmodified- 523 Since. 525 Add language that clarifies the difference between PUT and PATCH. 527 Add language that clarifies the issues with PATCH and Content 528 Negotiation. 530 Use of Accept-Patch on any response implies that PATCH is supported. 532 Add language advising caution when pipelining PATCH requests. 534 B.9. Changes from -08 536 Addition of the 209 Content Returned status code 538 Addition of the Prefer header field mechanism 540 Removed the paragraph discussing the use of 200+Content-Location. 541 This is replaced by the 209 Content Returned status code. 543 B.10. Changes from -09 545 Move the prefer header to a separate document 547 Restructure the document sections. 549 B.11. Changes from -10 551 Remove paragraph about pipelined requests. This is covered 552 adequately by RFC2616. 554 Remove paragraph about content negotiation. This is covered 555 adequately by RFC2616. 557 Explicitly indicate that PATCH can be used to create new resources. 559 Remove recommendation for servers to provide strong etags. This is 560 recommendation is implied and does not need to be explicitly. 562 Change Allow-Patch to a listing of media-type and not media-range. 564 B.12. Changes from -11 566 Fix section links. 568 State that this uses RFC2616-style ABNF. 570 Fix grammar for Accept-Patch. 572 Remove requirements for handling entity-headers on PATCH and replace 573 with general discussion of issues and consequences of having no 574 handling requirements. 576 Update Security Considerations to make it clear what security 577 considerations for PUT are, for comparison. 579 B.13. Changes from -12 581 Remove status 209 again. 583 Add security consideration about using too much server resources. 585 Remove Content-MD5 from example. 587 B.14. Changes from -13 589 Remove '*' value from Accept-Patch again. 591 Allow caching but only if context is clear. 593 Clarify how some patch formats might allow creating a new document. 595 Add comparison of PATCH to POST 597 B.15. Changes from -14 599 Clarified that Accept-Patch header SHOULD appear in OPTIONS response 600 -- it is not absolutely required 602 Clarified how server can indicate that a PATCH response body is 603 cachable as a resource representation. 605 Removed suggestion that PATCH side-effects might be specified in the 606 patch document specification -- this implied that side-effects could 607 exclusively be determined that way, but in fact side-effects are 608 often determined by the server unilaterally. 610 B.16. Changes from -15 612 Clarifications on how conflicting PATCH requests can be avoided, and 613 why not all use cases necessarily involve conflict 615 Added Content-Location to example response, so the ETag would be 616 legit 618 Expanded security considerations on avoiding collisions, recovering 619 from possible (unknown) collisions 621 Very slight reordering of paragraphs in section 2, for better flow 623 Clarified that the concurrent-modification status response is 624 optional for servers, and explained what clients can do with that 625 response 627 Updated text describing conflicting modifications: when 412 is used, 628 vs 409 630 Appendix C. Notes to RFC Editor 632 The RFC Editor should remove this section and the Changes section. 634 Authors' Addresses 636 Lisa Dusseault 637 Linden Lab 638 945 Battery Street 639 San Francisco, CA 94111 640 USA 642 Email: lisa.dusseault@gmail.com 644 James M. Snell 646 Email: jasnell@gmail.com 647 URI: http://www.snellspace.com