draft-ietf-httpbis-bcp56bis-05.txt   draft-ietf-httpbis-bcp56bis-latest.txt 
HTTP Working Group M. Nottingham HTTP Working Group M. Nottingham
Internet-Draft May 1, 2018 Internet-Draft May 22, 2018
Obsoletes: 3205 (if approved) Obsoletes: 3205 (if approved)
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: November 2, 2018 Expires: November 23, 2018
On the use of HTTP as a Substrate Building Protocols with HTTP
draft-ietf-httpbis-bcp56bis-05 draft-ietf-httpbis-bcp56bis-latest
Abstract Abstract
HTTP is often used as a substrate for other application protocols HTTP is often used as a substrate for other application protocols
(a.k.a. HTTP-based APIs). This document specifies best practices (a.k.a. HTTP-based APIs). This document specifies best practices
for these protocols' use of HTTP. for these protocols' use of HTTP.
Note to Readers Note to Readers
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 2, 2018. This Internet-Draft will expire on November 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
4.6. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 14 4.6. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 14
4.6.1. Redirection . . . . . . . . . . . . . . . . . . . . . 16 4.6.1. Redirection . . . . . . . . . . . . . . . . . . . . . 16
4.7. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 17 4.7. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 17
4.8. Defining Message Payloads . . . . . . . . . . . . . . . . 18 4.8. Defining Message Payloads . . . . . . . . . . . . . . . . 18
4.9. HTTP Caching . . . . . . . . . . . . . . . . . . . . . . 18 4.9. HTTP Caching . . . . . . . . . . . . . . . . . . . . . . 18
4.10. Application State . . . . . . . . . . . . . . . . . . . . 20 4.10. Application State . . . . . . . . . . . . . . . . . . . . 20
4.11. Client Authentication . . . . . . . . . . . . . . . . . . 20 4.11. Client Authentication . . . . . . . . . . . . . . . . . . 20
4.12. Co-Existing with Web Browsing . . . . . . . . . . . . . . 21 4.12. Co-Existing with Web Browsing . . . . . . . . . . . . . . 21
4.13. Application Boundaries . . . . . . . . . . . . . . . . . 22 4.13. Application Boundaries . . . . . . . . . . . . . . . . . 22
4.14. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23 4.14. Server Push . . . . . . . . . . . . . . . . . . . . . . . 23
4.15. Versioning and Evolution . . . . . . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . 26
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 29 Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
HTTP [RFC7230] is often used as a substrate for applications other HTTP [RFC7230] is often used as a substrate for applications other
than Web browsing; this is sometimes referred to as creating "HTTP- than Web browsing; this is sometimes referred to as creating "HTTP-
based APIs", or just "HTTP APIs". This is done for a variety of based APIs", or just "HTTP APIs". This is done for a variety of
skipping to change at page 7, line 7 skipping to change at page 7, line 11
the same server, and offers a natural mechanism for extensibility, the same server, and offers a natural mechanism for extensibility,
versioning and capability management, since the document containing versioning and capability management, since the document containing
the links can also contain information about their targets. the links can also contain information about their targets.
Using links also offers a form of cache invalidation that's seen on Using links also offers a form of cache invalidation that's seen on
the Web; when a resource's state changes, the application can change the Web; when a resource's state changes, the application can change
its link to it so that a fresh copy is always fetched. its link to it so that a fresh copy is always fetched.
3.3. Rich Functionality 3.3. Rich Functionality
The simplest possible use of HTTP is to POST data to a single URL, HTTP offers a number of features to applications, such as:
thereby effectively tunnelling through the protocol.
This "RPC" style of communication does get some benefit from using o Message framing
HTTP - namely, message framing and the availability of
implementations - but fails to realise many others when used o Multiplexing (in HTTP/2)
exclusively:
o Integration with TLS
o Support for intermediaries (proxies, gateways, Content Delivery
Networks)
o Client authentication
o Content negotiation for format, language, and other features
o Caching for server scalability, latency and bandwidth reduction, o Caching for server scalability, latency and bandwidth reduction,
and reliability; and reliability
o Granularity of access control (through use of a rich space of o Granularity of access control (through use of a rich space of
URLs); URLs)
o Partial content to selectively request part of a response;
o Definition of an information space using URLs; and o Partial content to selectively request part of a response
o The ability to interact with the application easily using a Web o The ability to interact with the application easily using a Web
browser. browser
Using such a high-level protocol to tunnel simple semantics has
downsides too; because of its more advanced capabilities, breadth of
deployment and age, HTTP's complexity can cause interoperability
problems that could be avoided by using a simpler substrate (e.g.,
WebSockets [RFC6455], if browser support is necessary, or TCP
[RFC0793] if not), or making the application be based upon HTTP,
instead of using it (as defined in Section 2).
Applications that use HTTP are encouraged to accommodate the various Applications that use HTTP are encouraged to utilise the various
features that the protocol offers, so that their users receive the features that the protocol offers, so that their users receive the
maximum benefit from it. This document does not require specific maximum benefit from it, and to allow it to be deployed in a variety
features to be used, since the appropriate design tradeoffs are of situations. This document does not require specific features to
highly specific to a given situation. However, following the be used, since the appropriate design tradeoffs are highly specific
practices in Section 4 will help make them available. to a given situation. However, following the practices in Section 4
is a good starting point.
4. Best Practices for Using HTTP 4. Best Practices for Using HTTP
This section contains best practices regarding the use of HTTP by This section contains best practices regarding the use of HTTP by
applications, including practices for specific HTTP protocol applications, including practices for specific HTTP protocol
elements. elements.
4.1. Specifying the Use of HTTP 4.1. Specifying the Use of HTTP
When specifying the use of HTTP, an application SHOULD use [RFC7230] When specifying the use of HTTP, an application SHOULD use [RFC7230]
skipping to change at page 12, line 11 skipping to change at page 12, line 11
o The resources identified by the new scheme will still be available o The resources identified by the new scheme will still be available
using "http" and/or "https" URLs. Those URLs can "leak" into use, using "http" and/or "https" URLs. Those URLs can "leak" into use,
which can present security and operability issues. For example, which can present security and operability issues. For example,
using a new scheme to assure that requests don't get sent to a using a new scheme to assure that requests don't get sent to a
"normal" Web site is likely to fail. "normal" Web site is likely to fail.
o Features that rely upon the URL's origin [RFC6454], such as the o Features that rely upon the URL's origin [RFC6454], such as the
Web's same-origin policy, will be impacted by a change of scheme. Web's same-origin policy, will be impacted by a change of scheme.
o HTTP-specific features such as cookies [RFC6265], authentication o HTTP-specific features such as cookies [RFC6265], authentication
[RFC7235], caching [RFC7234], and CORS [FETCH] might or might not [RFC7235], caching [RFC7234], HSTS [RFC6797], and CORS [FETCH]
work correctly, depending on how they are defined and implemented. might or might not work correctly, depending on how they are
Generally, they are designed and implemented with an assumption defined and implemented. Generally, they are designed and
that the URL will always be "http" or "https". implemented with an assumption that the URL will always be "http"
or "https".
o Web features that require a secure context [SECCTXT] will likely o Web features that require a secure context [SECCTXT] will likely
treat a new scheme as insecure. treat a new scheme as insecure.
See [RFC7595] for more information about minting new URL schemes. See [RFC7595] for more information about minting new URL schemes.
4.4.3. Transport Ports 4.4.3. Transport Ports
Applications that use HTTP can use the applicable default port (80 Applications that use HTTP can use the applicable default port (80
for HTTP, 443 for HTTPS), or they can be deployed upon other ports. for HTTP, 443 for HTTPS), or they can be deployed upon other ports.
skipping to change at page 13, line 20 skipping to change at page 13, line 20
their proposal as a separate HTTP extension, rather than as part of their proposal as a separate HTTP extension, rather than as part of
an application's specification. an application's specification.
4.5.1. GET 4.5.1. GET
GET is one of the most common and useful HTTP methods; its retrieval GET is one of the most common and useful HTTP methods; its retrieval
semantics allow caching, side-effect free linking and forms the basis semantics allow caching, side-effect free linking and forms the basis
of many of the benefits of using HTTP. of many of the benefits of using HTTP.
A common use of GET is to perform queries, often using the query A common use of GET is to perform queries, often using the query
component of the URL; this is this a familiar pattern from Web component of the URL; this is a familiar pattern from Web browsing,
browsing, and the results can be cached, improving efficiency of an and the results can be cached, improving efficiency of an often
often expensive process. expensive process.
In some cases, however, GET might be unwieldy for expressing queries, In some cases, however, GET might be unwieldy for expressing queries,
because of the limited syntax of the URL; in particular, if binary because of the limited syntax of the URL; in particular, if binary
data forms part of the query terms, it needs to be encoded to conform data forms part of the query terms, it needs to be encoded to conform
to URL syntax. to URL syntax.
While this is not an issue for short queries, it can become one for While this is not an issue for short queries, it can become one for
larger query terms, or ones which need to sustain a high rate of larger query terms, or ones which need to sustain a high rate of
requests. Additionally, some HTTP implementations limit the size of requests. Additionally, some HTTP implementations limit the size of
URLs they support - although modern HTTP software has much more URLs they support - although modern HTTP software has much more
skipping to change at page 21, line 36 skipping to change at page 21, line 36
using HTTP must consider. Generally, the best approach is to using HTTP must consider. Generally, the best approach is to
consider the application actually as a Web application, and to follow consider the application actually as a Web application, and to follow
best practices for their secure development. best practices for their secure development.
A complete enumeration of such practices is out of scope for this A complete enumeration of such practices is out of scope for this
document, but some considerations include: document, but some considerations include:
o Using an application-specific media type in the Content-Type o Using an application-specific media type in the Content-Type
header, and requiring clients to fail if it is not used header, and requiring clients to fail if it is not used
o Using X-Content-Type-Options: nosniff [FETCH]} to assure that o Using X-Content-Type-Options: nosniff [FETCH] to assure that
content under attacker control can't be coaxed into a form that is content under attacker control can't be coaxed into a form that is
interpreted as active content by a Web browser interpreted as active content by a Web browser
o Using Content-Security-Policy [CSP] to constrain the capabilities o Using Content-Security-Policy [CSP] to constrain the capabilities
of active content (such as HTML [HTML5]), thereby mitigating of active content (such as HTML [HTML5]), thereby mitigating
Cross-Site Scripting attacks Cross-Site Scripting attacks
o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data o Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data
in URLs from being leaked in the Referer request header in URLs from being leaked in the Referer request header
skipping to change at page 24, line 9 skipping to change at page 24, line 9
Applications wishing to optimise cases where the client can perform Applications wishing to optimise cases where the client can perform
work related to requests before the full response is available (e.g., work related to requests before the full response is available (e.g.,
fetching links for things likely to be contained within) might fetching links for things likely to be contained within) might
benefit from using the 103 (Early Hints) status code; see [RFC8297]. benefit from using the 103 (Early Hints) status code; see [RFC8297].
Applications using server push directly need to enforce the Applications using server push directly need to enforce the
requirements regarding authority in [RFC7540], Section 8.2, to avoid requirements regarding authority in [RFC7540], Section 8.2, to avoid
cross-origin push attacks. cross-origin push attacks.
4.15. Versioning and Evolution
It's often necessary to introduce new features into application
protocols, and change existing ones.
In HTTP, backwards-incompatible changes are possible using a number
of mechanisms:
o Using a distinct link relation type [RFC8288] to identify a URL
for a resource that implements the new functionality
o Using a distinct media type [RFC6838] to identify formats that
enable the new functionality
o Using a distinct HTTP header field to implement new functionality
outside the message body
5. IANA Considerations 5. IANA Considerations
This document has no requirements for IANA. This document has no requirements for IANA.
6. Security Considerations 6. Security Considerations
Section 4.10 discusses the impact of using stateful mechanisms in the Section 4.10 discusses the impact of using stateful mechanisms in the
protocol as ambient authority, and suggests a mitigation. protocol as ambient authority, and suggests a mitigation.
Section 4.4.2 requires support for 'https' URLs, and discourages the Section 4.4.2 requires support for 'https' URLs, and discourages the
skipping to change at page 27, line 11 skipping to change at page 27, line 22
Nottingham, M. and P. Kamp, "Structured Headers for HTTP", Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
draft-ietf-httpbis-header-structure-04 (work in progress), draft-ietf-httpbis-header-structure-04 (work in progress),
March 2018. March 2018.
[REFERRER-POLICY] [REFERRER-POLICY]
Eisinger, J. and E. Stark, "Referrer Policy", World Wide Eisinger, J. and E. Stark, "Referrer Policy", World Wide
Web Consortium CR CR-referrer-policy-20170126, January Web Consortium CR CR-referrer-policy-20170126, January
2017, 2017,
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>. <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
RFC 3205, DOI 10.17487/RFC3205, February 2002, RFC 3205, DOI 10.17487/RFC3205, February 2002,
<https://www.rfc-editor.org/info/rfc3205>. <https://www.rfc-editor.org/info/rfc3205>.
[RFC4367] Rosenberg, J., Ed. and IAB, "What's in a Name: False [RFC4367] Rosenberg, J., Ed. and IAB, "What's in a Name: False
Assumptions about DNS Names", RFC 4367, Assumptions about DNS Names", RFC 4367,
DOI 10.17487/RFC4367, February 2006, DOI 10.17487/RFC4367, February 2006,
<https://www.rfc-editor.org/info/rfc4367>. <https://www.rfc-editor.org/info/rfc4367>.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
skipping to change at page 28, line 5 skipping to change at page 28, line 9
<https://www.rfc-editor.org/info/rfc5861>. <https://www.rfc-editor.org/info/rfc5861>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata",
RFC 6415, DOI 10.17487/RFC6415, October 2011, RFC 6415, DOI 10.17487/RFC6415, October 2011,
<https://www.rfc-editor.org/info/rfc6415>. <https://www.rfc-editor.org/info/rfc6415>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
RFC 6455, DOI 10.17487/RFC6455, December 2011, Transport Security (HSTS)", RFC 6797,
<https://www.rfc-editor.org/info/rfc6455>. DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
 End of changes. 20 change blocks. 
47 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/