idnits 2.17.1 draft-ietf-httpbis-bcp56bis-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC3205, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 12, 2017) is 2327 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 787 -- Looks like a reference, but probably isn't: '2' on line 789 -- Looks like a reference, but probably isn't: '3' on line 791 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Nottingham 3 Internet-Draft December 12, 2017 4 Obsoletes: 3205 (if approved) 5 Intended status: Best Current Practice 6 Expires: June 15, 2018 8 On the use of HTTP as a Substrate 9 draft-ietf-httpbis-bcp56bis-00 11 Abstract 13 HTTP is often used as a substrate for other application protocols. 14 This document specifies best practices for these protocols' use of 15 HTTP. 17 Note to Readers 19 Discussion of this draft takes place on the HTTP working group 20 mailing list (ietf-http-wg@w3.org), which is archived at 21 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 23 Working Group information can be found at http://httpwg.github.io/ 24 [2]; source code and issues list for this draft can be found at 25 https://github.com/httpwg/http-extensions/labels/bcp56bis [3]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 15, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 63 2. Is HTTP Being Used? . . . . . . . . . . . . . . . . . . . . . 4 64 3. What's Important About HTTP . . . . . . . . . . . . . . . . . 5 65 3.1. Generic Semantics . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Getting Value from HTTP . . . . . . . . . . . . . . . . . 6 68 4. Best Practices for Using HTTP . . . . . . . . . . . . . . . . 7 69 4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 7 70 4.2. Defining HTTP Resources . . . . . . . . . . . . . . . . . 8 71 4.3. HTTP URLs . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3.1. Initial URL Discovery . . . . . . . . . . . . . . . . 9 73 4.3.2. URL Schemes . . . . . . . . . . . . . . . . . . . . . 9 74 4.3.3. Transport Ports . . . . . . . . . . . . . . . . . . . 10 75 4.4. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 11 76 4.5. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 11 77 4.6. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 12 78 4.7. Defining Message Payloads . . . . . . . . . . . . . . . . 13 79 4.8. Ensuring Browser Interoperability . . . . . . . . . . . . 13 80 4.9. Access Control . . . . . . . . . . . . . . . . . . . . . 13 81 4.9.1. Authentication and Application State . . . . . . . . 13 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 86 7.2. Informative References . . . . . . . . . . . . . . . . . 15 87 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 Appendix A. Changes from RFC3205 . . . . . . . . . . . . . . . . 17 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 HTTP [RFC7230] is often used as a substrate for other application 94 protocols. This is done for a variety of reasons, including: 96 o familiarity by implementers, specifiers, administrators, 97 developers and users, 99 o availability of a variety of client, server and proxy 100 implementations, 102 o ease of use, 104 o ubiquity of Web browsers, 106 o reuse of existing mechanisms like authentication and encryption, 108 o presence of HTTP servers and clients in target deployments, and 110 o its ability to traverse firewalls. 112 The Internet community has a long tradition of protocol reuse, dating 113 back to the use of Telnet [RFC0854] as a substrate for FTP [RFC0959] 114 and SMTP [RFC2821]. However, layering new protocols over HTTP brings 115 its own set of issues: 117 o Should an application using HTTP define a new URL scheme? Use new 118 ports? 120 o Should it use standard HTTP methods and status codes, or define 121 new ones? 123 o How can the maximum value be extracted from the use of HTTP? 125 o How does it coexist with other uses of HTTP - especially Web 126 browsing? 128 o How can interoperability problems and "protocol dead ends" be 129 avoided? 131 This document contains best current practices regarding the use of 132 HTTP by applications other than Web browsing. Section 2 defines what 133 applications it applies to; Section 3 surveys the properties of HTTP 134 that are important to preserve, and Section 4 conveys best practices 135 for those applications that do use HTTP. 137 It is written primarily to guide IETF efforts to define application 138 protocols using HTTP for deployment on the Internet, but might be 139 applicable in other situations. Note that the requirements herein do 140 not necessarily apply to the development of generic HTTP extensions. 142 1.1. Notational Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 2. Is HTTP Being Used? 152 Different applications have different goals when using HTTP. In this 153 document, we say an application is _using HTTP_ when any of the 154 following conditions are true: 156 o The transport port in use is 80 or 443, 158 o The URL scheme "http" or "https" is used, 160 o The ALPN protocol ID [RFC7301] "http/1.1", "h2" or "h2c" is used, 161 or 163 o The message formats described in [RFC7230] and/or [RFC7540] are 164 used in conjunction with the IANA registries defined for HTTP. 166 When an application is using HTTP, all of the requirements of the 167 HTTP protocol suite (including but not limited to [RFC7230], 168 [RFC7231], [RFC7232], [RFC7233], [RFC7234], [RFC7235] and [RFC7540]) 169 are in force. 171 An application might not be _using HTTP_ according to this 172 definition, but still relying upon the HTTP specifications in some 173 manner. For example, an application might wish to avoid re- 174 specifying parts of the message format, but change others; or, it 175 might want to use a different set of methods. 177 Such applications are referred to as _protocols based upon HTTP_ in 178 this document. These have more freedom to modify protocol operation, 179 but are also likely to lose at least a portion of the benefits 180 outlined above, as most HTTP implementations won't be easily 181 adaptable to these changes, and as the protocol diverges from HTTP, 182 the benefit of mindshare will be lost. 184 Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes, 185 transport ports, ALPN protocol IDs or IANA registries; rather, they 186 are encouraged to establish their own. 188 3. What's Important About HTTP 190 There are many ways that HTTP applications are defined and deployed, 191 and sometimes they are brought to the IETF for standardisation. In 192 that process, what might be workable for deployment in a limited 193 fashion isn't appropriate for standardisation and the corresponding 194 broader deployment. 196 This section examines the facets of the protocol that are important 197 to preserve in these situations. 199 3.1. Generic Semantics 201 When writing an application's specification, it's often tempting to 202 specify exactly how HTTP is to be implemented, supported and used. 204 However, this can easily lead to an unintended profile of HTTP's 205 behaviour. For example, it's common to see specifications with 206 language like this: 208 A `200 OK` response means that the widget has successfully been updated. 210 This sort of specification is bad practice, because it is adding new 211 semantics to HTTP's status codes and methods, respectively; a 212 recipient - whether it's an origin server, client library, 213 intermediary or cache - now has to know these extra semantics to 214 understand the message. 216 Some applications even require specific behaviours, such as: 218 A `POST` request MUST result in a `201 Created` response. 220 This forms an expectation in the client that the response will always 221 be "201 Created", when in fact there are a number of reasons why the 222 status code might differ in a real deployment. If the client does 223 not anticipate this, the application's deployment is brittle. 225 Much of the value of HTTP is in its _generic semantics_ - that is, 226 the protocol elements defined by HTTP are potentially applicable to 227 every resource, not specific to a particular context. Application- 228 specific semantics are expressed in the payload; mostly, in the body, 229 but also in header fields. 231 This allows a HTTP message to be examined by generic HTTP software 232 (e.g., HTTP servers, intermediaries, client implementatiions), and 233 its handling to be correctly determined. It also allows people to 234 leverage their knowledge of HTTP semantics without special-casing 235 them for a particular application. 237 Therefore, applications that use HTTP MUST NOT re-define, refine or 238 overlay the semantics of defined protocol elements. Instead, they 239 SHOULD focus their specifications on protocol elements that are 240 specific to them; namely their HTTP resources. 242 See Section 4.2 for details. 244 3.2. Links 246 Another common practice is assuming that the HTTP server's name space 247 (or a portion thereof) is exclusively for the use of a single 248 application. This effectively overlays special, application-specific 249 semantics onto that space, precludes other applications from using 250 it. 252 As explained in [RFC7320], such "squatting" on a part of the URL 253 space by a standard usurps the server's authority over its own 254 resources, can cause deployment issues, and is therefore bad practice 255 in standards. 257 Instead of statically defining URL paths, it is RECOMMENDED that 258 applications using HTTP define links in payloads, to allow 259 flexibility in deployment. 261 Using runtime links in this fashion has a number of other benefits. 262 For example, navigating with a link allows a request to be routed to 263 a different server without the overhead of a redirection, thereby 264 supporting deployment across machines well. It becomes possible to 265 "mix" different applications on the same server, and offers a natural 266 path for extensibility, versioning and capability management. 268 3.3. Getting Value from HTTP 270 The simplest possible use of HTTP is to POST data to a single URL, 271 thereby effectively tunnelling through the protocol. 273 This "RPC" style of communication does get some benefit from using 274 HTTP - namely, message framing and the availability of 275 implementations - but fails to realise many others: 277 o Caching for server scalability, latency and bandwidth reduction, 278 and reliability; 280 o Authentication and access control; 282 o Automatic redirection; 284 o Partial content to selectively request part of a response; 285 o Natural support for extensions and versioning through protocol 286 extension; and 288 o The ability to interact with the application easily using a Web 289 browser. 291 Using such a high-level protocol to tunnel simple semantics has 292 downsides too; because of its more advanced capabilities, breadth of 293 deployment and age, HTTP's complexity can cause interoperability 294 problems that could be avoided by using a simpler substrate (e.g., 295 WebSockets [RFC6455], if browser support is necessary, or TCP 296 [RFC0793] if not), or making the application be _based upon HTTP_, 297 instead of using it (as defined in Section 2). 299 Applications that use HTTP are encouraged to accommodate the various 300 features that the protocol offers, so that their users receive the 301 maximum benefit from it. This document does not require specific 302 features to be used, since the appropriate design tradeoffs are 303 highly specific to a given situation. However, following the 304 practices in Section 4 will help make them available. 306 4. Best Practices for Using HTTP 308 This section contains best practices regarding the use of HTTP by 309 applications, including practices for specific HTTP protocol 310 elements. 312 4.1. Specifying the Use of HTTP 314 When specifying the use of HTTP, an application SHOULD use [RFC7230] 315 as the primary reference; it is not necessary to reference all of the 316 specifications in the HTTP suite unless there are specific reasons to 317 do so (e.g., a particular feature is called out). 319 Applications using HTTP MAY specify a minimum version to be supported 320 (HTTP/1.1 is suggested), and MUST NOT specify a maximum version. 322 Likewise, applications need not specify what HTTP mechanisms - such 323 as redirection, caching, authentication, proxy authentication, and so 324 on - are to be supported. Full featured support for HTTP SHOULD be 325 taken for granted in servers and clients, and the application's 326 function SHOULD degrade gracefully if they are not (although this 327 might be achieved by informing the user that their task cannot be 328 completed). 330 For example, an application can specify that it uses HTTP like this: 332 Foo Application uses HTTP {{RFC7230}}. Implementations MUST support 333 HTTP/1.1, and MAY support later versions. Support for common HTTP 334 mechanisms such as redirection and caching are assumed. 336 4.2. Defining HTTP Resources 338 HTTP Applications SHOULD focus on defining the following application- 339 specific protocol elements: 341 o Media types [RFC6838], often based upon a format convention such 342 as JSON [RFC7159], 344 o HTTP header fields, as per Section 4.6, and 346 o The behaviour of resources, as identified by link relations 347 [RFC5988]. 349 By composing these protocol elements, an application can define a set 350 of resources, identified by link relations, that implement specified 351 behaviours, including: 353 o Retrieval of their state using GET, in one or more formats 354 identified by media type; 356 o Resource creation or update using POST or PUT, with an 357 appropriately identified request body format; 359 o Data processing using POST and identified request and response 360 body format(s); and 362 o Resource deletion using DELETE. 364 For example, an application might specify: 366 Resources linked to with the "example-widget" link relation type are 367 Widgets. The state of a Widget can be fetched in the 368 "application/example-widget+json" format, and can be updated by PUT 369 to the same link. Widget resources can be deleted. 371 The "Example-Count" response header field on Widget representations 372 indicates how many Widgets are held by the sender. 374 The "application/example-widget+json" format is a JSON {{RFC7159}} 375 format representing the state of a Widget. It contains links to 376 related information in the link indicated by the Link header field 377 value with the "example-other-info" link relation type. 379 4.3. HTTP URLs 381 In HTTP, URLs are opaque identifiers under the control of the server. 382 As outlined in [RFC7320], standards cannot usurp this space, since it 383 might conflict with existing resources, and constrain implementation 384 and deployment. 386 In other words, applications that use HTTP MUST NOT associate 387 application semantics with specific URL paths on arbitrary servers. 388 Doing so inappropriately conflates the identity of the resource (its 389 URL) with the capabilities that resource supports, bringing about 390 many of the same interoperability problems that [RFC4367] warns of. 392 For example, specifying that a "GET to the URL /foo retrieves a bar 393 document" is bad practice. Likewise, specifying "The widget API is 394 at the path /bar" violates [RFC7320]. 396 Instead, applications that use HTTP are encouraged to ensure that 397 URLs are discovered at runtime, allowing HTTP-based services to 398 describe their own capabilities. One way to do this is to use typed 399 links [RFC5988] to convey the URIs that are in use, as well as the 400 semantics of the resources that they identify. See Section 4.2 for 401 details. 403 4.3.1. Initial URL Discovery 405 Generally, a client will begin interacting with a given application 406 server by requesting an initial document that contains information 407 about that particular deployment, potentially including links to 408 other relevant resources. 410 Applications that use HTTP SHOULD allow an arbitrary URL to be used 411 as that entry point. For example, rather than specifying "the 412 initial document is at "/foo/v1", they should allow a deployment to 413 use any URL as the entry point for the application. 415 In cases where doing so is impractical (e.g., it is not possible to 416 convey a whole URL, but only a hostname) applications that use HTTP 417 MAY define a well-known URL [RFC5785] as an entry point. 419 4.3.2. URL Schemes 421 Applications that use HTTP will typically use the "http" and/or 422 "https" URL schemes. "https" is preferred to mitigate pervasive 423 monitoring attacks [RFC7258]. 425 However, application-specific schemes can be defined as well. 427 When defining an URL scheme for an application using HTTP, there are 428 a number of tradeoffs and caveats to keep in mind: 430 o Unmodified Web browsers will not support the new scheme. While it 431 is possible to register new URL schemes with Web browsers (e.g. 432 registerProtocolHandler() in [HTML5] Section 8.7.1.3, as well as 433 several proprietary approaches), support for these mechanisms is 434 not shared by all browsers, and their capabilities can vary. 436 o Likewise, existing non-browser clients, intermediaries, servers 437 and associated software will not recognise the new scheme, and 438 might fail to operate. For example, a client library might fail 439 to dispatch the request; a cache might refuse to store the 440 response, and a proxy might fail to forward the request. 442 o Because URLs occur in and are generated in HTTP artefacts 443 commonly, often without human intervention (e.g., in the 444 "Location" header), it can be difficult to assure that the new 445 scheme is used consistently. 447 o The resources identified by the new scheme will still be available 448 with "http" and/or "https" URLs to clients. While it is possible 449 to define the relationship between these resources in the new 450 scheme's specification, existing HTTP software (such as clients, 451 caches, intermediaries and servers) will not be available, so 452 there is a danger of confusion when the "wrong" URL is used. 454 o Features that rely upon the URL's origin [RFC6454], such as the 455 Web's same-origin policy, will be impacted by a change of scheme. 457 o HTTP-specific features such as cookies [RFC6265], authentication 458 [RFC7235], caching [RFC7234], and CORS [FETCH] might or might not 459 work correctly, depending on how they are defined and implemented. 460 Generally, they are designed and implemented with an assumption 461 that the URL will always be "http" or "https". 463 o Web features that require a secure context 464 [W3C.CR-secure-contexts-20160915] will likely treat a new scheme 465 as insecure. 467 See [RFC7595] for more information about minting new URL schemes. 469 4.3.3. Transport Ports 471 Applications that use HTTP SHOULD use the default port for the URL 472 scheme in use. If it is felt that networks might need to distinguish 473 the application's traffic for operational reasons, it MAY register a 474 separate port, but be aware that this has privacy implications for 475 that protocol's users. The impact of doing so MUST be documented in 476 Security Considerations. 478 See [RFC7605] for further guidance. 480 4.4. HTTP Methods 482 Applications that use HTTP MUST confine themselves to using 483 registered HTTP methods such as GET, POST, PUT, DELETE, and PATCH. 485 New HTTP methods are rare; they are required to be registered with 486 IETF Review (see [RFC7232]), and are also required to be _generic_. 487 That means that they need to be potentially applicable to all 488 resources, not just those of one application. 490 While historically some applications (e.g., [RFC4791]) has defined 491 non-generic methods, [RFC7231] now forbids this. 493 When it is believed that a new method is required, authors are 494 encouraged to engage with the HTTP community early, and document 495 their proposal as a separate HTTP extension, rather than as part of 496 an application's specification. 498 4.5. HTTP Status Codes 500 Applications that use HTTP MUST only use registered HTTP status 501 codes. 503 As with methods, new HTTP status codes are rare, and required (by 504 [RFC7231]) to be registered with IETF review. Similarly, HTTP status 505 codes are generic; they are required (by [RFC7231]) to be potentially 506 applicable to all resources, not just to those of one application. 508 When it is believed that a new status code is required, authors are 509 encouraged to engage with the HTTP community early, and document 510 their proposal as a separate HTTP extension, rather than as part of 511 an application's specification. 513 Status codes' primary function is to convey HTTP semantics for the 514 benefit of generic HTTP software, not application-specific semantics. 515 Therefore, applications MUST NOT specify additional semantics or 516 refine existing semantics for status codes. 518 In particular, specifying that a particular status code has a 519 specific meaning in the context of an application is harmful, as 520 these are not generic semantics, since the consumer needs to be in 521 the context of the application to understand them. 523 Furthermore, applications using HTTP MUST NOT re-specify the 524 semantics of HTTP status codes, even if it is only by copying their 525 definition. They MUST NOT require specific status phrases to be 526 used; the status phrase has no function in HTTP, and is not 527 guaranteed to be preserved by implementations. 529 Typically, applications using HTTP will convey application-specific 530 information in the message body and/or HTTP header fields, not the 531 status code. 533 Specifications sometimes also create a "laundry list" of potential 534 status codes, in an effort to be helpful. The problem with doing so 535 is that such a list is never complete; for example, if a network 536 proxy is interposed, the client might encounter a "407 Proxy 537 Authentication Required" response; or, if the server is rate limiting 538 the client, it might receive a "429 Too Many Requests" response. 540 Since the list of HTTP status codes can be added to, it's safer to 541 refer to it directly, and point out that clients SHOULD be able to 542 handle all applicable protocol elements gracefully (i.e., falling 543 back to the generic "n00" semantics of a given status code; e.g., 544 "499" can be safely handled as "400" by clients that don't recognise 545 it). 547 4.6. HTTP Header Fields 549 Applications that use HTTP MAY define new HTTP header fields, 550 following the advice in [RFC7231], Section 8.3.1. 552 Typically, using HTTP header fields is appropriate in a few different 553 situations: 555 o Their content is useful to intermediaries (who often wish to avoid 556 parsing the body), and/or 558 o Their content is useful to generic HTTP software (e.g., clients, 559 servers), and/or 561 o It is not possible to include their content in the message body 562 (usually because a format does not allow it). 564 If none of these motivations apply, using a header field is NOT 565 RECOMMENDED. 567 New header fields MUST be registered, as per [RFC7231] and [RFC3864]. 569 It is RECOMMENDED that header field names be short (even when HTTP/2 570 header compression is in effect, there is an overhead) but 571 appropriately specific. In particular, if a header field is specific 572 to an application, an identifier for that application SHOULD form a 573 prefix to the header field name, separated by a "-". 575 The semantics of existing HTTP header fields MUST NOT be re-defined 576 without updating their registration or defining an extension to them 577 (if allowed). For example, an application using HTTP cannot specify 578 that the "Location" header has a special meaning in a certain 579 context. 581 See Section 4.9.1 for requirements regarding header fields that carry 582 application state (e.g,. Cookie). 584 4.7. Defining Message Payloads 586 4.8. Ensuring Browser Interoperability 588 4.9. Access Control 590 Modern Web browsers constrain the ability of content from one origin 591 (as defined by [RFC6454]) to access resources from another, to avoid 592 the "confused deputy" problem. As a result, applications that wish 593 to expose cross-origin data to browsers will need to implement 594 [W3C.REC-cors-20140116]. 596 4.9.1. Authentication and Application State 598 Applications that use HTTP MAY use stateful cookies [RFC6265] to 599 identify a client and/or store client-specific data to contextualise 600 requests. 602 If it is only necessary to identify clients, applications that use 603 HTTP MAY use HTTP authentication [RFC7235]; if the Basic 604 authentication scheme [RFC7617] is used, it MUST NOT be used with the 605 'http' URL scheme. 607 In either case, it is important to carefully specify the scoping and 608 use of these mechanisms; if they expose sensitive data or 609 capabilities (e.g., by acting as an ambient authority), exploits are 610 possible. Mitigations include using a request-specific token to 611 assure the intent of the client. 613 5. IANA Considerations 615 This document has no requirements for IANA. 617 6. Security Considerations 619 Section 4.9.1 discusses the impact of using stateful mechanisms in 620 the protocol as ambient authority, and suggests a mitigation. 622 Section 4.3.2 requires support for 'https' URLs, and discourages the 623 use of 'http' URLs, to mitigate pervasive monitoring attacks. 625 Applications that use HTTP in a manner that involves modification of 626 implementations - for example, requiring support for a new URL 627 scheme, or a non-standard method - risk having those implementations 628 "fork" from their parent HTTP implementations, with the possible 629 result that they do not benefit from patches and other security 630 improvements incorporated upstream. 632 7. References 634 7.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, 638 DOI 10.17487/RFC2119, March 1997, 639 . 641 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 642 Procedures for Message Header Fields", BCP 90, RFC 3864, 643 DOI 10.17487/RFC3864, September 2004, 644 . 646 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 647 DOI 10.17487/RFC5988, October 2010, 648 . 650 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 651 Specifications and Registration Procedures", BCP 13, 652 RFC 6838, DOI 10.17487/RFC6838, January 2013, 653 . 655 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 656 Protocol (HTTP/1.1): Message Syntax and Routing", 657 RFC 7230, DOI 10.17487/RFC7230, June 2014, 658 . 660 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 661 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 662 DOI 10.17487/RFC7231, June 2014, 663 . 665 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 666 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 667 DOI 10.17487/RFC7232, June 2014, 668 . 670 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 671 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 672 RFC 7233, DOI 10.17487/RFC7233, June 2014, 673 . 675 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 676 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 677 RFC 7234, DOI 10.17487/RFC7234, June 2014, 678 . 680 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 681 Protocol (HTTP/1.1): Authentication", RFC 7235, 682 DOI 10.17487/RFC7235, June 2014, 683 . 685 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 686 "Transport Layer Security (TLS) Application-Layer Protocol 687 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 688 July 2014, . 690 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 691 RFC 7320, DOI 10.17487/RFC7320, July 2014, 692 . 694 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 695 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 696 DOI 10.17487/RFC7540, May 2015, 697 . 699 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 700 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 701 May 2017, . 703 [W3C.REC-cors-20140116] 704 Kesteren, A., "Cross-Origin Resource Sharing", World Wide 705 Web Consortium Recommendation REC-cors-20140116, January 706 2014, . 708 7.2. Informative References 710 [FETCH] various, ., "Fetch - Living Standard", September 2017, 711 . 713 [HTML5] various, ., "HTML - Living Standard", September 2017, 714 . 716 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 717 RFC 793, DOI 10.17487/RFC0793, September 1981, 718 . 720 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 721 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 722 1983, . 724 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 725 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 726 . 728 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 729 RFC 2821, DOI 10.17487/RFC2821, April 2001, 730 . 732 [RFC4367] Rosenberg, J., Ed. and IAB, "What's in a Name: False 733 Assumptions about DNS Names", RFC 4367, 734 DOI 10.17487/RFC4367, February 2006, 735 . 737 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 738 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 739 DOI 10.17487/RFC4791, March 2007, 740 . 742 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 743 Uniform Resource Identifiers (URIs)", RFC 5785, 744 DOI 10.17487/RFC5785, April 2010, 745 . 747 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 748 DOI 10.17487/RFC6265, April 2011, 749 . 751 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 752 DOI 10.17487/RFC6454, December 2011, 753 . 755 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 756 RFC 6455, DOI 10.17487/RFC6455, December 2011, 757 . 759 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 760 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 761 2014, . 763 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 764 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 765 2014, . 767 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 768 and Registration Procedures for URI Schemes", BCP 35, 769 RFC 7595, DOI 10.17487/RFC7595, June 2015, 770 . 772 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 773 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 774 August 2015, . 776 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 777 RFC 7617, DOI 10.17487/RFC7617, September 2015, 778 . 780 [W3C.CR-secure-contexts-20160915] 781 West, M., "Secure Contexts", World Wide Web Consortium CR 782 CR-secure-contexts-20160915, September 2016, 783 . 785 7.3. URIs 787 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 789 [2] http://httpwg.github.io/ 791 [3] https://github.com/httpwg/http-extensions/labels/bcp56bis 793 Appendix A. Changes from RFC3205 795 RFC3205 captured the Best Current Practice in the early 2000's, based 796 on the concerns facing protocol designers at the time. Use of HTTP 797 has changed considerably since then, and as a result this document is 798 substantially different. As a result, the changes are too numerous 799 to list individually. 801 Author's Address 803 Mark Nottingham 805 Email: mnot@mnot.net 806 URI: https://www.mnot.net/