idnits 2.17.1 draft-ietf-httpbis-bcp56bis-07.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 (October 21, 2018) is 2012 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 1399 -- Looks like a reference, but probably isn't: '2' on line 1401 -- Looks like a reference, but probably isn't: '3' on line 1403 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-07 -- 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 5785 (Obsoleted by RFC 8615) -- 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: 10 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Nottingham 3 Internet-Draft October 21, 2018 4 Obsoletes: 3205 (if approved) 5 Intended status: Best Current Practice 6 Expires: April 24, 2019 8 Building Protocols with HTTP 9 draft-ietf-httpbis-bcp56bis-07 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 April 24, 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 . . . . . . . . . . . . . . . . . . 20 87 4.12. Co-Existing with Web Browsing . . . . . . . . . . . . . . 21 88 4.13. Application Boundaries . . . . . . . . . . . . . . . . . 22 89 4.14. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23 90 4.15. Versioning and Evolution . . . . . . . . . . . . . . . . 24 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 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 [RFC7230] is often used as a substrate for applications other 104 than Web browsing; this is sometimes referred to as creating "HTTP- 105 based APIs", or just "HTTP APIs". This is done for a variety of 106 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 For example, because implementations (both client and server) will 137 implement and evolve at different paces, a HTTP-based API might need 138 to more carefully consider how extensibility of the service will be 139 handled, and how different deployment requirements will be 140 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. In this 180 document, we say an application is "using HTTP" when any of the 181 following 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 [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], [RFC7235] and 195 [RFC7540]). 197 An application might not be using HTTP according to this definition, 198 but still relying upon the HTTP specifications in some manner. For 199 example, an application might wish to avoid re-specifying parts of 200 the message format, but change others; or, it might want to use a 201 different set 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 There are many ways that applications using HTTP are defined and 217 deployed, and sometimes they are brought to the IETF for 218 standardisation. In that process, what might be workable for 219 deployment in a limited fashion isn't appropriate for standardisation 220 and the corresponding broader 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 an application's specification, it's often tempting to 228 specify exactly 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 HTTP software 248 (e.g., HTTP servers, intermediaries, client implementations), and its 249 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 [RFC7230] 340 as the primary reference; it is not necessary to reference all of the 341 specifications in the HTTP suite unless there are specific reasons to 342 do so (e.g., a particular feature is called out). 344 Applications using HTTP SHOULD NOT specify a minimum version of HTTP 345 to be used; because it is a hop-by-hop protocol, a HTTP connection 346 can be handled by implementations that are not controlled by the 347 application; for example, proxies, CDNs, firewalls and so on. 348 Requiring a particular version of HTTP makes it difficult to use in 349 these situations, and harms interoperability for little reason (since 350 HTTP's semantics are stable between protocol versions). 352 However, if an application's deployment would benefit from the use of 353 a particular version of HTTP (for example, HTTP/2's multiplexing), 354 this SHOULD be noted. 356 Applications using HTTP MUST NOT specify a maximum version, to 357 preserve the protocol's ability to evolve. 359 When specifying examples of protocol interactions, applications 360 SHOULD document both the request and response messages, with full 361 headers, preferably in HTTP/1.1 format. For example: 363 GET /thing HTTP/1.1 364 Host: example.com 365 Accept: application/things+json 366 User-Agent: Foo/1.0 368 HTTP/1.1 200 OK 369 Content-Type: application/things+json 370 Content-Length: 500 371 Server: Bar/2.2 373 [payload here] 375 4.2. Defining HTTP Resources 377 Applications that use HTTP should focus on defining the following 378 application-specific protocol elements: 380 o Media types [RFC6838], often based upon a format convention such 381 as JSON [RFC8259], 383 o HTTP header fields, as per Section 4.7, and 385 o The behaviour of resources, as identified by link relations 386 [RFC8288]. 388 By composing these protocol elements, an application can define a set 389 of resources, identified by link relations, that implement specified 390 behaviours, including: 392 o Retrieval of their state using GET, in one or more formats 393 identified by media type; 395 o Resource creation or update using POST or PUT, with an 396 appropriately identified request body format; 398 o Data processing using POST and identified request and response 399 body format(s); and 401 o Resource deletion using DELETE. 403 For example, an application might specify: 405 Resources linked to with the "example-widget" link relation type are 406 Widgets. The state of a Widget can be fetched in the 407 "application/example-widget+json" format, and can be updated by PUT 408 to the same link. Widget resources can be deleted. 410 The "Example-Count" response header field on Widget representations 411 indicates how many Widgets are held by the sender. 413 The "application/example-widget+json" format is a JSON [RFC8259] 414 format representing the state of a Widget. It contains links to 415 related information in the link indicated by the Link header field 416 value with the "example-other-info" link relation type. 418 4.3. Specifying Client Behaviours 420 HTTP does not mandate some behaviours that have nevertheless become 421 very common; if these are not explicitly specified by applications 422 using HTTP, there may be confusion and interoperability problems. 423 This section recommends default handling for these mechanisms. 425 o Redirect handling - Applications need to specify how redirects are 426 expected to be handled; see Section 4.6.1. 428 o Cookies - Applications using HTTP MUST explicitly reference the 429 Cookie specification [RFC6265] if they are required. 431 o Certificates - Applications using HTTP MUST specify that TLS 432 certificates are to be checked according to [RFC2818] when HTTPS 433 is used. 435 In general, applications using HTTP ought to align their usage as 436 closely as possible with Web browsers, to avoid interoperability 437 issues when they are used. See Section 4.12. 439 If an application using HTTP has browser compatibility as a goal, 440 client interaction ought to be defined in terms of [FETCH], since 441 that is the abstraction that browsers use for HTTP; it enforces many 442 of these best practices. 444 Applications using HTTP MUST NOT require HTTP features that are 445 usually negotiated to be supported. For example, requiring that 446 clients support responses with a certain content-encoding ([RFC7231], 447 Section 3.1.2.2) instead of negotiating for it ([RFC7231], 448 Section 5.3.4) means that otherwise conformant clients cannot 449 interoperate with the application. Applications MAY encourage the 450 implementation of such features, though. 452 4.4. HTTP URLs 454 In HTTP, URLs are opaque identifiers under the control of the server. 455 As outlined in [RFC7320], standards cannot usurp this space, since it 456 might conflict with existing resources, and constrain implementation 457 and deployment. 459 In other words, applications that use HTTP shouldn't associate 460 application semantics with specific URL paths on arbitrary servers. 461 Doing so inappropriately conflates the identity of the resource (its 462 URL) with the capabilities that resource supports, bringing about 463 many of the same interoperability problems that [RFC4367] warns of. 465 For example, specifying that a "GET to the URL /foo retrieves a bar 466 document" is bad practice. Likewise, specifying "The widget API is 467 at the path /bar" violates [RFC7320]. 469 Instead, applications that use HTTP are encouraged to ensure that 470 URLs are discovered at runtime, allowing HTTP-based services to 471 describe their own capabilities. One way to do this is to use typed 472 links [RFC8288] to convey the URIs that are in use, as well as the 473 semantics of the resources that they identify. See Section 4.2 for 474 details. 476 4.4.1. Initial URL Discovery 478 Generally, a client will begin interacting with a given application 479 server by requesting an initial document that contains information 480 about that particular deployment, potentially including links to 481 other relevant resources. 483 Applications that use HTTP are encouraged to allow an arbitrary URL 484 to be used as that entry point. For example, rather than specifying 485 "the initial document is at "/foo/v1", they should allow a deployment 486 to use any URL as the entry point for the application. 488 In cases where doing so is impractical (e.g., it is not possible to 489 convey a whole URL, but only a hostname) standard applications that 490 use HTTP can request a well-known URL [RFC5785] as an entry point. 492 4.4.2. URL Schemes 494 Applications that use HTTP will typically employ the "http" and/or 495 "https" URL schemes. "https" is RECOMMENDED to provide 496 authentication, integrity and confidentiality, as well as mitigate 497 pervasive monitoring attacks [RFC7258]. 499 However, application-specific schemes can be defined as well. 501 When defining an URL scheme for an application using HTTP, there are 502 a number of tradeoffs and caveats to keep in mind: 504 o Unmodified Web browsers will not support the new scheme. While it 505 is possible to register new URL schemes with Web browsers (e.g. 506 registerProtocolHandler() in [HTML5], as well as several 507 proprietary approaches), support for these mechanisms is not 508 shared by all browsers, and their capabilities vary. 510 o Existing non-browser clients, intermediaries, servers and 511 associated software will not recognise the new scheme. For 512 example, a client library might fail to dispatch the request; a 513 cache might refuse to store the response, and a proxy might fail 514 to forward the request. 516 o Because URLs occur in HTTP artefacts commonly, often being 517 generated automatically (e.g., in the "Location" response header), 518 it can be difficult to assure that the new scheme is used 519 consistently. 521 o The resources identified by the new scheme will still be available 522 using "http" and/or "https" URLs. Those URLs can "leak" into use, 523 which can present security and operability issues. For example, 524 using a new scheme to assure that requests don't get sent to a 525 "normal" Web site is likely to fail. 527 o Features that rely upon the URL's origin [RFC6454], such as the 528 Web's same-origin policy, will be impacted by a change of scheme. 530 o HTTP-specific features such as cookies [RFC6265], authentication 531 [RFC7235], caching [RFC7234], HSTS [RFC6797], and CORS [FETCH] 532 might or might not work correctly, depending on how they are 533 defined and implemented. Generally, they are designed and 534 implemented with an assumption that the URL will always be "http" 535 or "https". 537 o Web features that require a secure context [SECCTXT] will likely 538 treat a new scheme as insecure. 540 See [RFC7595] for more information about minting new URL schemes. 542 4.4.3. Transport Ports 544 Applications that use HTTP can use the applicable default port (80 545 for HTTP, 443 for HTTPS), or they can be deployed upon other ports. 546 This decision can be made at deployment time, or might be encouraged 547 by the application's specification (e.g., by registering a port for 548 that application). 550 If a non-default port is used, it needs to be reflected in the 551 authority of all URLs for that resource; the only mechanism for 552 changing a default port is changing the scheme (see Section 4.4.2). 554 Using a port other than the default has privacy implications (i.e., 555 the protocol can now be distinguished from other traffic), as well as 556 operability concerns (as some networks might block or otherwise 557 interfere with it). Privacy implications should be documented in 558 Security Considerations. 560 See [RFC7605] for further guidance. 562 4.5. HTTP Methods 564 Applications that use HTTP MUST confine themselves to using 565 registered HTTP methods such as GET, POST, PUT, DELETE, and PATCH. 567 New HTTP methods are rare; they are required to be registered in the 568 HTTP Method Registry with IETF Review (see [RFC7231]), and are also 569 required to be generic. That means that they need to be potentially 570 applicable to all resources, not just those of one application. 572 While historically some applications (e.g., [RFC4791]) have defined 573 non-generic methods, [RFC7231] now forbids this. 575 When authors believe that a new method is required, they are 576 encouraged to engage with the HTTP community early, and document 577 their proposal as a separate HTTP extension, rather than as part of 578 an application's specification. 580 4.5.1. GET 582 GET is one of the most common and useful HTTP methods; its retrieval 583 semantics allow caching, side-effect free linking and forms the basis 584 of many of the benefits of using HTTP. 586 A common use of GET is to perform queries, often using the query 587 component of the URL; this is a familiar pattern from Web browsing, 588 and the results can be cached, improving efficiency of an often 589 expensive process. 591 In some cases, however, GET might be unwieldy for expressing queries, 592 because of the limited syntax of the URL; in particular, if binary 593 data forms part of the query terms, it needs to be encoded to conform 594 to URL syntax. 596 While this is not an issue for short queries, it can become one for 597 larger query terms, or ones which need to sustain a high rate of 598 requests. Additionally, some HTTP implementations limit the size of 599 URLs they support - although modern HTTP software has much more 600 generous limits than previously (typically, considerably more than 601 8000 octets, as required by [RFC7230], Section 3.1.1). 603 In these cases, an application using HTTP might consider using POST 604 to express queries in the request body; doing so avoids encoding 605 overhead and URL length limits in implementations. However, in doing 606 so it should be noted that the benefits of GET such as caching and 607 linking to query results are lost. Therefore, applications using 608 HTTP that feel a need to allow POST queries ought consider allowing 609 both methods. 611 Applications that use HTTP SHOULD NOT define GET requests to have 612 side effects, since implementations can and do retry HTTP GET 613 requests that fail. 615 Finally, note that while HTTP allows GET requests to have a body 616 syntactically, this is done only to allow parsers to be generic; as 617 per [RFC7231], Section 4.3.1, a body on a GET has no meaning, and 618 will be either ignored or rejected by generic HTTP software. 620 4.5.2. OPTIONS 622 The OPTIONS method was defined for metadata retrieval, and is used 623 both by WebDAV [RFC4918] and CORS [FETCH]. Because HTTP-based APIs 624 often need to retrieve metadata about resources, it is often 625 considered for their use. 627 However, OPTIONS does have significant limitations: 629 o It isn't possible to link to the metadata with a simple URL, 630 because OPTIONS is not the default GET method. 632 o OPTIONS responses are not cacheable, because HTTP caches operate 633 on representations of the resource (i.e., GET and HEAD). If 634 OPTIONS responses are cached separately, their interaction with 635 HTTP cache expiry, secondary keys and other mechanisms needs to be 636 considered. 638 o OPTIONS is "chatty" - always separating metadata out into a 639 separate request increases the number of requests needed to 640 interact with the application. 642 o Implementation support for OPTIONS is not universal; some servers 643 do not expose the ability to respond to OPTIONS requests without 644 significant effort. 646 Instead of OPTIONS, one of these alternative approaches might be more 647 appropriate: 649 o For server-wide metadata, create a well-known URI [RFC5785], or 650 using an already existing one if it's appropriate (e.g., HostMeta 651 [RFC6415]). 653 o For metadata about a specific resource, create a separate resource 654 and link to it using a Link response header or a link serialised 655 into the representation's body. See [RFC8288]. Note that the 656 Link header is available on HEAD responses, which is useful if the 657 client wants to discover a resource's capabilities before they 658 interact with it. 660 4.6. HTTP Status Codes 662 The primary function of a HTTP status code is to convey semantics for 663 the benefit of generic HTTP software, not to convey application- 664 specific semantics. 666 In particular, status codes are often generated or overwritten by 667 intermediaries, as well as server and client implementations; for 668 example, when network errors are encountered, a captive portal is 669 present, when an implementation is overloaded, or it thinks it is 670 under attack. As a result, the status code that a server-side 671 application generates and the one that the client software receives 672 often differ. 674 This means that status codes are not a reliable way to carry 675 application-specific signals. Specifying that a particular status 676 code has a specific meaning in the context of an application can have 677 unintended side effects; if that status code is generated by a 678 generic HTTP component can lead clients to believe that the 679 application is in a state that wasn't intended. 681 Instead, applications using HTTP should specify the implications of 682 general classes of responses (e.g., "successful response" for 2xx; 683 "client error" for 4xx and "server error" for 5xx), conveying any 684 application-specific information in the message body and/or HTTP 685 header fields, not the status code. [RFC7807] provides one way for 686 applications using HTTP to do so for error conditions. 688 There are limited exceptions to this; for example, applications might 689 use 201 (Created) or 404 (Not Found) to convey application semantics 690 that are compatible with the generic HTTP semantics of those status 691 codes. In general, though, applications should resist the temptation 692 to map their semantics into fine-grained status codes. 694 Because the set of registered HTTP status codes can expand, 695 applications using HTTP should explicitly point out that clients 696 ought to be able to handle all applicable status codes gracefully 697 (i.e., falling back to the generic "n00" semantics of a given status 698 code; e.g., "499" can be safely handled as "400" by clients that 699 don't recognise it). This is preferable to creating a "laundry list" 700 of potential status codes, since such a list is never complete. 702 Applications using HTTP MUST NOT re-specify the semantics of HTTP 703 status codes, even if it is only by copying their definition. They 704 MUST NOT require specific reason phrases to be used; the reason 705 phrase has no function in HTTP, and is not guaranteed to be preserved 706 by implementations, and the reason phrase is not carried at all in 707 the [RFC7540] message format. 709 Applications that use HTTP MUST only use registered HTTP status 710 codes. As with methods, new HTTP status codes are rare, and required 711 (by [RFC7231]) to be registered with IETF review. Similarly, HTTP 712 status codes are generic; they are required (by [RFC7231]) to be 713 potentially applicable to all resources, not just to those of one 714 application. 716 When authors believe that a new status code is required, they are 717 encouraged to engage with the HTTP community early, and document 718 their proposal as a separate HTTP extension, rather than as part of 719 an application's specification. 721 4.6.1. Redirection 723 The 3xx series of status codes specified in [RFC7231], Section 6.4 724 are used to direct the user agent to another resource to satisfy the 725 request. The most common of these are 301, 302, 307 and 308 726 ([RFC7538]), all of which use the Location response header field to 727 indicate where the client should send the request to. 729 There are two ways that this group of status codes differ: 731 o Whether they are permanent or temporary. Permanent redirects can 732 be used to update links stored in the client (e.g., bookmarks), 733 whereas temporary ones can not. Note that this has no effect on 734 HTTP caching; it is completely separate. 736 o Whether they allow the redirected request to change the request 737 method from POST to GET. Web browsers generally do change POST to 738 GET for 301 and 302; therefore, 308 and 307 were created to allow 739 redirection without changing the method. 741 This table summarises their relationships: 743 +-------------------------------------------+-----------+-----------+ 744 | | Permanent | Temporary | 745 +-------------------------------------------+-----------+-----------+ 746 | Allows changing the request method from | 301 | 302 | 747 | POST to GET | | | 748 | Does not allow changing the request | 308 | 307 | 749 | method | | | 750 +-------------------------------------------+-----------+-----------+ 752 As noted in [RFC7231], a user agent is allowed to automatically 753 follow a 3xx redirect that has a Location response header field, even 754 if they don't understand the semantics of the specific status code. 755 However, they aren't required to do so; therefore, if an application 756 using HTTP desires redirects to be automatically followed, it needs 757 to explicitly specify the circumstances when this is required. 759 Applications using HTTP SHOULD specify that 301 and 302 responses 760 change the subsequent request method from POST (but no other method) 761 to GET, to be compatible with browsers. 763 Generally, when a redirected request is made, its header fields are 764 copied from the original request's. However, they can be modified by 765 various mechanisms; e.g., sent Authorization ([RFC7235]) and Cookie 766 ([RFC6265]) headers will change if the origin (and sometimes path) of 767 the request changes. Applications using HTTP SHOULD specify if any 768 request headers need to be modified or removed upon a redirect; 769 however, this behaviour cannot be relied upon, since a generic client 770 (like a browser) will be unaware of such requirements. 772 4.7. HTTP Header Fields 774 Applications that use HTTP MAY define new HTTP header fields. 775 Typically, using HTTP header fields is appropriate in a few different 776 situations: 778 o Their content is useful to intermediaries (who often wish to avoid 779 parsing the body), and/or 781 o Their content is useful to generic HTTP software (e.g., clients, 782 servers), and/or 784 o It is not possible to include their content in the message body 785 (usually because a format does not allow it). 787 New header fields MUST be registered, as per [RFC7231] and [RFC3864]. 789 See [RFC7231], Section 8.3.1 for guidelines to consider when minting 790 new header fields. [I-D.ietf-httpbis-header-structure] provides a 791 common structure for new header fields, and avoids many issues in 792 their parsing and handling; it is RECOMMENDED that new header fields 793 use it. 795 It is RECOMMENDED that header field names be short (even when HTTP/2 796 header compression is in effect, there is an overhead) but 797 appropriately specific. In particular, if a header field is specific 798 to an application, an identifier for that application SHOULD form a 799 prefix to the header field name, separated by a "-". 801 For example, if the "example" application needs to create three 802 headers, they might be called "example-foo", "example-bar" and 803 "example-baz". Note that the primary motivation here is to avoid 804 consuming more generic header names, not to reserve a portion of the 805 namespace for the application; see [RFC6648] for related 806 considerations. 808 The semantics of existing HTTP header fields MUST NOT be re-defined 809 without updating their registration or defining an extension to them 810 (if allowed). For example, an application using HTTP cannot specify 811 that the "Location" header has a special meaning in a certain 812 context. 814 See Section 4.9 for the interaction between headers and HTTP caching; 815 in particular, request headers that are used to "select" a response 816 have impact there, and need to be carefully considered. 818 See Section 4.10 for considerations regarding header fields that 819 carry application state (e.g., Cookie). 821 4.8. Defining Message Payloads 823 There are many potential formats for payloads; for example, JSON 824 [RFC8259], XML [XML], and CBOR [RFC7049]. Best practices for their 825 use are out of scope for this document. 827 Applications SHOULD register distinct media types for each format 828 they define; this makes it possible to identify them unambiguously 829 and negotiate for their use. See [RFC6838] for more information. 831 4.9. HTTP Caching 833 HTTP caching [RFC7234] is one of the primary benefits of using HTTP 834 for applications; it provides scalability, reduces latency and 835 improves reliability. Furthermore, HTTP caches are readily available 836 in browsers and other clients, networks as forward and reverse 837 proxies, Content Delivery Networks and as part of server software. 839 Assigning even a short freshness lifetime ([RFC7234], Section 4.2) - 840 e.g., 5 seconds - allows a response to be reused to satisfy multiple 841 clients, and/or a single client making the same request repeatedly. 842 In general, if it is safe to reuse something, consider assigning a 843 freshness lifetime; cache implementations take active measures to 844 remove content intelligently when they are out of space, so "it will 845 fill up the cache" is not a valid concern. 847 The most common method for specifying freshness is the max-age 848 response directive ([RFC7234], Section 5.2.2.8). The Expires header 849 ([RFC7234], Section 5.3) can also be used, but it is not necessary to 850 specify it; all modern cache implementations support Cache-Control, 851 and specifying freshness as a delta is both more convenient in most 852 cases, and less error-prone. 854 Understand that stale responses (e.g., one with "Cache-Control: max- 855 age=0") can be reused when the cache is disconnected from the origin 856 server; this can be useful for handling network issues. See 857 [RFC7234], Section 4.2.4, and also [RFC5861] for additional controls 858 over stale content. 860 Stale responses can be refreshed by assigning a validator, saving 861 both transfer bandwidth and latency for large responses; see 862 [RFC7232]. 864 If an application defines a request header field that might be used 865 by a server to change the response's headers or body, authors should 866 point out that this has implications for caching; in general, such 867 resources need to either make their responses uncacheable (e.g., with 868 the "no-store" cache-control directive defined in [RFC7234], 869 Section 5.2.2.3) or consistently send the Vary response header 870 ([RFC7231], Section 7.1.4). 872 For example, this response: 874 HTTP/1.1 200 OK 875 Content-Type: application/example+xml 876 Cache-Control: max-age=60 877 ETag: "sa0f8wf20fs0f" 878 Vary: Accept-Encoding 880 [content] 882 can be stored for 60 seconds by both private and shared caches, can 883 be revalidated with If-None-Match, and varies on the Accept-Encoding 884 request header field. 886 In some situations, responses without explicit cache directives 887 (e.g., Cache-Control or Expires) will be stored and served using a 888 heuristic freshness lifetime; see [RFC7234], Section 4.2.2. As the 889 heuristic is not under control of the application, it is generally 890 preferable to set an explicit freshness lifetime. 892 If caching of a response is not desired, the appropriate response 893 directive is "Cache-Control: no-store". This only need be sent in 894 situations where the response might be cached; see [RFC7234], 895 Section 3. Note that "Cache-Control: no-cache" allows a response to 896 be stored, just not reused by a cache; it does not prevent caching 897 (despite its name). 899 For example, this response cannot be stored or reused by a cache: 901 HTTP/1.1 200 OK 902 Content-Type: application/example+xml 903 Cache-Control: no-store 905 [content] 907 When an application has a need to express a lifetime that's separate 908 from the freshness lifetime, this should be expressed separately, 909 either in the response's body or in a separate header field. When 910 this happens, the relationship between HTTP caching and that lifetime 911 need to be carefully considered, since the response will be used as 912 long as it is considered fresh. 914 Like other functions, HTTP caching is generic; it does not have 915 knowledge of the application in use. Therefore, caching extensions 916 need to be backwards-compatible, as per [RFC7234], Section 5.2.3. 918 4.10. Application State 920 Applications that use HTTP MAY use stateful cookies [RFC6265] to 921 identify a client and/or store client-specific data to contextualise 922 requests. 924 When used, it is important to carefully specify the scoping and use 925 of cookies; if the application exposes sensitive data or capabilities 926 (e.g., by acting as an ambient authority), exploits are possible. 927 Mitigations include using a request-specific token to assure the 928 intent of the client. 930 Applications MUST NOT make assumptions about the relationship between 931 separate requests on a single transport connection; doing so breaks 932 many of the assumptions of HTTP as a stateless protocol, and will 933 cause problems in interoperability, security, operability and 934 evolution. 936 4.11. Client Authentication 938 Applications that use HTTP MAY use HTTP authentication [RFC7235] to 939 identify clients. The Basic authentication scheme [RFC7617] MUST NOT 940 be used unless the underlying transport is authenticated, integrity- 941 protected and confidential (e.g., as provided the "HTTPS" URL scheme, 942 or another using TLS). The Digest scheme [RFC7616] MUST NOT be used 943 unless the underlying transport is similarly secure, or the chosen 944 hash algorithm is not "MD5". 946 With HTTPS, clients might also be authenticated using certificates 947 [RFC5246]. 949 When used, it is important to carefully specify the scoping and use 950 of authentication; if the application exposes sensitive data or 951 capabilities (e.g., by acting as an ambient authority), exploits are 952 possible. Mitigations include using a request-specific token to 953 assure the intent of the client. 955 4.12. Co-Existing with Web Browsing 957 Even if there is not an intent for an application that uses HTTP to 958 be used with a Web browser, its resources will remain available to 959 browsers and other HTTP clients. 961 This means that all such applications need to consider how browsers 962 will interact with them, particularly regarding security. 964 For example, if an application's state can be changed using a POST 965 request, a Web browser can easily be coaxed into cross-site request 966 forgery (CSRF) from arbitrary Web sites. 968 Or, If content returned from the application's resources is under 969 control of an attacker (for example, part of the request is reflected 970 in the response, or the response contains external information that 971 might be under the control of the attacker), a cross-site scripting 972 (XSS) attack is possible, whereby an attacker can inject code into 973 the browser and access data and capabilities on that origin. 975 This is only a small sample of the kinds of issues that applications 976 using HTTP must consider. Generally, the best approach is to 977 consider the application actually as a Web application, and to follow 978 best practices for their secure development. 980 A complete enumeration of such practices is out of scope for this 981 document, but some considerations include: 983 o Using an application-specific media type in the Content-Type 984 header, and requiring clients to fail if it is not used 986 o Using X-Content-Type-Options: nosniff [FETCH] to assure that 987 content under attacker control can't be coaxed into a form that is 988 interpreted as active content by a Web browser 990 o Using Content-Security-Policy [CSP] to constrain the capabilities 991 of active content (such as HTML [HTML5]), thereby mitigating 992 Cross-Site Scripting attacks 994 o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data 995 in URLs from being leaked in the Referer request header 997 o Using the 'HttpOnly' flag on Cookies to assure that cookies are 998 not exposed to browser scripting languages [RFC6265] 1000 o Avoiding use of compression on any sensitive information (e.g., 1001 authentication tokens, passwords), as the scripting environment 1002 offered by Web browsers allows an attacker to repeatedly probe the 1003 compression space; if the attacker has access to the path of the 1004 communication, they can use this capability to recover that 1005 information. 1007 Depending on how they are intended to be deployed, specifications for 1008 applications using HTTP might require the use of these mechanisms in 1009 specific ways, or might merely point them out in Security 1010 Considerations. 1012 An example of a HTTP response from an application that does not 1013 intend for its content to be treated as active by browsers might look 1014 like this: 1016 HTTP/1.1 200 OK 1017 Content-Type: application/example+json 1018 X-Content-Type-Options: nosniff 1019 Content-Security-Policy: default-src 'none' 1020 Cache-Control: max-age=3600 1021 Referrer-Policy: no-referrer 1023 [content] 1025 If an application using HTTP has browser compatibility as a goal, 1026 client interaction ought to be defined in terms of [FETCH], since 1027 that is the abstraction that browsers use for HTTP; it enforces many 1028 of these best practices. 1030 4.13. Application Boundaries 1032 Because the origin [RFC6454] is how many HTTP capabilities are 1033 scoped, applications also need to consider how deployments might 1034 interact with other applications (including Web browsing) on the same 1035 origin. 1037 For example, if Cookies [RFC6265] are used to carry application 1038 state, they will be sent with all requests to the origin by default, 1039 unless scoped by path, and the application might receive cookies from 1040 other applications on the origin. This can lead to security issues, 1041 as well as collision in cookie names. 1043 One solution to these issues is to require a dedicated hostname for 1044 the application, so that it has a unique origin. However, it is 1045 often desirable to allow multiple applications to be deployed on a 1046 single hostname; doing so provides the most deployment flexibility 1047 and enables them to be "mixed" together (See [RFC7320] for details). 1048 Therefore, applications using HTTP should strive to allow multiple 1049 applications on an origin. 1051 To enable this, when specifying the use of Cookies, HTTP 1052 authentication realms [RFC7235], or other origin-wide HTTP 1053 mechanisms, applications using HTTP SHOULD NOT mandate the use of a 1054 particular name, but instead let deployments configure them. 1055 Consideration SHOULD be given to scoping them to part of the origin, 1056 using their specified mechanisms for doing so. 1058 Modern Web browsers constrain the ability of content from one origin 1059 to access resources from another, to avoid leaking private 1060 information. As a result, applications that wish to expose cross- 1061 origin data to browsers will need to implement the CORS protocol; see 1062 [FETCH]. 1064 4.14. Server Push 1066 HTTP/2 adds the ability for servers to "push" request/response pairs 1067 to clients in [RFC7540], Section 8.2. While server push seems like a 1068 natural fit for many common application semantics (e.g., "fanout" and 1069 publish/subscribe), a few caveats should be noted: 1071 o Server push is hop-by-hop; that is, it is not automatically 1072 forwarded by intermediaries. As a result, it might not work 1073 easily (or at all) with proxies, reverse proxies, and Content 1074 Delivery Networks. 1076 o Server push can have negative performance impact on HTTP when used 1077 incorrectly; in particular, if there is contention with resources 1078 that have actually been requested by the client. 1080 o Server push is implemented differently in different clients, 1081 especially regarding interaction with HTTP caching, and 1082 capabilities might vary. 1084 o APIs for server push are currently unavailable in some 1085 implementations, and vary widely in others. In particular, there 1086 is no current browser API for it. 1088 o Server push is not supported in HTTP/1.1 or HTTP/1.0. 1090 o Server push does not form part of the "core" semantics of HTTP, 1091 and therefore might not be supported by future versions of the 1092 protocol. 1094 Applications wishing to optimise cases where the client can perform 1095 work related to requests before the full response is available (e.g., 1096 fetching links for things likely to be contained within) might 1097 benefit from using the 103 (Early Hints) status code; see [RFC8297]. 1099 Applications using server push directly need to enforce the 1100 requirements regarding authority in [RFC7540], Section 8.2, to avoid 1101 cross-origin push attacks. 1103 4.15. Versioning and Evolution 1105 It's often necessary to introduce new features into application 1106 protocols, and change existing ones. 1108 In HTTP, backwards-incompatible changes are possible using a number 1109 of mechanisms: 1111 o Using a distinct link relation type [RFC8288] to identify a URL 1112 for a resource that implements the new functionality 1114 o Using a distinct media type [RFC6838] to identify formats that 1115 enable the new functionality 1117 o Using a distinct HTTP header field to implement new functionality 1118 outside the message body 1120 5. IANA Considerations 1122 This document has no requirements for IANA. 1124 6. Security Considerations 1126 Section 4.10 discusses the impact of using stateful mechanisms in the 1127 protocol as ambient authority, and suggests a mitigation. 1129 Section 4.4.2 requires support for 'https' URLs, and discourages the 1130 use of 'http' URLs, to provide authentication, integrity and 1131 confidentiality, as well as mitigate pervasive monitoring attacks. 1133 Section 4.12 highlights the implications of Web browsers' 1134 capabilities on applications that use HTTP. 1136 Section 4.13 discusses the issues that arise when applications are 1137 deployed on the same origin as Web sites (and other applications). 1139 Section 4.14 highlights risks of using HTTP/2 server push in a manner 1140 other than specified. 1142 Applications that use HTTP in a manner that involves modification of 1143 implementations - for example, requiring support for a new URL 1144 scheme, or a non-standard method - risk having those implementations 1145 "fork" from their parent HTTP implementations, with the possible 1146 result that they do not benefit from patches and other security 1147 improvements incorporated upstream. 1149 6.1. Privacy Considerations 1151 HTTP clients can expose a variety of information to servers. Besides 1152 information that's explicitly sent as part of an application's 1153 operation (for example, names and other user-entered data), and "on 1154 the wire" (which is one of the reasons https is recommended in 1155 Section 4.4.2), other information can be gathered through less 1156 obvious means - often by connecting activities of a user over time. 1158 This includes session information, tracking the client through 1159 fingerprinting, and mobile code. 1161 Session information includes things like the IP address of the 1162 client, TLS session tickets, Cookies, ETags stored in the client's 1163 cache, and other stateful mechanisms. Applications are advised to 1164 avoid using session mechanisms unless they are unavoidable or 1165 necessary for operation, in which case these risks needs to be 1166 documented. When they are used, implementations should be encouraged 1167 to allow clearing such state. 1169 Fingerprinting uses unique aspects of a client's messages and 1170 behaviours to connect disparate requests and connections. For 1171 example, the User-Agent request header conveys specific information 1172 about the implementation; the Accept-Language request header conveys 1173 the users' preferred language. In combination, a number of these 1174 markers can be used to uniquely identify a client, impacting its 1175 control over its data. As a result, applications are advised to 1176 specify that clients should only emit the information they need to 1177 function in requests. 1179 Finally, if an application exposes the ability to run mobile code, 1180 great care needs to be taken, since any ability to observe its 1181 environment can be used as an opportunity to both fingerprint the 1182 client and to obtain and manipulate private data (including session 1183 information). For example, access to high-resolution timers (even 1184 indirectly) can be used to profile the underlying hardware, creating 1185 a unique identifier for the system. Applications are advised avoid 1186 allowing the use of mobile code where possible; when it cannot be 1187 avoided, the resulting system's security properties need be carefully 1188 scrutinised. 1190 7. References 1192 7.1. Normative References 1194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1195 Requirement Levels", BCP 14, RFC 2119, 1196 DOI 10.17487/RFC2119, March 1997, 1197 . 1199 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1200 DOI 10.17487/RFC2818, May 2000, 1201 . 1203 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1204 Procedures for Message Header Fields", BCP 90, RFC 3864, 1205 DOI 10.17487/RFC3864, September 2004, 1206 . 1208 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1209 DOI 10.17487/RFC6454, December 2011, 1210 . 1212 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1213 "Deprecating the "X-" Prefix and Similar Constructs in 1214 Application Protocols", BCP 178, RFC 6648, 1215 DOI 10.17487/RFC6648, June 2012, 1216 . 1218 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1219 Specifications and Registration Procedures", BCP 13, 1220 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1221 . 1223 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1224 Protocol (HTTP/1.1): Message Syntax and Routing", 1225 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1226 . 1228 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1229 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1230 DOI 10.17487/RFC7231, June 2014, 1231 . 1233 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1234 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 1235 DOI 10.17487/RFC7232, June 2014, 1236 . 1238 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1239 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1240 RFC 7233, DOI 10.17487/RFC7233, June 2014, 1241 . 1243 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1244 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1245 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1246 . 1248 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1249 Protocol (HTTP/1.1): Authentication", RFC 7235, 1250 DOI 10.17487/RFC7235, June 2014, 1251 . 1253 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1254 "Transport Layer Security (TLS) Application-Layer Protocol 1255 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1256 July 2014, . 1258 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 1259 RFC 7320, DOI 10.17487/RFC7320, July 2014, 1260 . 1262 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1263 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1264 DOI 10.17487/RFC7540, May 2015, 1265 . 1267 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1268 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1269 May 2017, . 1271 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 1272 DOI 10.17487/RFC8288, October 2017, 1273 . 1275 7.2. Informative References 1277 [CSP] West, M., "Content Security Policy Level 3", World Wide 1278 Web Consortium WD WD-CSP3-20160913, September 2016, 1279 . 1281 [FETCH] WHATWG, "Fetch - Living Standard", n.d., 1282 . 1284 [HTML5] WHATWG, "HTML - Living Standard", n.d., 1285 . 1287 [I-D.ietf-httpbis-header-structure] 1288 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 1289 draft-ietf-httpbis-header-structure-07 (work in progress), 1290 July 2018. 1292 [REFERRER-POLICY] 1293 Eisinger, J. and E. Stark, "Referrer Policy", World Wide 1294 Web Consortium CR CR-referrer-policy-20170126, January 1295 2017, 1296 . 1298 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 1299 RFC 3205, DOI 10.17487/RFC3205, February 2002, 1300 . 1302 [RFC4367] Rosenberg, J., Ed. and IAB, "What's in a Name: False 1303 Assumptions about DNS Names", RFC 4367, 1304 DOI 10.17487/RFC4367, February 2006, 1305 . 1307 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 1308 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 1309 DOI 10.17487/RFC4791, March 2007, 1310 . 1312 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1313 Authoring and Versioning (WebDAV)", RFC 4918, 1314 DOI 10.17487/RFC4918, June 2007, 1315 . 1317 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1318 (TLS) Protocol Version 1.2", RFC 5246, 1319 DOI 10.17487/RFC5246, August 2008, 1320 . 1322 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1323 Uniform Resource Identifiers (URIs)", RFC 5785, 1324 DOI 10.17487/RFC5785, April 2010, 1325 . 1327 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1328 Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, 1329 . 1331 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1332 DOI 10.17487/RFC6265, April 2011, 1333 . 1335 [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 1336 RFC 6415, DOI 10.17487/RFC6415, October 2011, 1337 . 1339 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1340 Transport Security (HSTS)", RFC 6797, 1341 DOI 10.17487/RFC6797, November 2012, 1342 . 1344 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1345 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1346 October 2013, . 1348 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1349 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1350 2014, . 1352 [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 1353 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, 1354 April 2015, . 1356 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1357 and Registration Procedures for URI Schemes", BCP 35, 1358 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1359 . 1361 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 1362 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 1363 August 2015, . 1365 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1366 Digest Access Authentication", RFC 7616, 1367 DOI 10.17487/RFC7616, September 2015, 1368 . 1370 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1371 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1372 . 1374 [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP 1375 APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, 1376 . 1378 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1379 Interchange Format", STD 90, RFC 8259, 1380 DOI 10.17487/RFC8259, December 2017, 1381 . 1383 [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", 1384 RFC 8297, DOI 10.17487/RFC8297, December 2017, 1385 . 1387 [SECCTXT] West, M., "Secure Contexts", World Wide Web Consortium CR 1388 CR-secure-contexts-20160915, September 2016, 1389 . 1391 [XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 1392 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1393 Edition)", World Wide Web Consortium Recommendation REC- 1394 xml-20081126, November 2008, 1395 . 1397 7.3. URIs 1399 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 1401 [2] http://httpwg.github.io/ 1403 [3] https://github.com/httpwg/http-extensions/labels/bcp56bis 1405 Appendix A. Changes from RFC 3205 1407 [RFC3205] captured the Best Current Practice in the early 2000's, 1408 based on the concerns facing protocol designers at the time. Use of 1409 HTTP has changed considerably since then, and as a result this 1410 document is substantially different. As a result, the changes are 1411 too numerous to list individually. 1413 Author's Address 1415 Mark Nottingham 1417 Email: mnot@mnot.net 1418 URI: https://www.mnot.net/