idnits 2.17.00 (12 Aug 2021) /tmp/idnits58867/draft-ietf-httpbis-bcp56bis-04.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2018) is 1500 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 1241 -- Looks like a reference, but probably isn't: '2' on line 1243 -- Looks like a reference, but probably isn't: '3' on line 1245 ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) == Outdated reference: draft-ietf-httpbis-header-structure has been published as RFC 8941 -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Nottingham 3 Internet-Draft April 11, 2018 4 Obsoletes: 3205 (if approved) 5 Intended status: Best Current Practice 6 Expires: October 13, 2018 8 On the use of HTTP as a Substrate 9 draft-ietf-httpbis-bcp56bis-04 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 these protocols' use of HTTP. 17 This document obsoletes RFC 3205. 19 Note to Readers 21 Discussion of this draft takes place on the HTTP working group 22 mailing list (ietf-http-wg@w3.org), which is archived at 23 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 25 Working Group information can be found at http://httpwg.github.io/ 26 [2]; source code and issues list for this draft can be found at 27 https://github.com/httpwg/http-extensions/labels/bcp56bis [3]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 13, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 65 2. Is HTTP Being Used? . . . . . . . . . . . . . . . . . . . . . 4 66 3. What's Important About HTTP . . . . . . . . . . . . . . . . . 5 67 3.1. Generic Semantics . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3. Rich Functionality . . . . . . . . . . . . . . . . . . . 7 70 4. Best Practices for Using HTTP . . . . . . . . . . . . . . . . 7 71 4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 8 72 4.2. Defining HTTP Resources . . . . . . . . . . . . . . . . . 8 73 4.3. Specifying Client Behaviours . . . . . . . . . . . . . . 9 74 4.4. HTTP URLs . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.4.1. Initial URL Discovery . . . . . . . . . . . . . . . . 11 76 4.4.2. URL Schemes . . . . . . . . . . . . . . . . . . . . . 11 77 4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 12 78 4.5. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 12 79 4.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.5.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.6. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 14 82 4.7. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 16 83 4.8. Defining Message Payloads . . . . . . . . . . . . . . . . 17 84 4.9. HTTP Caching . . . . . . . . . . . . . . . . . . . . . . 17 85 4.10. Application State . . . . . . . . . . . . . . . . . . . . 19 86 4.11. Client Authentication . . . . . . . . . . . . . . . . . . 19 87 4.12. Co-Existing with Web Browsing . . . . . . . . . . . . . . 19 88 4.13. Application Boundaries . . . . . . . . . . . . . . . . . 21 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 93 7.2. Informative References . . . . . . . . . . . . . . . . . 24 94 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 27 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 98 1. Introduction 100 HTTP [RFC7230] is often used as a substrate for other application 101 protocols; this is sometimes referred to as creating "HTTP-based 102 APIs", or just "HTTP APIs", although the latter is ambiguous. This 103 is done for a variety of reasons, including: 105 o familiarity by implementers, specifiers, administrators, 106 developers and users, 108 o availability of a variety of client, server and proxy 109 implementations, 111 o ease of use, 113 o ubiquity of Web browsers, 115 o reuse of existing mechanisms like authentication and encryption, 117 o presence of HTTP servers and clients in target deployments, and 119 o its ability to traverse firewalls. 121 In many cases, these protocols are ad hoc; they are intended for only 122 deployment on the server side, and consumption by a limited set of 123 clients. A body of practices and tools has arisen around defining 124 HTTP-based APIs that favours these conditions. 126 However, when such a protocol is standarised, it is typically 127 deployed on multiple servers, implemented a number of times, and 128 might be consumed by a broader variety of clients. Such diversity 129 brings a different set of concerns, and tools and practices intended 130 for a single-server deployment might not be suitable. 132 In particular, standards-defined HTTP-based APIs need to more 133 carefully consider how extensibility and evolution will be handled, 134 how different deployment requirements will be accommodated, and how 135 clients will evolve with the API. 137 At the same time, the IETF has a tradition of protocol reuse (e.g., 138 [TELNET] as a substrate for [FTP] and [SMTP]; HTTP as a substrate for 139 [IPP] and [RESTCONF]). Because HTTP is extensible in many ways, a 140 number of questions arise, such as: 142 o Should an application using HTTP define a new URL scheme? Use new 143 ports? 145 o Should it use standard HTTP methods and status codes, or define 146 new ones? 148 o How can the maximum value be extracted from the use of HTTP? 150 o How does it coexist with other uses of HTTP - especially Web 151 browsing? 153 o How can interoperability problems and "protocol dead ends" be 154 avoided? 156 This document contains best current practices regarding the use of 157 HTTP by applications other than Web browsing. Section 2 defines what 158 applications it applies to; Section 3 surveys the properties of HTTP 159 that are important to preserve, and Section 4 conveys best practices 160 for those applications that do use HTTP. 162 It is written primarily to guide IETF efforts to define application 163 protocols using HTTP for deployment on the Internet, but might be 164 applicable in other situations. Note that the requirements herein do 165 not necessarily apply to the development of generic HTTP extensions. 167 1.1. Notational Conventions 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 2. Is HTTP Being Used? 177 Different applications have different goals when using HTTP. In this 178 document, we say an application is "using HTTP" when any of the 179 following conditions are true: 181 o The transport port in use is 80 or 443, 183 o The URL scheme "http" or "https" is used, 185 o The ALPN protocol ID [RFC7301] generically identifies HTTP (e.g., 186 "http/1.1", "h2", "h2c"), or 188 o The IANA registries defined for HTTP are updated or modified. 190 When an application is using HTTP, all of the requirements of the 191 HTTP protocol suite are in force (including but not limited to 192 [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], [RFC7235] and 193 [RFC7540]). 195 An application might not be using HTTP according to this definition, 196 but still relying upon the HTTP specifications in some manner. For 197 example, an application might wish to avoid re-specifying parts of 198 the message format, but change others; or, it might want to use a 199 different set of methods. 201 Such applications are referred to as "protocols based upon HTTP" in 202 this document. These have more freedom to modify protocol operation, 203 but are also likely to lose at least a portion of the benefits 204 outlined above, as most HTTP implementations won't be easily 205 adaptable to these changes, and as the protocol diverges from HTTP, 206 the benefit of mindshare will be lost. 208 Protocols that are based upon HTTP MUST NOT reuse HTTP's URL schemes, 209 transport ports, ALPN protocol IDs or IANA registries; rather, they 210 are encouraged to establish their own. 212 3. What's Important About HTTP 214 There are many ways that applications using HTTP are defined and 215 deployed, and sometimes they are brought to the IETF for 216 standardisation. In that process, what might be workable for 217 deployment in a limited fashion isn't appropriate for standardisation 218 and the corresponding broader deployment. 220 This section examines the facets of the protocol that are important 221 to preserve in these situations. 223 3.1. Generic Semantics 225 When writing an application's specification, it's often tempting to 226 specify exactly how HTTP is to be implemented, supported and used. 228 However, this can easily lead to an unintended profile of HTTP's 229 behaviour. For example, it's common to see specifications with 230 language like this: 232 A `POST` request MUST result in a `201 Created` response. 234 This forms an expectation in the client that the response will always 235 be "201 Created", when in fact there are a number of reasons why the 236 status code might differ in a real deployment. If the client does 237 not anticipate this, the application's deployment is brittle. 239 Much of the value of HTTP is in its generic semantics - that is, the 240 protocol elements defined by HTTP are potentially applicable to every 241 resource, not specific to a particular context. Application-specific 242 semantics are expressed in the payload; mostly, in the body, but also 243 in header fields. 245 This allows a HTTP message to be examined by generic HTTP software 246 (e.g., HTTP servers, intermediaries, client implementations), and its 247 handling to be correctly determined. It also allows people to 248 leverage their knowledge of HTTP semantics without special-casing 249 them for a particular application. 251 Therefore, applications that use HTTP MUST NOT re-define, refine or 252 overlay the semantics of defined protocol elements. Instead, they 253 should focus their specifications on protocol elements that are 254 specific to that application; namely their HTTP resources. 256 See Section 4.2 for details. 258 3.2. Links 260 Another common practice is assuming that the HTTP server's name space 261 (or a portion thereof) is exclusively for the use of a single 262 application. This effectively overlays special, application-specific 263 semantics onto that space, precludes other applications from using 264 it. 266 As explained in [RFC7320], such "squatting" on a part of the URL 267 space by a standard usurps the server's authority over its own 268 resources, can cause deployment issues, and is therefore bad practice 269 in standards. 271 Instead of statically defining URL components like paths, it is 272 RECOMMENDED that applications using HTTP define links in payloads, to 273 allow flexibility in deployment. 275 Using runtime links in this fashion has a number of other benefits. 276 For example, navigating with a link allows a request to be routed to 277 a different server without the overhead of a redirection, thereby 278 supporting deployment across machines well. 280 It also becomes possible to "mix" different applications on the same 281 server, and offers a natural mechanism for extensibility, versioning 282 and capability management. 284 3.3. Rich Functionality 286 The simplest possible use of HTTP is to POST data to a single URL, 287 thereby effectively tunnelling through the protocol. 289 This "RPC" style of communication does get some benefit from using 290 HTTP - namely, message framing and the availability of 291 implementations - but fails to realise many others when used 292 exclusively: 294 o Caching for server scalability, latency and bandwidth reduction, 295 and reliability; 297 o Granularity of access control (through use of a rich space of 298 URLs); 300 o Partial content to selectively request part of a response; 302 o Definition of an information space using URLs; and 304 o The ability to interact with the application easily using a Web 305 browser. 307 Using such a high-level protocol to tunnel simple semantics has 308 downsides too; because of its more advanced capabilities, breadth of 309 deployment and age, HTTP's complexity can cause interoperability 310 problems that could be avoided by using a simpler substrate (e.g., 311 WebSockets [RFC6455], if browser support is necessary, or TCP 312 [RFC0793] if not), or making the application be based upon HTTP, 313 instead of using it (as defined in Section 2). 315 Applications that use HTTP are encouraged to accommodate the various 316 features that the protocol offers, so that their users receive the 317 maximum benefit from it. This document does not require specific 318 features to be used, since the appropriate design tradeoffs are 319 highly specific to a given situation. However, following the 320 practices in Section 4 will help make them available. 322 4. Best Practices for Using HTTP 324 This section contains best practices regarding the use of HTTP by 325 applications, including practices for specific HTTP protocol 326 elements. 328 4.1. Specifying the Use of HTTP 330 When specifying the use of HTTP, an application SHOULD use [RFC7230] 331 as the primary reference; it is not necessary to reference all of the 332 specifications in the HTTP suite unless there are specific reasons to 333 do so (e.g., a particular feature is called out). 335 Applications using HTTP MAY specify a minimum version to be supported 336 (HTTP/1.1 is suggested), and MUST NOT specify a maximum version, to 337 preserve the protocol's ability to evolve. 339 Likewise, applications need not specify what HTTP mechanisms - such 340 as redirection, caching, authentication, proxy authentication, and so 341 on - are to be supported. For example, an application can specify 342 that it uses HTTP like this: 344 Foo Application uses HTTP [RFC7230]. Implementations MUST support 345 HTTP/1.1, and MAY support later versions. 347 When specifying examples of protocol interactions, applications 348 SHOULD document both the request and response messages, with full 349 headers, preferably in HTTP/1.1 format. For example: 351 GET /thing HTTP/1.1 352 Host: example.com 353 Accept: application/things+json 354 User-Agent: Foo/1.0 356 HTTP/1.1 200 OK 357 Content-Type: application/things+json 358 Content-Length: 500 359 Server: Bar/2.2 361 [payload here] 363 4.2. Defining HTTP Resources 365 Applications that use HTTP should focus on defining the following 366 application-specific protocol elements: 368 o Media types [RFC6838], often based upon a format convention such 369 as JSON [RFC8259], 371 o HTTP header fields, as per Section 4.7, and 373 o The behaviour of resources, as identified by link relations 374 [RFC8288]. 376 By composing these protocol elements, an application can define a set 377 of resources, identified by link relations, that implement specified 378 behaviours, including: 380 o Retrieval of their state using GET, in one or more formats 381 identified by media type; 383 o Resource creation or update using POST or PUT, with an 384 appropriately identified request body format; 386 o Data processing using POST and identified request and response 387 body format(s); and 389 o Resource deletion using DELETE. 391 For example, an application might specify: 393 Resources linked to with the "example-widget" link relation type are 394 Widgets. The state of a Widget can be fetched in the 395 "application/example-widget+json" format, and can be updated by PUT 396 to the same link. Widget resources can be deleted. 398 The "Example-Count" response header field on Widget representations 399 indicates how many Widgets are held by the sender. 401 The "application/example-widget+json" format is a JSON [RFC8259] 402 format representing the state of a Widget. It contains links to 403 related information in the link indicated by the Link header field 404 value with the "example-other-info" link relation type. 406 4.3. Specifying Client Behaviours 408 HTTP does not mandate some behaviours that have nevertheless become 409 very common; if these are not explicitly specified by applications 410 using HTTP, there may be confusion and interoperability problems. 411 This section recommends default handling for these mechanisms. 413 o Redirect handling - Applications using HTTP SHOULD specify that 414 3xx redirect status codes be followed automatically. See 415 [RFC7231], Section 6.4. 417 o Redirect methods - Applications using HTTP SHOULD specify that 301 418 and 302 redirect status codes rewrite the POST method to GET, in 419 order to be compatible with browsers. See [RFC7231], Section 6.4. 421 o Cookies - Applications using HTTP MUST explicitly reference the 422 Cookie specification [RFC6265] if they are required. 424 o Certificates - Applications using HTTP MUST specify that TLS 425 certificates are to be checked according to [RFC2818] when HTTPS 426 is used. 428 In general, applications using HTTP ought to align their usage as 429 closely as possible with Web browsers, to avoid interoperability 430 issues when they are used. See Section 4.12. 432 If an application using HTTP has browser compatibility as a goal, 433 client interaction ought to be defined in terms of [FETCH], since 434 that is the abstraction that browsers use for HTTP; it enforces many 435 of these best practices. 437 Applications using HTTP MUST NOT require HTTP features that are 438 usually negotiated to be supported. For example, requiring that 439 clients support responses with a certain content-encoding ([RFC7231], 440 Section 3.1.2.2) instead of negotiating for it ([RFC7231], 441 Section 5.3.4) means that otherwise conformant clients cannot 442 interoperate with the application. Applications MAY encourage the 443 implementation of such features, though. 445 4.4. HTTP URLs 447 In HTTP, URLs are opaque identifiers under the control of the server. 448 As outlined in [RFC7320], standards cannot usurp this space, since it 449 might conflict with existing resources, and constrain implementation 450 and deployment. 452 In other words, applications that use HTTP shouldn't associate 453 application semantics with specific URL paths on arbitrary servers. 454 Doing so inappropriately conflates the identity of the resource (its 455 URL) with the capabilities that resource supports, bringing about 456 many of the same interoperability problems that [RFC4367] warns of. 458 For example, specifying that a "GET to the URL /foo retrieves a bar 459 document" is bad practice. Likewise, specifying "The widget API is 460 at the path /bar" violates [RFC7320]. 462 Instead, applications that use HTTP are encouraged to ensure that 463 URLs are discovered at runtime, allowing HTTP-based services to 464 describe their own capabilities. One way to do this is to use typed 465 links [RFC8288] to convey the URIs that are in use, as well as the 466 semantics of the resources that they identify. See Section 4.2 for 467 details. 469 4.4.1. Initial URL Discovery 471 Generally, a client will begin interacting with a given application 472 server by requesting an initial document that contains information 473 about that particular deployment, potentially including links to 474 other relevant resources. 476 Applications that use HTTP are encouraged to allow an arbitrary URL 477 to be used as that entry point. For example, rather than specifying 478 "the initial document is at "/foo/v1", they should allow a deployment 479 to use any URL as the entry point for the application. 481 In cases where doing so is impractical (e.g., it is not possible to 482 convey a whole URL, but only a hostname) standard applications that 483 use HTTP can request a well-known URL [RFC5785] as an entry point. 485 4.4.2. URL Schemes 487 Applications that use HTTP will typically employ the "http" and/or 488 "https" URL schemes. "https" is RECOMMENDED to provide 489 authentication, integrity and confidentiality, as well as mitigate 490 pervasive monitoring attacks [RFC7258]. 492 However, application-specific schemes can be defined as well. 494 When defining an URL scheme for an application using HTTP, there are 495 a number of tradeoffs and caveats to keep in mind: 497 o Unmodified Web browsers will not support the new scheme. While it 498 is possible to register new URL schemes with Web browsers (e.g. 499 registerProtocolHandler() in [HTML5], as well as several 500 proprietary approaches), support for these mechanisms is not 501 shared by all browsers, and their capabilities vary. 503 o Existing non-browser clients, intermediaries, servers and 504 associated software will not recognise the new scheme. For 505 example, a client library might fail to dispatch the request; a 506 cache might refuse to store the response, and a proxy might fail 507 to forward the request. 509 o Because URLs occur in and are generated in HTTP artefacts 510 commonly, often without human intervention (e.g., in the 511 "Location" response header), it can be difficult to assure that 512 the new scheme is used consistently. 514 o The resources identified by the new scheme will still be available 515 using "http" and/or "https" URLs. Those URLs can "leak" into use, 516 which can present security and operability issues. For example, 517 using a new scheme to assure that requests don't get sent to a 518 "normal" Web site is likely to fail. 520 o Features that rely upon the URL's origin [RFC6454], such as the 521 Web's same-origin policy, will be impacted by a change of scheme. 523 o HTTP-specific features such as cookies [RFC6265], authentication 524 [RFC7235], caching [RFC7234], and CORS [FETCH] might or might not 525 work correctly, depending on how they are defined and implemented. 526 Generally, they are designed and implemented with an assumption 527 that the URL will always be "http" or "https". 529 o Web features that require a secure context [SECCTXT] will likely 530 treat a new scheme as insecure. 532 See [RFC7595] for more information about minting new URL schemes. 534 4.4.3. Transport Ports 536 Applications that use HTTP can use the applicable default port (80 537 for HTTP, 443 for HTTPS), or they can be deployed upon other ports. 538 This decision can be made at deployment time, or might be encouraged 539 by the application's specification (e.g., by registering a port for 540 that application). 542 In either case, non-default ports will need to be reflected in the 543 authority of all URLs for that resource; the only mechanism for 544 changing a default port is changing the scheme (see Section 4.4.2). 546 Using a port other than the default has privacy implications (i.e., 547 the protocol can now be distinguished from other traffic), as well as 548 operability concerns (as some networks might block or otherwise 549 interfere with it). Privacy implications should be documented in 550 Security Considerations. 552 See [RFC7605] for further guidance. 554 4.5. HTTP Methods 556 Applications that use HTTP MUST confine themselves to using 557 registered HTTP methods such as GET, POST, PUT, DELETE, and PATCH. 559 New HTTP methods are rare; they are required to be registered with 560 IETF Review (see [RFC7232]), and are also required to be _generic_. 561 That means that they need to be potentially applicable to all 562 resources, not just those of one application. 564 While historically some applications (e.g., [RFC4791]) have defined 565 non-generic methods, [RFC7231] now forbids this. 567 When authors believe that a new method is required, they are 568 encouraged to engage with the HTTP community early, and document 569 their proposal as a separate HTTP extension, rather than as part of 570 an application's specification. 572 4.5.1. GET 574 GET is one of the most common and useful HTTP methods; its retrieval 575 semantics allow caching, side-effect free linking and forms the basis 576 of many of the benefits of using HTTP. 578 A common use of GET is to perform queries, often using the query 579 component of the URL; this is this a familiar pattern from Web 580 browsing, and the results can be cached, improving efficiency of an 581 often expensive process. 583 In some cases, however, GET might be unwieldy for expressing queries, 584 because of the limited syntax of the URL; in particular, if binary 585 data forms part of the query terms, it needs to be encoded to conform 586 to URL syntax. 588 While this is not an issue for short queries, it can become one for 589 larger query terms, or ones which need to sustain a high rate of 590 requests. Additionally, some HTTP implementations limit the size of 591 URLs they support - although modern HTTP software has much more 592 generous limits than previously (typically, considerably more than 593 8000 octets, as required by [RFC7230], Section 3.1.1). 595 In these cases, an application using HTTP might consider using POST 596 to express queries in the request body; doing so avoids encoding 597 overhead and URL length limits in implementations. However, in doing 598 so it should be noted that the benefits of GET such as caching and 599 linking to query results are lost. Therefore, applications using 600 HTTP that feel a need to allow POST queries ought consider allowing 601 both methods. 603 Applications that use HTTP SHOULD NOT define GET requests to have 604 side effects, since implementations can and do retry HTTP GET 605 requests that fail. 607 Finally, note that while HTTP allows GET requests to have a body 608 syntactically, this is done only to allow parsers to be generic; as 609 per [RFC7231], Section 4.3.1, a body on a GET has no meaning, and 610 will be either ignored or rejected by generic HTTP software. 612 4.5.2. OPTIONS 614 The OPTIONS method was defined for metadata retrieval, and is used 615 both by WebDAV [RFC4918] and CORS [FETCH]. Because HTTP-based APIs 616 often need to retrieve metadata about resources, it is often 617 considered for their use. 619 However, OPTIONS does have significant limitations: 621 o It isn't possible to link to the metadata with a simple URL, 622 because OPTIONS is not the default GET method. 624 o OPTIONS responses are not cacheable, because HTTP caches operate 625 on representations of the resource (i.e., GET and HEAD). If 626 OPTIONS responses are cached separately, their interaction with 627 HTTP cache expiry, secondary keys and other mechanisms needs to be 628 considered. 630 o OPTIONS is "chatty" - always separating metadata out into a 631 separate request increases the number of requests needed to 632 interact with the application. 634 o Implementation support for OPTIONS is not universal; some servers 635 do not expose the ability to respond to OPTIONS requests without 636 significant effort. 638 Instead of OPTIONS, one of these alternative approaches might be more 639 appropriate: 641 o For server-wide metadata, create a well-known URI [RFC5785], or 642 using an already existing one if it's appropriate (e.g., HostMeta 643 [RFC6415]). 645 o For metadata about a specific resource, use a Link response 646 header, or a link in the representation format for that resource. 647 See [RFC8288]. Note that the Link header is available on HEAD 648 responses, which is useful if the client wants to discover a 649 resource's capabilities before they interact with it. 651 4.6. HTTP Status Codes 653 The primary function of a HTTP status code is to convey semantics for 654 the benefit of generic HTTP software, not to convey application- 655 specific semantics. 657 In particular, status codes are often generated or overwritten by 658 intermediaries, as well as server and client implementations; for 659 example, when network errors are encountered, a captive portal is 660 present, when an implementation is overloaded, or it thinks it is 661 under attack. As a result, the status code that a server-side 662 application generates and the one that the client software receives 663 often differ. 665 This means that status codes are not a reliable way to carry 666 application-specific signals. Specifying that a particular status 667 code has a specific meaning in the context of an application can have 668 unintended side effects; if that status code is generated by a 669 generic HTTP component can lead clients to believe that the 670 application is in a state that wasn't intended. 672 Instead, applications using HTTP should specify the implications of 673 general classes of responses (e.g., "successful response" for 2xx; 674 "client error" for 4xx and "server error" for 5xx), conveying any 675 application-specific information in the message body and/or HTTP 676 header fields, not the status code. [RFC7807] provides one way for 677 applications using HTTP to do so for error conditions. 679 There are limited exceptions to this; for example, applications might 680 use 201 (Created) or 404 (Not Found) to convey application semantics 681 that are compatible with the generic HTTP semantics of those status 682 codes. In general, though, applications should resist the temptation 683 to map their semantics into fine-grained status codes. 685 Because the set of registered HTTP status codes can expand, 686 applications using HTTP should explicitly point out that clients 687 ought to be able to handle all applicable status codes gracefully 688 (i.e., falling back to the generic "n00" semantics of a given status 689 code; e.g., "499" can be safely handled as "400" by clients that 690 don't recognise it). This is preferable to creating a "laundry list" 691 of potential status codes, since such a list is never complete. 693 Applications using HTTP MUST NOT re-specify the semantics of HTTP 694 status codes, even if it is only by copying their definition. They 695 MUST NOT require specific reason phrases to be used; the reason 696 phrase has no function in HTTP, and is not guaranteed to be preserved 697 by implementations, and the reason phrase is not carried at all in 698 the [RFC7540] message format. 700 Applications that use HTTP MUST only use registered HTTP status 701 codes. As with methods, new HTTP status codes are rare, and required 702 (by [RFC7231]) to be registered with IETF review. Similarly, HTTP 703 status codes are generic; they are required (by [RFC7231]) to be 704 potentially applicable to all resources, not just to those of one 705 application. 707 When authors believe that a new status code is required, they are 708 encouraged to engage with the HTTP community early, and document 709 their proposal as a separate HTTP extension, rather than as part of 710 an application's specification. 712 4.7. HTTP Header Fields 714 Applications that use HTTP MAY define new HTTP header fields. 715 Typically, using HTTP header fields is appropriate in a few different 716 situations: 718 o Their content is useful to intermediaries (who often wish to avoid 719 parsing the body), and/or 721 o Their content is useful to generic HTTP software (e.g., clients, 722 servers), and/or 724 o It is not possible to include their content in the message body 725 (usually because a format does not allow it). 727 New header fields MUST be registered, as per [RFC7231] and [RFC3864]. 729 See [RFC7231], Section 8.3.1 for guidelines to consider when minting 730 new header fields. [I-D.ietf-httpbis-header-structure] provides a 731 common structure for new header fields, and avoids many issues in 732 their parsing and handling; it is RECOMMENDED that new header fields 733 use it. 735 It is RECOMMENDED that header field names be short (even when HTTP/2 736 header compression is in effect, there is an overhead) but 737 appropriately specific. In particular, if a header field is specific 738 to an application, an identifier for that application SHOULD form a 739 prefix to the header field name, separated by a "-". 741 For example, if the "example" application needs to create three 742 headers, they might be called "example-foo", "example-bar" and 743 "example-baz". Note that the primary motivation here is to avoid 744 consuming more generic header names, not to reserve a portion of the 745 namespace for the application; see [RFC6648] for related 746 considerations. 748 The semantics of existing HTTP header fields MUST NOT be re-defined 749 without updating their registration or defining an extension to them 750 (if allowed). For example, an application using HTTP cannot specify 751 that the "Location" header has a special meaning in a certain 752 context. 754 See Section 4.9 for the interaction between headers and HTTP caching; 755 in particular, request headers that are used to "select" a response 756 have impact there, and need to be carefully considered. 758 See Section 4.10 for considerations regarding header fields that 759 carry application state (e.g., Cookie). 761 4.8. Defining Message Payloads 763 There are many potential formats for payloads; for example, JSON 764 [RFC8259], XML [XML], and CBOR [RFC7049]. Best practices for their 765 use are out of scope for this document. 767 Applications SHOULD register distinct media types for each format 768 they define; this makes it possible to identify them unambiguously 769 and negotiate for their use. See [RFC6838] for more information. 771 4.9. HTTP Caching 773 HTTP caching [RFC7234] is one of the primary benefits of using HTTP 774 for applications; it provides scalability, reduces latency and 775 improves reliability. Furthermore, HTTP caches are readily available 776 in browsers and other clients, networks as forward and reverse 777 proxies, Content Delivery Networks and as part of server software. 779 Assigning even a short freshness lifetime ([RFC7234], Section 4.2) - 780 e.g., 5 seconds - allows a response to be reused to satisfy multiple 781 clients, and/or a single client making the same request repeatedly. 782 In general, if it is safe to reuse something, consider assigning a 783 freshness lifetime; cache implementations take active measures to 784 remove content intelligently when they are out of space, so "it will 785 fill up the cache" is not a valid concern. 787 Understand that stale responses (e.g., one with "Cache-Control: max- 788 age=0") can be reused when the cache is disconnected from the origin 789 server; this can be useful for handling network issues. See 790 [RFC7234], Section 4.2.4, and also [RFC5861] for additional controls 791 over stale content. 793 Stale responses can be refreshed by assigning a validator, saving 794 both transfer bandwidth and latency for large responses; see 795 [RFC7232]. 797 If an application defines a request header field that might be used 798 by a server to change the response's headers or body, authors should 799 point out that this has implications for caching; in general, such 800 resources need to either make their responses uncacheable (e.g., with 801 the "no-store" cache-control directive defined in [RFC7234], 802 Section 5.2.2.3) or consistently send the Vary response header 803 ([RFC7231], Section 7.1.4). 805 For example, this response: 807 HTTP/1.1 200 OK 808 Content-Type: application/example+xml 809 Cache-Control: max-age=60 810 ETag: "sa0f8wf20fs0f" 811 Vary: Accept-Encoding 813 [content] 815 can be stored for 60 seconds by both private and shared caches, can 816 be revalidated with If-None-Match, and varies on the Accept-Encoding 817 request header field. 819 In some situations, responses without explicit cache directives 820 (e.g., Cache-Control or Expires) will be stored and served using a 821 heuristic freshness lifetime; see [RFC7234], Section 4.2.2. As the 822 heuristic is not under control of the application, it is generally 823 preferable to set an explicit freshness lifetime. 825 If caching of a response is not desired, the appropriate response 826 directive is "Cache-Control: no-store". This only need be sent in 827 situations where the response might be cached; see [RFC7234], 828 Section 3. Note that "Cache-Control: no-cache" allows a response to 829 be stored, just not reused by a cache; it does not prevent caching 830 (despite its name). 832 For example, this response cannot be stored or reused by a cache: 834 HTTP/1.1 200 OK 835 Content-Type: application/example+xml 836 Cache-Control: no-store 838 [content] 840 When an application has a need to express a lifetime that's separate 841 from the freshness lifetime, this should be expressed separately, 842 either in the response's body or in a separate header field. When 843 this happens, the relationship between HTTP caching and that lifetime 844 need to be carefully considered, since the response will be used as 845 long as it is considered fresh. 847 Like other functions, HTTP caching is generic; it does not have 848 knowledge of the application in use. Therefore, caching extensions 849 need to be backwards-compatible, as per [RFC7234], Section 5.2.3. 851 4.10. Application State 853 Applications that use HTTP MAY use stateful cookies [RFC6265] to 854 identify a client and/or store client-specific data to contextualise 855 requests. 857 When used, it is important to carefully specify the scoping and use 858 of cookies; if the application exposes sensitive data or capabilities 859 (e.g., by acting as an ambient authority), exploits are possible. 860 Mitigations include using a request-specific token to assure the 861 intent of the client. 863 Applications MUST NOT make assumptions about the relationship between 864 separate requests on a single transport connection; doing so breaks 865 many of the assumptions of HTTP as a stateless protocol, and will 866 cause problems in interoperability, security, operability and 867 evolution. 869 4.11. Client Authentication 871 Applications that use HTTP MAY use HTTP authentication [RFC7235] to 872 identify clients. The Basic authentication scheme [RFC7617] MUST NOT 873 be used unless the underlying transport is authenticated, integrity- 874 protected and confidential (e.g., as provided the "HTTPS" URL scheme, 875 or another using TLS). The Digest scheme [RFC7616] MUST NOT be used 876 unless the underlying transport is similarly secure, or the chosen 877 hash algorithm is not "MD5". 879 When used, it is important to carefully specify the scoping and use 880 of authentication; if the application exposes sensitive data or 881 capabilities (e.g., by acting as an ambient authority), exploits are 882 possible. Mitigations include using a request-specific token to 883 assure the intent of the client. 885 4.12. Co-Existing with Web Browsing 887 Even if there is not an intent for an application that uses HTTP to 888 be used with a Web browser, its resources will remain available to 889 browsers and other HTTP clients. 891 This means that all such applications need to consider how browsers 892 will interact with them, particularly regarding security. 894 For example, if an application's state can be changed using a POST 895 request, a Web browser can easily be coaxed into making that request 896 by a HTML form on an arbitrary Web site. 898 Or, If content returned from the application's resources is under 899 control of an attacker (for example, part of the request is reflected 900 in the response, or the response contains external information that 901 might be under the control of the attacker), a cross-site scripting 902 attack is possible, whereby an attacker can inject code into the 903 browser and access data and capabilities on that origin. 905 This is only a small sample of the kinds of issues that applications 906 using HTTP must consider. Generally, the best approach is to 907 consider the application _as_ a Web application, and to follow best 908 practices for their secure development. 910 A complete enumeration of such practices is out of scope for this 911 document, but some considerations include: 913 o Using an application-specific media type in the Content-Type 914 header, and requiring clients to fail if it is not used 916 o Using X-Content-Type-Options: nosniff [FETCH]} to assure that 917 content under attacker control can't be coaxed into a form that is 918 interpreted as active content by a Web browser 920 o Using Content-Security-Policy [CSP] to constrain the capabilities 921 of active content (such as HTML [HTML5]), thereby mitigating 922 Cross-Site Scripting attacks 924 o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data 925 in URLs from being leaked in the Referer request header 927 o Using the 'HttpOnly' flag on Cookies to assure that cookies are 928 not exposed to browser scripting languages [RFC6265] 930 o Avoiding use of compression on any sensitive information (e.g., 931 authentication tokens, passwords), as the scripting environment 932 offered by Web browsers allows an attacker to repeatedly probe the 933 compression space; if the attacker has access to the path of the 934 communication, they can use this capability to recover that 935 information. 937 Depending on how they are intended to be deployed, specifications for 938 applications using HTTP might require the use of these mechanisms in 939 specific ways, or might merely point them out in Security 940 Considerations. 942 An example of a HTTP response from an application that does not 943 intend for its content to be treated as active by browsers might look 944 like this: 946 HTTP/1.1 200 OK 947 Content-Type: application/example+json 948 X-Content-Type-Options: nosniff 949 Content-Security-Policy: default-src 'none' 950 Cache-Control: max-age=3600 951 Referrer-Policy: no-referrer 953 [content] 955 If an application using HTTP has browser compatibility as a goal, 956 client interaction ought to be defined in terms of [FETCH], since 957 that is the abstraction that browsers use for HTTP; it enforces many 958 of these best practices. 960 4.13. Application Boundaries 962 Because the origin [RFC6454] is how many HTTP capabilities are 963 scoped, applications also need to consider how deployments might 964 interact with other applications (including Web browsing) on the same 965 origin. 967 For example, if Cookies [RFC6265] are used to carry application 968 state, they will be sent with all requests to the origin by default, 969 unless scoped by path, and the application might receive cookies from 970 other applications on the origin. This can lead to security issues, 971 as well as collision in cookie names. 973 One solution to these issues is to require a dedicated hostname for 974 the application, so that it has a unique origin. However, it is 975 often desirable to allow multiple applications to be deployed on a 976 single hostname; doing so provides the most deployment flexibility 977 and enables them to be "mixed" together (See [RFC7320] for details). 978 Therefore, applications using HTTP should strive to allow multiple 979 applications on an origin. 981 To enable this, when specifying the use of Cookies, HTTP 982 authentication realms [RFC7235], or other origin-wide HTTP 983 mechanisms, applications using HTTP SHOULD NOT mandate the use of a 984 particular identifier, but instead let deployments configure them. 985 Consideration SHOULD be given to scoping them to part of the origin, 986 using their specified mechanisms for doing so. 988 Modern Web browsers constrain the ability of content from one origin 989 to access resources from another, to avoid leaking private 990 information. As a result, applications that wish to expose cross- 991 origin data to browsers will need to implement the CORS protocol; see 992 [FETCH]. 994 5. IANA Considerations 996 This document has no requirements for IANA. 998 6. Security Considerations 1000 Section 4.10 discusses the impact of using stateful mechanisms in the 1001 protocol as ambient authority, and suggests a mitigation. 1003 Section 4.4.2 requires support for 'https' URLs, and discourages the 1004 use of 'http' URLs, to provide authentication, integrity and 1005 confidentiality, as well as mitigate pervasive monitoring attacks. 1007 Section 4.12 highlights the implications of Web browsers' 1008 capabilities on applications that use HTTP. 1010 Section 4.13 discusses the issues that arise when applications are 1011 deployed on the same origin as Web sites (and other applications). 1013 Applications that use HTTP in a manner that involves modification of 1014 implementations - for example, requiring support for a new URL 1015 scheme, or a non-standard method - risk having those implementations 1016 "fork" from their parent HTTP implementations, with the possible 1017 result that they do not benefit from patches and other security 1018 improvements incorporated upstream. 1020 7. References 1022 7.1. Normative References 1024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1025 Requirement Levels", BCP 14, RFC 2119, 1026 DOI 10.17487/RFC2119, March 1997, 1027 . 1029 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1030 DOI 10.17487/RFC2818, May 2000, 1031 . 1033 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1034 Procedures for Message Header Fields", BCP 90, RFC 3864, 1035 DOI 10.17487/RFC3864, September 2004, 1036 . 1038 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1039 DOI 10.17487/RFC6454, December 2011, 1040 . 1042 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1043 "Deprecating the "X-" Prefix and Similar Constructs in 1044 Application Protocols", BCP 178, RFC 6648, 1045 DOI 10.17487/RFC6648, June 2012, 1046 . 1048 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1049 Specifications and Registration Procedures", BCP 13, 1050 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1051 . 1053 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1054 Protocol (HTTP/1.1): Message Syntax and Routing", 1055 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1056 . 1058 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1059 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1060 DOI 10.17487/RFC7231, June 2014, 1061 . 1063 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1064 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 1065 DOI 10.17487/RFC7232, June 2014, 1066 . 1068 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1069 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1070 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1071 . 1073 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1074 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1075 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1076 . 1078 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1079 Protocol (HTTP/1.1): Authentication", RFC 7235, 1080 DOI 10.17487/RFC7235, June 2014, 1081 . 1083 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1084 "Transport Layer Security (TLS) Application-Layer Protocol 1085 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1086 July 2014, . 1088 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 1089 RFC 7320, DOI 10.17487/RFC7320, July 2014, 1090 . 1092 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1093 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1094 DOI 10.17487/RFC7540, May 2015, 1095 . 1097 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1098 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1099 May 2017, . 1101 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 1102 DOI 10.17487/RFC8288, October 2017, 1103 . 1105 7.2. Informative References 1107 [CSP] West, M., "Content Security Policy Level 3", World Wide 1108 Web Consortium WD WD-CSP3-20160913, September 2016, 1109 . 1111 [FETCH] WHATWG, "Fetch - Living Standard", n.d., 1112 . 1114 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 1115 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 1116 . 1118 [HTML5] WHATWG, "HTML - Living Standard", n.d., 1119 . 1121 [I-D.ietf-httpbis-header-structure] 1122 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 1123 draft-ietf-httpbis-header-structure-04 (work in progress), 1124 March 2018. 1126 [IPP] Sweet, M. and I. McDonald, "Internet Printing 1127 Protocol/1.1: Model and Semantics", RFC 8011, 1128 DOI 10.17487/RFC8011, January 2017, 1129 . 1131 [REFERRER-POLICY] 1132 Eisinger, J. and E. Stark, "Referrer Policy", World Wide 1133 Web Consortium CR CR-referrer-policy-20170126, January 1134 2017, 1135 . 1137 [RESTCONF] 1138 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1139 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1140 . 1142 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1143 RFC 793, DOI 10.17487/RFC0793, September 1981, 1144 . 1146 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 1147 RFC 3205, DOI 10.17487/RFC3205, February 2002, 1148 . 1150 [RFC4367] Rosenberg, J., Ed. and IAB, "What's in a Name: False 1151 Assumptions about DNS Names", RFC 4367, 1152 DOI 10.17487/RFC4367, February 2006, 1153 . 1155 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 1156 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 1157 DOI 10.17487/RFC4791, March 2007, 1158 . 1160 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1161 Authoring and Versioning (WebDAV)", RFC 4918, 1162 DOI 10.17487/RFC4918, June 2007, 1163 . 1165 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1166 Uniform Resource Identifiers (URIs)", RFC 5785, 1167 DOI 10.17487/RFC5785, April 2010, 1168 . 1170 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1171 Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, 1172 . 1174 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1175 DOI 10.17487/RFC6265, April 2011, 1176 . 1178 [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 1179 RFC 6415, DOI 10.17487/RFC6415, October 2011, 1180 . 1182 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1183 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1184 . 1186 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1187 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1188 October 2013, . 1190 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1191 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1192 2014, . 1194 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1195 and Registration Procedures for URI Schemes", BCP 35, 1196 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1197 . 1199 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 1200 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 1201 August 2015, . 1203 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1204 Digest Access Authentication", RFC 7616, 1205 DOI 10.17487/RFC7616, September 2015, 1206 . 1208 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1209 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1210 . 1212 [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP 1213 APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, 1214 . 1216 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1217 Interchange Format", STD 90, RFC 8259, 1218 DOI 10.17487/RFC8259, December 2017, 1219 . 1221 [SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR 1222 CR-secure-contexts-20160915, September 2016, 1223 . 1225 [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", 1226 RFC 2821, DOI 10.17487/RFC2821, April 2001, 1227 . 1229 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 1230 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1231 1983, . 1233 [XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1234 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1235 Edition)", World Wide Web Consortium Recommendation REC- 1236 xml-20081126, November 2008, 1237 . 1239 7.3. URIs 1241 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 1243 [2] http://httpwg.github.io/ 1245 [3] https://github.com/httpwg/http-extensions/labels/bcp56bis 1247 Appendix A. Changes from RFC 3205 1249 [RFC3205] captured the Best Current Practice in the early 2000's, 1250 based on the concerns facing protocol designers at the time. Use of 1251 HTTP has changed considerably since then, and as a result this 1252 document is substantially different. As a result, the changes are 1253 too numerous to list individually. 1255 Author's Address 1257 Mark Nottingham 1259 Email: mnot@mnot.net 1260 URI: https://www.mnot.net/