idnits 2.17.1 draft-ietf-httpbis-bcp56bis-08.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 (November 9, 2018) is 1993 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 1394 -- Looks like a reference, but probably isn't: '2' on line 1396 -- Looks like a reference, but probably isn't: '3' on line 1398 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-cache-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-cache' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-messaging' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-07 == Outdated reference: A later version (-13) exists of draft-ietf-httpbis-rfc6265bis-02 == Outdated reference: A later version (-11) exists of draft-nottingham-rfc5785bis-08 -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7538 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7807 (Obsoleted by RFC 9457) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Nottingham 3 Internet-Draft November 9, 2018 4 Obsoletes: 3205 (if approved) 5 Intended status: Best Current Practice 6 Expires: May 13, 2019 8 Building Protocols with HTTP 9 draft-ietf-httpbis-bcp56bis-08 11 Abstract 13 HTTP is often used as a substrate for other application protocols 14 (a.k.a. HTTP-based APIs). This document specifies best practices 15 for such protocols' use of HTTP when they are defined for diverse 16 implementation and broad deployment (e.g., in standards efforts). 18 Note to Readers 20 Discussion of this draft takes place on the HTTP working group 21 mailing list (ietf-http-wg@w3.org), which is archived at 22 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 24 Working Group information can be found at http://httpwg.github.io/ 25 [2]; source code and issues list for this draft can be found at 26 https://github.com/httpwg/http-extensions/labels/bcp56bis [3]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 13, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 64 2. Is HTTP Being Used? . . . . . . . . . . . . . . . . . . . . . 4 65 3. What's Important About HTTP . . . . . . . . . . . . . . . . . 5 66 3.1. Generic Semantics . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Rich Functionality . . . . . . . . . . . . . . . . . . . 7 69 4. Best Practices for Using HTTP . . . . . . . . . . . . . . . . 8 70 4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 8 71 4.2. Defining HTTP Resources . . . . . . . . . . . . . . . . . 9 72 4.3. Specifying Client Behaviours . . . . . . . . . . . . . . 9 73 4.4. HTTP URLs . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.4.1. Initial URL Discovery . . . . . . . . . . . . . . . . 11 75 4.4.2. URL Schemes . . . . . . . . . . . . . . . . . . . . . 11 76 4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 12 77 4.5. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 13 78 4.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.5.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 14 80 4.6. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 15 81 4.6.1. Redirection . . . . . . . . . . . . . . . . . . . . . 16 82 4.7. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 17 83 4.8. Defining Message Payloads . . . . . . . . . . . . . . . . 18 84 4.9. HTTP Caching . . . . . . . . . . . . . . . . . . . . . . 18 85 4.10. Application State . . . . . . . . . . . . . . . . . . . . 20 86 4.11. Client Authentication . . . . . . . . . . . . . . . . . . 21 87 4.12. Co-Existing with Web Browsing . . . . . . . . . . . . . . 21 88 4.13. Application Boundaries . . . . . . . . . . . . . . . . . 23 89 4.14. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23 90 4.15. Versioning and Evolution . . . . . . . . . . . . . . . . 24 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 25 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 96 7.2. Informative References . . . . . . . . . . . . . . . . . 27 97 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 98 Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 30 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 101 1. Introduction 103 HTTP [I-D.ietf-httpbis-semantics] is often used as a substrate for 104 applications other than Web browsing; this is sometimes referred to 105 as creating "HTTP-based APIs", or just "HTTP APIs". This is done for 106 a variety of reasons, including: 108 o familiarity by implementers, specifiers, administrators, 109 developers and users, 111 o availability of a variety of client, server and proxy 112 implementations, 114 o ease of use, 116 o availability of Web browsers, 118 o reuse of existing mechanisms like authentication and encryption, 120 o presence of HTTP servers and clients in target deployments, and 122 o its ability to traverse firewalls. 124 These protocols are often ad hoc; they are intended for only 125 deployment by one or a few servers, and consumption by a limited set 126 of clients. Perhaps because of the factors cited above, a body of 127 practices and tools has arisen around defining HTTP-based APIs that 128 favours these conditions. 130 However, when such an application has multiple, separate 131 implementations of the server component, is deployed on multiple 132 uncoordinated servers, and is consumed by diverse clients - as is 133 often the case for standards efforts to define new HTTP APIs - tools 134 and practices intended for limited deployment can become unsuitable. 136 This is largely because implementations (both client and server) will 137 implement and evolve at different paces. As a result, such an HTTP- 138 based API will need to more carefully consider how extensibility of 139 the service will be handled and how different deployment requirements 140 will be accommodated. 142 More generally, application protocols using HTTP face a number of 143 design decisions, including: 145 o Should it define a new URL scheme? Use new ports? 147 o Should it use standard HTTP methods and status codes, or define 148 new ones? 150 o How can the maximum value be extracted from the use of HTTP? 152 o How does it coexist with other uses of HTTP - especially Web 153 browsing? 155 o How can interoperability problems and "protocol dead ends" be 156 avoided? 158 This document contains best current practices regarding the use of 159 HTTP by applications other than Web browsing. Section 2 defines what 160 applications it applies to; Section 3 surveys the properties of HTTP 161 that are important to preserve, and Section 4 conveys best practices 162 for those applications that do use HTTP. 164 It is written primarily to guide IETF efforts to define application 165 protocols using HTTP for deployment on the Internet, but might be 166 applicable in other situations. Note that the requirements herein do 167 not necessarily apply to the development of generic HTTP extensions. 169 1.1. Notational Conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 2. Is HTTP Being Used? 179 Different applications have different goals when using HTTP. The 180 requirements in this document apply when any of the following 181 conditions are true: 183 o The transport port in use is 80 or 443, 185 o The URL scheme "http" or "https" is used, 187 o The ALPN protocol ID [RFC7301] generically identifies HTTP (e.g., 188 "http/1.1", "h2", "h2c"), or 190 o The IANA registries defined for HTTP are updated or modified. 192 When an application is using HTTP, all of the requirements of the 193 HTTP protocol suite are in force (including but not limited to 194 [I-D.ietf-httpbis-semantics], [I-D.ietf-httpbis-cache], 195 [I-D.ietf-httpbis-messaging], and [RFC7540]). 197 An application might not use HTTP according to this definition and 198 still rely upon the HTTP specifications in some manner. For example, 199 an application might wish to avoid re-specifying parts of the message 200 format, but change others; or, it might want to use a different set 201 of methods. 203 Such applications are referred to as "protocols based upon HTTP" in 204 this document. These have more freedom to modify protocol 205 operations, but are also likely to lose at least a portion of the 206 benefits outlined above, as most HTTP implementations won't be easily 207 adaptable to these changes, and as the protocol diverges from HTTP, 208 the benefit of mindshare will be lost. 210 Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes, 211 transport ports, ALPN protocol IDs or IANA registries; rather, they 212 are encouraged to establish their own. 214 3. What's Important About HTTP 216 Applications using HTTP are defined and deployed in many ways; 217 sometimes they are brought to the IETF for standardisation. What 218 might be workable for deployment in a limited fashion isn't 219 appropriate for standardisation and the corresponding broader 220 deployment. 222 This section examines the facets of the protocol that are important 223 to preserve in these situations. 225 3.1. Generic Semantics 227 When writing a specification, it's often tempting to specify exactly 228 how HTTP is to be implemented, supported and used. 230 However, this can easily lead to an unintended profile of HTTP's 231 behaviour. For example, it's common to see specifications with 232 language like this: 234 A `POST` request MUST result in a `201 Created` response. 236 This forms an expectation in the client that the response will always 237 be "201 Created", when in fact there are a number of reasons why the 238 status code might differ in a real deployment. If the client does 239 not anticipate this, the application's deployment is brittle. 241 Much of the value of HTTP is in its generic semantics - that is, the 242 protocol elements defined by HTTP are potentially applicable to every 243 resource, not specific to a particular context. Application-specific 244 semantics are expressed in the payload; mostly, in the body, but also 245 in header fields. 247 This allows a HTTP message to be examined by generic software (e.g., 248 HTTP servers, intermediaries, client implementations, and caches) and 249 its handling to be correctly determined. It also allows people to 250 leverage their knowledge of HTTP semantics without special-casing 251 them for a particular application. 253 Therefore, applications that use HTTP MUST NOT re-define, refine or 254 overlay the semantics of defined protocol elements. Instead, they 255 should focus their specifications on protocol elements that are 256 specific to that application; namely their HTTP resources. 258 See Section 4.2 for details. 260 3.2. Links 262 Another common practice is assuming that the HTTP server's name space 263 (or a portion thereof) is exclusively for the use of a single 264 application. This effectively overlays special, application-specific 265 semantics onto that space, precludes other applications from using 266 it. 268 As explained in [RFC7320], such "squatting" on a part of the URL 269 space by a standard usurps the server's authority over its own 270 resources, can cause deployment issues, and is therefore bad practice 271 in standards. 273 Instead of statically defining URL components like paths, it is 274 RECOMMENDED that applications using HTTP define links in payloads, to 275 allow flexibility in deployment. 277 Using runtime links in this fashion has a number of other benefits - 278 especially when an application is to have multiple implementations 279 and/or deployments (as is often the case for those that are 280 standardised). 282 For example, navigating with a link allows a request to be routed to 283 a different server without the overhead of a redirection, thereby 284 supporting deployment across machines well. 286 It also becomes possible to "mix and match" different applications on 287 the same server, and offers a natural mechanism for extensibility, 288 versioning and capability management, since the document containing 289 the links can also contain information about their targets. 291 Using links also offers a form of cache invalidation that's seen on 292 the Web; when a resource's state changes, the application can change 293 its link to it so that a fresh copy is always fetched. 295 3.3. Rich Functionality 297 HTTP offers a number of features to applications, such as: 299 o Message framing 301 o Multiplexing (in HTTP/2) 303 o Integration with TLS 305 o Support for intermediaries (proxies, gateways, Content Delivery 306 Networks) 308 o Client authentication 310 o Content negotiation for format, language, and other features 312 o Caching for server scalability, latency and bandwidth reduction, 313 and reliability 315 o Granularity of access control (through use of a rich space of 316 URLs) 318 o Partial content to selectively request part of a response 320 o The ability to interact with the application easily using a Web 321 browser 323 Applications that use HTTP are encouraged to utilise the various 324 features that the protocol offers, so that their users receive the 325 maximum benefit from it, and to allow it to be deployed in a variety 326 of situations. This document does not require specific features to 327 be used, since the appropriate design tradeoffs are highly specific 328 to a given situation. However, following the practices in Section 4 329 is a good starting point. 331 4. Best Practices for Using HTTP 333 This section contains best practices regarding the use of HTTP by 334 applications, including practices for specific HTTP protocol 335 elements. 337 4.1. Specifying the Use of HTTP 339 When specifying the use of HTTP, an application SHOULD use 340 [I-D.ietf-httpbis-semantics] as the primary reference; it is not 341 necessary to reference all of the specifications in the HTTP suite 342 unless there are specific reasons to do so (e.g., a particular 343 feature is called out). 345 Applications using HTTP SHOULD NOT specify a minimum version of HTTP 346 to be used; because it is a hop-by-hop protocol, a HTTP connection 347 can be handled by implementations that are not controlled by the 348 application; for example, proxies, CDNs, firewalls and so on. 349 Requiring a particular version of HTTP makes it difficult to use in 350 these situations, and harms interoperability for little reason (since 351 HTTP's semantics are stable between protocol versions). 353 However, if an application's deployment would benefit from the use of 354 a particular version of HTTP (for example, HTTP/2's multiplexing), 355 this SHOULD be noted. 357 Applications using HTTP MUST NOT specify a maximum version, to 358 preserve the protocol's ability to evolve. 360 When specifying examples of protocol interactions, applications 361 SHOULD document both the request and response messages, with full 362 headers, preferably in HTTP/1.1 format. For example: 364 GET /thing HTTP/1.1 365 Host: example.com 366 Accept: application/things+json 367 User-Agent: Foo/1.0 369 HTTP/1.1 200 OK 370 Content-Type: application/things+json 371 Content-Length: 500 372 Server: Bar/2.2 374 [payload here] 376 4.2. Defining HTTP Resources 378 Applications that use HTTP should focus on defining the following 379 application-specific protocol elements: 381 o Media types [RFC6838], often based upon a format convention such 382 as JSON [RFC8259], 384 o HTTP header fields, as per Section 4.7, and 386 o The behaviour of resources, as identified by link relations 387 [RFC8288]. 389 By composing these protocol elements, an application can define a set 390 of resources, identified by link relations, that implement specified 391 behaviours, including: 393 o Retrieval of their state using GET, in one or more formats 394 identified by media type; 396 o Resource creation or update using POST or PUT, with an 397 appropriately identified request body format; 399 o Data processing using POST and identified request and response 400 body format(s); and 402 o Resource deletion using DELETE. 404 For example, an application might specify: 406 Resources linked to with the "example-widget" link relation type are 407 Widgets. The state of a Widget can be fetched in the 408 "application/example-widget+json" format, and can be updated by PUT 409 to the same link. Widget resources can be deleted. 411 The "Example-Count" response header field on Widget representations 412 indicates how many Widgets are held by the sender. 414 The "application/example-widget+json" format is a JSON [RFC8259] 415 format representing the state of a Widget. It contains links to 416 related information in the link indicated by the Link header field 417 value with the "example-other-info" link relation type. 419 4.3. Specifying Client Behaviours 421 Some behaviours (e.g., automatic redirect handling) and extensions 422 (e.g., Cookies) are not required by HTTP, but nevertheless have 423 become very common, possibly because they are supported by Web 424 browsers. If their use is not explicitly specified by applications 425 using HTTP, there may be confusion and interoperability problems. 426 This section recommends default handling for these mechanisms. 428 o Redirect handling - Applications need to specify how redirects are 429 expected to be handled; see Section 4.6.1. 431 o Cookies - Applications using HTTP MUST explicitly reference the 432 Cookie specification [I-D.ietf-httpbis-rfc6265bis] if they are 433 required. 435 o Certificates - Applications using HTTP MUST specify that TLS 436 certificates are to be checked according to [RFC2818] when HTTPS 437 is used. 439 In general, applications using HTTP ought to align their usage as 440 closely as possible with Web browsers, to avoid interoperability 441 issues when they are used. See Section 4.12. 443 If an application using HTTP has browser compatibility as a goal, 444 client interaction ought to be defined in terms of [FETCH], since 445 that is the abstraction that browsers use for HTTP; it enforces many 446 of these best practices. 448 Applications using HTTP MUST NOT require HTTP features that are 449 usually negotiated to be supported by clients. For example, 450 requiring that clients support responses with a certain content- 451 coding ([I-D.ietf-httpbis-semantics], Section 6.2.2) instead of 452 negotiating for it ({{?I-D.ietf-httpbis-semantics, Section 8.4.4) 453 means that otherwise conformant clients cannot interoperate with the 454 application. Applications MAY encourage the implementation of such 455 features, though. 457 4.4. HTTP URLs 459 In HTTP, URLs are opaque identifiers under the control of the server. 460 As outlined in [RFC7320], standards cannot usurp this space, since it 461 might conflict with existing resources, and constrain implementation 462 and deployment. 464 In other words, applications that use HTTP shouldn't associate 465 application semantics with specific URL paths on arbitrary servers. 466 Doing so inappropriately conflates the identity of the resource (its 467 URL) with the capabilities that resource supports, bringing about 468 many of the same interoperability problems that [RFC4367] warns of. 470 For example, specifying that a "GET to the URL /foo retrieves a bar 471 document" is bad practice. Likewise, specifying "The widget API is 472 at the path /bar" violates [RFC7320]. 474 Instead, applications are encouraged to ensure that URLs are 475 discovered at runtime, allowing HTTP-based services to describe their 476 own capabilities. One way to do this is to use typed links [RFC8288] 477 to convey the URIs that are in use, as well as the semantics of the 478 resources that they identify. See Section 4.2 for details. 480 4.4.1. Initial URL Discovery 482 Generally, a client will begin interacting with a given application 483 server by requesting an initial document that contains information 484 about that particular deployment, potentially including links to 485 other relevant resources. 487 Applications are encouraged to allow an arbitrary URL to be used as 488 that entry point. For example, rather than specifying "the initial 489 document is at "/foo/v1", they should allow a deployment to use any 490 URL as the entry point for the application. 492 In cases where doing so is impractical (e.g., it is not possible to 493 convey a whole URL, but only a hostname) applications can request a 494 well-known URL [I-D.nottingham-rfc5785bis] as an entry point. 496 4.4.2. URL Schemes 498 Applications that use HTTP will typically employ the "http" and/or 499 "https" URL schemes. "https" is RECOMMENDED to provide 500 authentication, integrity and confidentiality, as well as mitigate 501 pervasive monitoring attacks [RFC7258]. 503 However, application-specific schemes can also be defined. When 504 defining an URL scheme for an application using HTTP, there are a 505 number of tradeoffs and caveats to keep in mind: 507 o Unmodified Web browsers will not support the new scheme. While it 508 is possible to register new URL schemes with Web browsers (e.g. 509 registerProtocolHandler() in [HTML5], as well as several 510 proprietary approaches), support for these mechanisms is not 511 shared by all browsers, and their capabilities vary. 513 o Existing non-browser clients, intermediaries, servers and 514 associated software will not recognise the new scheme. For 515 example, a client library might fail to dispatch the request; a 516 cache might refuse to store the response, and a proxy might fail 517 to forward the request. 519 o Because URLs occur in HTTP artefacts commonly, often being 520 generated automatically (e.g., in the "Location" response header), 521 it can be difficult to assure that the new scheme is used 522 consistently. 524 o The resources identified by the new scheme will still be available 525 using "http" and/or "https" URLs. Those URLs can "leak" into use, 526 which can present security and operability issues. For example, 527 using a new scheme to assure that requests don't get sent to a 528 "normal" Web site is likely to fail. 530 o Features that rely upon the URL's origin [RFC6454], such as the 531 Web's same-origin policy, will be impacted by a change of scheme. 533 o HTTP-specific features such as cookies 534 [I-D.ietf-httpbis-rfc6265bis], authentication 535 [I-D.ietf-httpbis-semantics], caching [I-D.ietf-httpbis-cache], 536 HSTS [RFC6797], and CORS [FETCH] might or might not work 537 correctly, depending on how they are defined and implemented. 538 Generally, they are designed and implemented with an assumption 539 that the URL will always be "http" or "https". 541 o Web features that require a secure context [SECCTXT] will likely 542 treat a new scheme as insecure. 544 See [RFC7595] for more information about minting new URL schemes. 546 4.4.3. Transport Ports 548 Applications can use the applicable default port (80 for HTTP, 443 549 for HTTPS), or they can be deployed upon other ports. This decision 550 can be made at deployment time, or might be encouraged by the 551 application's specification (e.g., by registering a port for that 552 application). 554 If a non-default port is used, it needs to be reflected in the 555 authority of all URLs for that resource; the only mechanism for 556 changing a default port is changing the scheme (see Section 4.4.2). 558 Using a port other than the default has privacy implications (i.e., 559 the protocol can now be distinguished from other traffic), as well as 560 operability concerns (as some networks might block or otherwise 561 interfere with it). Privacy implications should be documented in 562 Security Considerations. 564 See [RFC7605] for further guidance. 566 4.5. HTTP Methods 568 Applications that use HTTP MUST confine themselves to using 569 registered HTTP methods such as GET, POST, PUT, DELETE, and PATCH. 571 New HTTP methods are rare; they are required to be registered in the 572 HTTP Method Registry with IETF Review (see 573 [I-D.ietf-httpbis-semantics]), and are also required to be generic. 574 That means that they need to be potentially applicable to all 575 resources, not just those of one application. 577 While historically some applications (e.g., [RFC4791]) have defined 578 non-generic methods, [I-D.ietf-httpbis-semantics] now forbids this. 580 When authors believe that a new method is required, they are 581 encouraged to engage with the HTTP community early, and document 582 their proposal as a separate HTTP extension, rather than as part of 583 an application's specification. 585 4.5.1. GET 587 GET is one of the most common and useful HTTP methods; its retrieval 588 semantics allow caching, side-effect free linking and underlies many 589 of the benefits of using HTTP. 591 A common use of GET is to perform queries, often using the query 592 component of the URL; this is a familiar pattern from Web browsing, 593 and the results can be cached, improving efficiency of an often 594 expensive process. 596 In some cases, however, GET might be unwieldy for expressing queries, 597 because of the limited syntax of the URL; in particular, if binary 598 data forms part of the query terms, it needs to be encoded to conform 599 to URL syntax. 601 While this is not an issue for short queries, it can become one for 602 larger query terms, or ones which need to sustain a high rate of 603 requests. Additionally, some HTTP implementations limit the size of 604 URLs they support - although modern HTTP software has much more 605 generous limits than previously (typically, considerably more than 606 8000 octets, as required by [I-D.ietf-httpbis-semantics]. 608 In these cases, an application using HTTP might consider using POST 609 to express queries in the request body; doing so avoids encoding 610 overhead and URL length limits in implementations. However, in doing 611 so it should be noted that the benefits of GET such as caching and 612 linking to query results are lost. Therefore, applications using 613 HTTP that feel a need to allow POST queries ought consider allowing 614 both methods. 616 Applications SHOULD NOT define GET requests to have side effects, 617 since implementations can and do retry HTTP GET requests that fail. 619 Finally, note that while HTTP allows GET requests to have a body 620 syntactically, this is done only to allow parsers to be generic; as 621 per [I-D.ietf-httpbis-semantics], Section 7.3.1, a body on a GET has 622 no meaning, and will be either ignored or rejected by generic HTTP 623 software. 625 4.5.2. OPTIONS 627 The OPTIONS method was defined for metadata retrieval, and is used 628 both by WebDAV [RFC4918] and CORS [FETCH]. Because HTTP-based APIs 629 often need to retrieve metadata about resources, it is often 630 considered for their use. 632 However, OPTIONS does have significant limitations: 634 o It isn't possible to link to the metadata with a simple URL, 635 because OPTIONS is not the default GET method. 637 o OPTIONS responses are not cacheable, because HTTP caches operate 638 on representations of the resource (i.e., GET and HEAD). If 639 OPTIONS responses are cached separately, their interaction with 640 HTTP cache expiry, secondary keys and other mechanisms needs to be 641 considered. 643 o OPTIONS is "chatty" - always separating metadata out into a 644 separate request increases the number of requests needed to 645 interact with the application. 647 o Implementation support for OPTIONS is not universal; some servers 648 do not expose the ability to respond to OPTIONS requests without 649 significant effort. 651 Instead of OPTIONS, one of these alternative approaches might be more 652 appropriate: 654 o For server-wide metadata, create a well-known URI 655 [I-D.nottingham-rfc5785bis], or using an already existing one if 656 it's appropriate (e.g., HostMeta [RFC6415]). 658 o For metadata about a specific resource, create a separate resource 659 and link to it using a Link response header or a link serialised 660 into the representation's body. See [RFC8288]. Note that the 661 Link header is available on HEAD responses, which is useful if the 662 client wants to discover a resource's capabilities before they 663 interact with it. 665 4.6. HTTP Status Codes 667 The primary function of a HTTP status code is to convey semantics for 668 the benefit of generic HTTP software, not to convey application- 669 specific semantics. 671 Status codes are often generated or overwritten by intermediaries, as 672 well as server and client implementations. This can happen, for 673 example, when network errors are encountered, a captive portal is 674 present, when an implementation is overloaded, or it thinks it is 675 under attack. As a result, the status code that a server-side 676 application generates and the one that the client software receives 677 often differ. 679 This means that status codes are not a reliable way to carry 680 application-specific signals. Specifying that a particular status 681 code has a specific meaning in the context of an application can have 682 unintended side effects; if that status code is generated by a 683 generic HTTP component can lead clients to believe that the 684 application is in a state that wasn't intended. 686 Instead, applications using HTTP should specify the implications of 687 general classes of responses (e.g., "successful response" for 2xx; 688 "client error" for 4xx and "server error" for 5xx), conveying any 689 application-specific information in the message body and/or HTTP 690 header fields, not the status code. [RFC7807] provides one way for 691 applications using HTTP to do so for error conditions. 693 There are limited exceptions to this; for example, applications might 694 use 201 (Created) or 404 (Not Found) to convey application semantics 695 that are compatible with the generic HTTP semantics of those status 696 codes. In general, though, applications should resist the temptation 697 to map their semantics into fine-grained status codes. 699 Because the set of registered HTTP status codes can expand, 700 applications using HTTP should explicitly point out that clients 701 ought to be able to handle all applicable status codes gracefully 702 (i.e., falling back to the generic "n00" semantics of a given status 703 code; e.g., "499" can be safely handled as "400" by clients that 704 don't recognise it). This is preferable to creating a "laundry list" 705 of potential status codes, since such a list is never complete. 707 Applications using HTTP MUST NOT re-specify the semantics of HTTP 708 status codes, even if it is only by copying their definition. They 709 MUST NOT require specific reason phrases to be used; the reason 710 phrase has no function in HTTP, is not guaranteed to be preserved by 711 implementations, and the reason phrase is not carried at all in the 712 HTTP/2 [RFC7540] message format. 714 Applications MUST only use registered HTTP status codes. As with 715 methods, new HTTP status codes are rare, and required (by 716 [I-D.ietf-httpbis-semantics]) to be registered with IETF Review. 717 Similarly, HTTP status codes are generic; they are required (by 718 [I-D.ietf-httpbis-semantics]) to be potentially applicable to all 719 resources, not just to those of one application. 721 When authors believe that a new status code is required, they are 722 encouraged to engage with the HTTP community early, and document 723 their proposal as a separate HTTP extension, rather than as part of 724 an application's specification. 726 4.6.1. Redirection 728 The 3xx series of status codes specified in 729 [I-D.ietf-httpbis-semantics], Section 9.4 direct the user agent to 730 another resource to satisfy the request. The most common of these 731 are 301, 302, 307 and 308 ([RFC7538]), all of which use the Location 732 response header field to indicate where the client should send the 733 request to. 735 There are two ways that this group of status codes differ: 737 o Whether they are permanent or temporary. Permanent redirects can 738 be used to update links stored in the client (e.g., bookmarks), 739 whereas temporary ones can not. Note that this has no effect on 740 HTTP caching; it is completely separate. 742 o Whether they allow the redirected request to change the request 743 method from POST to GET. Web browsers generally do change POST to 744 GET for 301 and 302; therefore, 308 and 307 were created to allow 745 redirection without changing the method. 747 This table summarises their relationships: 749 +-------------------------------------------+-----------+-----------+ 750 | | Permanent | Temporary | 751 +-------------------------------------------+-----------+-----------+ 752 | Allows changing the request method from | 301 | 302 | 753 | POST to GET | | | 754 | Does not allow changing the request | 308 | 307 | 755 | method | | | 756 +-------------------------------------------+-----------+-----------+ 757 As noted in [I-D.ietf-httpbis-semantics], a user agent is allowed to 758 automatically follow a 3xx redirect that has a Location response 759 header field, even if they don't understand the semantics of the 760 specific status code. However, they aren't required to do so; 761 therefore, if an application using HTTP desires redirects to be 762 automatically followed, it needs to explicitly specify the 763 circumstances when this is required. 765 Applications using HTTP SHOULD specify that 301 and 302 responses 766 change the subsequent request method from POST (but no other method) 767 to GET, to be compatible with browsers. 769 Generally, when a redirected request is made, its header fields are 770 copied from the original request's. However, they can be modified by 771 various mechanisms; e.g., sent Authorization 772 ([I-D.ietf-httpbis-semantics]) and Cookie 773 ([I-D.ietf-httpbis-rfc6265bis]) headers will change if the origin 774 (and sometimes path) of the request changes. Applications using HTTP 775 SHOULD specify if any request headers need to be modified or removed 776 upon a redirect; however, this behaviour cannot be relied upon, since 777 a generic client (like a browser) will be unaware of such 778 requirements. 780 4.7. HTTP Header Fields 782 Applications MAY define new HTTP header fields. Typically, using 783 HTTP header fields is appropriate in a few different situations: 785 o Their content is useful to intermediaries (who often wish to avoid 786 parsing the body), and/or 788 o Their content is useful to generic HTTP software (e.g., clients, 789 servers), and/or 791 o It is not possible to include their content in the message body 792 (usually because a format does not allow it). 794 New header fields MUST be registered, as per 795 [I-D.ietf-httpbis-semantics]. 797 See [I-D.ietf-httpbis-semantics], Section 4.1.3 for guidelines to 798 consider when minting new header fields. 799 [I-D.ietf-httpbis-header-structure] provides a common structure for 800 new header fields, and avoids many issues in their parsing and 801 handling; it is RECOMMENDED that new header fields use it. 803 It is RECOMMENDED that header field names be short (even when HTTP/2 804 header compression is in effect, there is an overhead) but 805 appropriately specific. In particular, if a header field is specific 806 to an application, an identifier for that application SHOULD form a 807 prefix to the header field name, separated by a "-". 809 For example, if the "example" application needs to create three 810 headers, they might be called "example-foo", "example-bar" and 811 "example-baz". Note that the primary motivation here is to avoid 812 consuming more generic header names, not to reserve a portion of the 813 namespace for the application; see [RFC6648] for related 814 considerations. 816 The semantics of existing HTTP header fields MUST NOT be re-defined 817 without updating their registration or defining an extension to them 818 (if allowed). For example, an application using HTTP cannot specify 819 that the "Location" header has a special meaning in a certain 820 context. 822 See Section 4.9 for the interaction between headers and HTTP caching; 823 in particular, request headers that are used to "select" a response 824 have impact there, and need to be carefully considered. 826 See Section 4.10 for considerations regarding header fields that 827 carry application state (e.g., Cookie). 829 4.8. Defining Message Payloads 831 There are many potential formats for payloads; for example, JSON 832 [RFC8259], XML [XML], and CBOR [RFC7049]. Best practices for their 833 use are out of scope for this document. 835 Applications SHOULD register distinct media types for each format 836 they define; this makes it possible to identify them unambiguously 837 and negotiate for their use. See [RFC6838] for more information. 839 4.9. HTTP Caching 841 HTTP caching [I-D.ietf-httpbis-cache] is one of the primary benefits 842 of using HTTP for applications; it provides scalability, reduces 843 latency and improves reliability. Furthermore, HTTP caches are 844 readily available in browsers and other clients, networks as forward 845 and reverse proxies, Content Delivery Networks and as part of server 846 software. 848 Assigning even a short freshness lifetime ([I-D.ietf-httpbis-cache], 849 Section 4.2) - e.g., 5 seconds - allows a response to be reused to 850 satisfy multiple clients, and/or a single client making the same 851 request repeatedly. In general, if it is safe to reuse something, 852 consider assigning a freshness lifetime; cache implementations take 853 active measures to remove content intelligently when they are out of 854 space, so "it will fill up the cache" is not a valid concern. 856 The most common method for specifying freshness is the max-age 857 response directive ([I-D.ietf-httpbis-cache], Section 5.2.2.8). The 858 Expires header ([I-D.ietf-httpbis-cache], Section 5.3) can also be 859 used, but it is not necessary to specify it; all modern cache 860 implementations support Cache-Control, and specifying freshness as a 861 delta is usually more convenient and always less error-prone. 863 Understand that stale responses (e.g., with "Cache-Control: max- 864 age=0") can be reused when the cache is disconnected from the origin 865 server; this can be useful for handling network issues. See 866 [I-D.ietf-httpbis-cache], Section 4.2.4, and also [RFC5861] for 867 additional controls over stale content. 869 Stale responses can be refreshed by assigning a validator, saving 870 both transfer bandwidth and latency for large responses; see 871 [I-D.ietf-httpbis-semantics]. 873 If an application uses a request header field to change the 874 response's headers or body, authors should point out that this has 875 implications for caching; in general, such resources need to either 876 make their responses uncacheable (e.g., with the "no-store" cache- 877 control directive defined in [I-D.ietf-httpbis-cache], 878 Section 5.2.2.3) or send the Vary response header 879 ([I-D.ietf-httpbis-semantics], Section 10.1.4) on all responses from 880 that resource (including the "default" response). 882 For example, this response: 884 HTTP/1.1 200 OK 885 Content-Type: application/example+xml 886 Cache-Control: max-age=60 887 ETag: "sa0f8wf20fs0f" 888 Vary: Accept-Encoding 890 [content] 892 can be stored for 60 seconds by both private and shared caches, can 893 be revalidated with If-None-Match, and varies on the Accept-Encoding 894 request header field. 896 In some situations, responses without explicit cache directives 897 (e.g., Cache-Control or Expires) will be stored and served using a 898 heuristic freshness lifetime; see [I-D.ietf-httpbis-cache], 899 Section 4.2.2. As the heuristic is not under control of the 900 application, it is generally preferable to set an explicit freshness 901 lifetime. 903 If caching of a response is not desired, the appropriate response 904 directive is "Cache-Control: no-store". This only need be sent in 905 situations where the response might be cached; see 906 [I-D.ietf-httpbis-cache], Section 3. Note that "Cache-Control: no- 907 cache" allows a response to be stored, just not reused by a cache; it 908 does not prevent caching (despite its name). 910 For example, this response cannot be stored or reused by a cache: 912 HTTP/1.1 200 OK 913 Content-Type: application/example+xml 914 Cache-Control: no-store 916 [content] 918 When an application has a need to express a lifetime that's separate 919 from the freshness lifetime, this should be expressed separately, 920 either in the response's body or in a separate header field. When 921 this happens, the relationship between HTTP caching and that lifetime 922 need to be carefully considered, since the response will be used as 923 long as it is considered fresh. 925 Like other functions, HTTP caching is generic; it does not have 926 knowledge of the application in use. Therefore, caching extensions 927 need to be backwards-compatible, as per [I-D.ietf-httpbis-cache], 928 Section 5.2.3. 930 4.10. Application State 932 Applications MAY use stateful cookies [I-D.ietf-httpbis-rfc6265bis] 933 to identify a client and/or store client-specific data to 934 contextualise requests. 936 When used, it is important to carefully specify the scoping and use 937 of cookies; if the application exposes sensitive data or capabilities 938 (e.g., by acting as an ambient authority), exploits are possible. 939 Mitigations include using a request-specific token to assure the 940 intent of the client. 942 Applications MUST NOT make assumptions about the relationship between 943 separate requests on a single transport connection; doing so breaks 944 many of the assumptions of HTTP as a stateless protocol, and will 945 cause problems in interoperability, security, operability and 946 evolution. 948 4.11. Client Authentication 950 Applications MAY use HTTP authentication [I-D.ietf-httpbis-semantics] 951 to identify clients. The Basic authentication scheme [RFC7617] MUST 952 NOT be used unless the underlying transport is authenticated, 953 integrity-protected and confidential (e.g., as provided the "HTTPS" 954 URL scheme, or another using TLS). The Digest scheme [RFC7616] MUST 955 NOT be used unless the underlying transport is similarly secure, or 956 the chosen hash algorithm is not "MD5". 958 With HTTPS, clients might also be authenticated using certificates 959 [RFC5246]. 961 When used, it is important to carefully specify the scoping and use 962 of authentication; if the application exposes sensitive data or 963 capabilities (e.g., by acting as an ambient authority), exploits are 964 possible. Mitigations include using a request-specific token to 965 assure the intent of the client. 967 4.12. Co-Existing with Web Browsing 969 Even if there is not an intent for an application to be used with a 970 Web browser, its resources will remain available to browsers and 971 other HTTP clients. 973 This means that all such applications that use HTTP need to consider 974 how browsers will interact with them, particularly regarding 975 security. 977 For example, if an application's state can be changed using a POST 978 request, a Web browser can easily be coaxed into cross-site request 979 forgery (CSRF) from arbitrary Web sites. 981 Or, if content returned from the application's resources is under 982 control of an attacker (for example, part of the request is reflected 983 in the response, or the response contains external information that 984 might be under the control of the attacker), a cross-site scripting 985 (XSS) attack is possible, whereby an attacker can inject code into 986 the browser and access data and capabilities on that origin. 988 This is only a small sample of the kinds of issues that applications 989 using HTTP must consider. Generally, the best approach is to 990 consider the application actually as a Web application, and to follow 991 best practices for their secure development. 993 A complete enumeration of such practices is out of scope for this 994 document, but some considerations include: 996 o Using an application-specific media type in the Content-Type 997 header, and requiring clients to fail if it is not used 999 o Using X-Content-Type-Options: nosniff [FETCH] to assure that 1000 content under attacker control can't be coaxed into a form that is 1001 interpreted as active content by a Web browser 1003 o Using Content-Security-Policy [CSP] to constrain the capabilities 1004 of active content (such as HTML [HTML5]), thereby mitigating 1005 Cross-Site Scripting attacks 1007 o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data 1008 in URLs from being leaked in the Referer request header 1010 o Using the 'HttpOnly' flag on Cookies to assure that cookies are 1011 not exposed to browser scripting languages 1012 [I-D.ietf-httpbis-rfc6265bis] 1014 o Avoiding use of compression on any sensitive information (e.g., 1015 authentication tokens, passwords), as the scripting environment 1016 offered by Web browsers allows an attacker to repeatedly probe the 1017 compression space; if the attacker has access to the path of the 1018 communication, they can use this capability to recover that 1019 information 1021 Depending on how they are intended to be deployed, specifications for 1022 applications using HTTP might require the use of these mechanisms in 1023 specific ways, or might merely point them out in Security 1024 Considerations. 1026 An example of a HTTP response from an application that does not 1027 intend for its content to be treated as active by browsers might look 1028 like this: 1030 HTTP/1.1 200 OK 1031 Content-Type: application/example+json 1032 X-Content-Type-Options: nosniff 1033 Content-Security-Policy: default-src 'none' 1034 Cache-Control: max-age=3600 1035 Referrer-Policy: no-referrer 1037 [content] 1039 If an application has browser compatibility as a goal, client 1040 interaction ought to be defined in terms of [FETCH], since that is 1041 the abstraction that browsers use for HTTP; it enforces many of these 1042 best practices. 1044 4.13. Application Boundaries 1046 Because the origin [RFC6454] is how many HTTP capabilities are 1047 scoped, applications also need to consider how deployments might 1048 interact with other applications (including Web browsing) on the same 1049 origin. 1051 For example, if Cookies [I-D.ietf-httpbis-rfc6265bis] are used to 1052 carry application state, they will be sent with all requests to the 1053 origin by default, unless scoped by path, and the application might 1054 receive cookies from other applications on the origin. This can lead 1055 to security issues, as well as collision in cookie names. 1057 One solution to these issues is to require a dedicated hostname for 1058 the application, so that it has a unique origin. However, it is 1059 often desirable to allow multiple applications to be deployed on a 1060 single hostname; doing so provides the most deployment flexibility 1061 and enables them to be "mixed" together (See [RFC7320] for details). 1062 Therefore, applications using HTTP should strive to allow multiple 1063 applications on an origin. 1065 To enable this, when specifying the use of Cookies, HTTP 1066 authentication realms [I-D.ietf-httpbis-semantics], or other origin- 1067 wide HTTP mechanisms, applications using HTTP SHOULD NOT mandate the 1068 use of a particular name, but instead let deployments configure them. 1069 Consideration SHOULD be given to scoping them to part of the origin, 1070 using their specified mechanisms for doing so. 1072 Modern Web browsers constrain the ability of content from one origin 1073 to access resources from another, to avoid leaking private 1074 information. As a result, applications that wish to expose cross- 1075 origin data to browsers will need to implement the CORS protocol; see 1076 [FETCH]. 1078 4.14. Server Push 1080 HTTP/2 adds the ability for servers to "push" request/response pairs 1081 to clients in [RFC7540], Section 8.2. While server push seems like a 1082 natural fit for many common application semantics (e.g., "fanout" and 1083 publish/subscribe), a few caveats should be noted: 1085 o Server push is hop-by-hop; that is, it is not automatically 1086 forwarded by intermediaries. As a result, it might not work 1087 easily (or at all) with proxies, reverse proxies, and Content 1088 Delivery Networks. 1090 o Server push can have negative performance impact on HTTP when used 1091 incorrectly; in particular, if there is contention with resources 1092 that have actually been requested by the client. 1094 o Server push is implemented differently in different clients, 1095 especially regarding interaction with HTTP caching, and 1096 capabilities might vary. 1098 o APIs for server push are currently unavailable in some 1099 implementations, and vary widely in others. In particular, there 1100 is no current browser API for it. 1102 o Server push is not supported in HTTP/1.1 or HTTP/1.0. 1104 o Server push does not form part of the "core" semantics of HTTP, 1105 and therefore might not be supported by future versions of the 1106 protocol. 1108 Applications wishing to optimise cases where the client can perform 1109 work related to requests before the full response is available (e.g., 1110 fetching links for things likely to be contained within) might 1111 benefit from using the 103 (Early Hints) status code; see [RFC8297]. 1113 Applications using server push directly need to enforce the 1114 requirements regarding authority in [RFC7540], Section 8.2, to avoid 1115 cross-origin push attacks. 1117 4.15. Versioning and Evolution 1119 It's often necessary to introduce new features into application 1120 protocols, and change existing ones. 1122 In HTTP, backwards-incompatible changes are possible using a number 1123 of mechanisms: 1125 o Using a distinct link relation type [RFC8288] to identify a URL 1126 for a resource that implements the new functionality 1128 o Using a distinct media type [RFC6838] to identify formats that 1129 enable the new functionality 1131 o Using a distinct HTTP header field to implement new functionality 1132 outside the message body 1134 5. IANA Considerations 1136 This document has no requirements for IANA. 1138 6. Security Considerations 1140 Section 4.10 discusses the impact of using stateful mechanisms in the 1141 protocol as ambient authority, and suggests a mitigation. 1143 Section 4.4.2 requires support for 'https' URLs, and discourages the 1144 use of 'http' URLs, to provide authentication, integrity and 1145 confidentiality, as well as mitigate pervasive monitoring attacks. 1147 Section 4.12 highlights the implications of Web browsers' 1148 capabilities on applications that use HTTP. 1150 Section 4.13 discusses the issues that arise when applications are 1151 deployed on the same origin as Web sites (and other applications). 1153 Section 4.14 highlights risks of using HTTP/2 server push in a manner 1154 other than specified. 1156 Applications that use HTTP in a manner that involves modification of 1157 implementations - for example, requiring support for a new URL 1158 scheme, or a non-standard method - risk having those implementations 1159 "fork" from their parent HTTP implementations, with the possible 1160 result that they do not benefit from patches and other security 1161 improvements incorporated upstream. 1163 6.1. Privacy Considerations 1165 HTTP clients can expose a variety of information to servers. Besides 1166 information that's explicitly sent as part of an application's 1167 operation (for example, names and other user-entered data), and "on 1168 the wire" (which is one of the reasons https is recommended in 1169 Section 4.4.2), other information can be gathered through less 1170 obvious means - often by connecting activities of a user over time. 1172 This includes session information, tracking the client through 1173 fingerprinting, and mobile code. 1175 Session information includes things like the IP address of the 1176 client, TLS session tickets, Cookies, ETags stored in the client's 1177 cache, and other stateful mechanisms. Applications are advised to 1178 avoid using session mechanisms unless they are unavoidable or 1179 necessary for operation, in which case these risks needs to be 1180 documented. When they are used, implementations should be encouraged 1181 to allow clearing such state. 1183 Fingerprinting uses unique aspects of a client's messages and 1184 behaviours to connect disparate requests and connections. For 1185 example, the User-Agent request header conveys specific information 1186 about the implementation; the Accept-Language request header conveys 1187 the users' preferred language. In combination, a number of these 1188 markers can be used to uniquely identify a client, impacting its 1189 control over its data. As a result, applications are advised to 1190 specify that clients should only emit the information they need to 1191 function in requests. 1193 Finally, if an application exposes the ability to run mobile code, 1194 great care needs to be taken, since any ability to observe its 1195 environment can be used as an opportunity to both fingerprint the 1196 client and to obtain and manipulate private data (including session 1197 information). For example, access to high-resolution timers (even 1198 indirectly) can be used to profile the underlying hardware, creating 1199 a unique identifier for the system. Applications are advised avoid 1200 allowing the use of mobile code where possible; when it cannot be 1201 avoided, the resulting system's security properties need be carefully 1202 scrutinised. 1204 7. References 1206 7.1. Normative References 1208 [I-D.ietf-httpbis-cache] 1209 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 1210 Caching", draft-ietf-httpbis-cache-03 (work in progress), 1211 October 2018. 1213 [I-D.ietf-httpbis-messaging] 1214 Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1 1215 Messaging", draft-ietf-httpbis-messaging-03 (work in 1216 progress), October 2018. 1218 [I-D.ietf-httpbis-semantics] 1219 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 1220 Semantics", draft-ietf-httpbis-semantics-03 (work in 1221 progress), October 2018. 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, 1225 DOI 10.17487/RFC2119, March 1997, 1226 . 1228 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1229 DOI 10.17487/RFC2818, May 2000, 1230 . 1232 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1233 DOI 10.17487/RFC6454, December 2011, 1234 . 1236 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1237 "Deprecating the "X-" Prefix and Similar Constructs in 1238 Application Protocols", BCP 178, RFC 6648, 1239 DOI 10.17487/RFC6648, June 2012, 1240 . 1242 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1243 Specifications and Registration Procedures", BCP 13, 1244 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1245 . 1247 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1248 "Transport Layer Security (TLS) Application-Layer Protocol 1249 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1250 July 2014, . 1252 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 1253 RFC 7320, DOI 10.17487/RFC7320, July 2014, 1254 . 1256 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1257 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1258 DOI 10.17487/RFC7540, May 2015, 1259 . 1261 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1262 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1263 May 2017, . 1265 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 1266 DOI 10.17487/RFC8288, October 2017, 1267 . 1269 7.2. Informative References 1271 [CSP] West, M., "Content Security Policy Level 3", World Wide 1272 Web Consortium WD WD-CSP3-20160913, September 2016, 1273 . 1275 [FETCH] WHATWG, "Fetch - Living Standard", n.d., 1276 . 1278 [HTML5] WHATWG, "HTML - Living Standard", n.d., 1279 . 1281 [I-D.ietf-httpbis-header-structure] 1282 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 1283 draft-ietf-httpbis-header-structure-07 (work in progress), 1284 July 2018. 1286 [I-D.ietf-httpbis-rfc6265bis] 1287 Barth, A. and M. West, "Cookies: HTTP State Management 1288 Mechanism", draft-ietf-httpbis-rfc6265bis-02 (work in 1289 progress), August 2017. 1291 [I-D.nottingham-rfc5785bis] 1292 Nottingham, M., "Well-Known Uniform Resource Identifiers 1293 (URIs)", draft-nottingham-rfc5785bis-08 (work in 1294 progress), October 2018. 1296 [REFERRER-POLICY] 1297 Eisinger, J. and E. Stark, "Referrer Policy", World Wide 1298 Web Consortium CR CR-referrer-policy-20170126, January 1299 2017, 1300 . 1302 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 1303 RFC 3205, DOI 10.17487/RFC3205, February 2002, 1304 . 1306 [RFC4367] Rosenberg, J., Ed. and IAB, "What's in a Name: False 1307 Assumptions about DNS Names", RFC 4367, 1308 DOI 10.17487/RFC4367, February 2006, 1309 . 1311 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 1312 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 1313 DOI 10.17487/RFC4791, March 2007, 1314 . 1316 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1317 Authoring and Versioning (WebDAV)", RFC 4918, 1318 DOI 10.17487/RFC4918, June 2007, 1319 . 1321 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1322 (TLS) Protocol Version 1.2", RFC 5246, 1323 DOI 10.17487/RFC5246, August 2008, 1324 . 1326 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1327 Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, 1328 . 1330 [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 1331 RFC 6415, DOI 10.17487/RFC6415, October 2011, 1332 . 1334 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1335 Transport Security (HSTS)", RFC 6797, 1336 DOI 10.17487/RFC6797, November 2012, 1337 . 1339 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1340 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1341 October 2013, . 1343 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1344 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1345 2014, . 1347 [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 1348 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, 1349 April 2015, . 1351 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1352 and Registration Procedures for URI Schemes", BCP 35, 1353 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1354 . 1356 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 1357 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 1358 August 2015, . 1360 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1361 Digest Access Authentication", RFC 7616, 1362 DOI 10.17487/RFC7616, September 2015, 1363 . 1365 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1366 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1367 . 1369 [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP 1370 APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, 1371 . 1373 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1374 Interchange Format", STD 90, RFC 8259, 1375 DOI 10.17487/RFC8259, December 2017, 1376 . 1378 [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", 1379 RFC 8297, DOI 10.17487/RFC8297, December 2017, 1380 . 1382 [SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR 1383 CR-secure-contexts-20160915, September 2016, 1384 . 1386 [XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1387 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1388 Edition)", World Wide Web Consortium Recommendation REC- 1389 xml-20081126, November 2008, 1390 . 1392 7.3. URIs 1394 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 1396 [2] http://httpwg.github.io/ 1398 [3] https://github.com/httpwg/http-extensions/labels/bcp56bis 1400 Appendix A. Changes from RFC 3205 1402 [RFC3205] captured the Best Current Practice in the early 2000's, 1403 based on the concerns facing protocol designers at the time. Use of 1404 HTTP has changed considerably since then, and as a result this 1405 document is substantially different. As a result, the changes are 1406 too numerous to list individually. 1408 Author's Address 1410 Mark Nottingham 1412 Email: mnot@mnot.net 1413 URI: https://www.mnot.net/