< draft-ietf-httpbis-bcp56bis-10.txt   draft-ietf-httpbis-bcp56bis-11.txt >
HTTP M. Nottingham HTTP M. Nottingham
Internet-Draft 7 March 2021 Internet-Draft 17 March 2021
Obsoletes: 3205 (if approved) Obsoletes: 3205 (if approved)
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: 8 September 2021 Expires: 18 September 2021
Building Protocols with HTTP Building Protocols with HTTP
draft-ietf-httpbis-bcp56bis-10 draft-ietf-httpbis-bcp56bis-11
Abstract Abstract
HTTP is often used as a substrate for other application protocols to HTTP is often used as a substrate for other application protocols to
create HTTP-based APIs. This document specifies best practices for create HTTP-based APIs. This document specifies best practices for
writing specifications that use HTTP to define new application writing specifications that use HTTP to define new application
protocols, especially when they are defined for diverse protocols, especially when they are defined for diverse
implementation and broad deployment (e.g., in standards efforts). implementation and broad deployment (e.g., in standards efforts).
Note to Readers Note to Readers
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 8 September 2021. This Internet-Draft will expire on 18 September 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 44 skipping to change at page 2, line 44
4.4. Specifying URLs . . . . . . . . . . . . . . . . . . . . . 11 4.4. Specifying URLs . . . . . . . . . . . . . . . . . . . . . 11
4.4.1. Discovering an Application's URLs . . . . . . . . . . 11 4.4.1. Discovering an Application's URLs . . . . . . . . . . 11
4.4.2. Considering URI Schemes . . . . . . . . . . . . . . . 12 4.4.2. Considering URI Schemes . . . . . . . . . . . . . . . 12
4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 13 4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 13
4.5. Using HTTP Methods . . . . . . . . . . . . . . . . . . . 14 4.5. Using HTTP Methods . . . . . . . . . . . . . . . . . . . 14
4.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 15 4.5.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. Using HTTP Status Codes . . . . . . . . . . . . . . . . . 16 4.6. Using HTTP Status Codes . . . . . . . . . . . . . . . . . 16
4.6.1. Redirection . . . . . . . . . . . . . . . . . . . . . 17 4.6.1. Redirection . . . . . . . . . . . . . . . . . . . . . 17
4.7. Specifying HTTP Header Fields . . . . . . . . . . . . . . 18 4.7. Specifying HTTP Header Fields . . . . . . . . . . . . . . 18
4.8. Defining Message Payloads . . . . . . . . . . . . . . . . 19 4.8. Defining Message Content . . . . . . . . . . . . . . . . 20
4.9. Leveraging HTTP Caching . . . . . . . . . . . . . . . . . 20 4.9. Leveraging HTTP Caching . . . . . . . . . . . . . . . . . 20
4.9.1. Freshness . . . . . . . . . . . . . . . . . . . . . . 20 4.9.1. Freshness . . . . . . . . . . . . . . . . . . . . . . 20
4.9.2. Stale Responses . . . . . . . . . . . . . . . . . . . 21 4.9.2. Stale Responses . . . . . . . . . . . . . . . . . . . 21
4.9.3. Caching and Application Semantics . . . . . . . . . . 21 4.9.3. Caching and Application Semantics . . . . . . . . . . 21
4.9.4. Varying Content Based Upon the Request . . . . . . . 22 4.9.4. Varying Content Based Upon the Request . . . . . . . 22
4.10. Handling Application State . . . . . . . . . . . . . . . 22 4.10. Handling Application State . . . . . . . . . . . . . . . 22
4.11. Client Authentication . . . . . . . . . . . . . . . . . . 23 4.11. Making Multiple Requests . . . . . . . . . . . . . . . . 23
4.12. Co-Existing with Web Browsing . . . . . . . . . . . . . . 23 4.12. Client Authentication . . . . . . . . . . . . . . . . . . 23
4.13. Maintaining Application Boundaries . . . . . . . . . . . 25 4.13. Co-Existing with Web Browsing . . . . . . . . . . . . . . 24
4.14. Using Server Push . . . . . . . . . . . . . . . . . . . . 25 4.14. Maintaining Application Boundaries . . . . . . . . . . . 25
4.15. Allowing Versioning and Evolution . . . . . . . . . . . . 26 4.15. Using Server Push . . . . . . . . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4.16. Allowing Versioning and Evolution . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 27 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
HTTP [I-D.ietf-httpbis-semantics] is often used as a substrate for HTTP [I-D.ietf-httpbis-semantics] is often used as a substrate for
applications other than Web browsing; this is sometimes referred to applications other than Web browsing; this is sometimes referred to
as creating "HTTP-based APIs", "REST APIs" or just "HTTP APIs". This as creating "HTTP-based APIs", "REST APIs" or just "HTTP APIs". This
is done for a variety of reasons, including: is done for a variety of reasons, including:
* familiarity by implementers, specifiers, administrators, * familiarity by implementers, specifiers, administrators,
developers and users, developers and users,
skipping to change at page 9, line 15 skipping to change at page 9, line 15
GET /thing HTTP/1.1 GET /thing HTTP/1.1
Host: example.com Host: example.com
Accept: application/things+json Accept: application/things+json
User-Agent: Foo/1.0 User-Agent: Foo/1.0
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/things+json Content-Type: application/things+json
Content-Length: 500 Content-Length: 500
Server: Bar/2.2 Server: Bar/2.2
[payload here] [content here]
4.2. Specifying Server Behaviour 4.2. Specifying Server Behaviour
The most effective way to specify an application's server-side HTTP The most effective way to specify an application's server-side HTTP
behaviours is in terms of the following protocol elements: behaviours is in terms of the following protocol elements:
* Media types [RFC6838], often based upon a format convention such * Media types [RFC6838], often based upon a format convention such
as JSON [RFC8259], as JSON [RFC8259],
* HTTP header fields, as per Section 4.7, and * HTTP header fields, as per Section 4.7, and
skipping to change at page 11, line 5 skipping to change at page 11, line 5
expected to be handled; see Section 4.6.1. expected to be handled; see Section 4.6.1.
* Cookies - Applications using HTTP should explicitly reference the * Cookies - Applications using HTTP should explicitly reference the
Cookie specification [I-D.ietf-httpbis-rfc6265bis] if they are Cookie specification [I-D.ietf-httpbis-rfc6265bis] if they are
required. required.
* Certificates - Applications using HTTP should specify that TLS * Certificates - Applications using HTTP should specify that TLS
certificates are to be checked according to certificates are to be checked according to
[I-D.ietf-httpbis-semantics], Section 4.3.4 when HTTPS is used. [I-D.ietf-httpbis-semantics], Section 4.3.4 when HTTPS is used.
Applications using HTTP MUST NOT require HTTP features that are Applications using HTTP should not statically require HTTP features
usually negotiated to be supported by clients. For example, that are usually negotiated to be supported by clients. For example,
requiring that clients support responses with a certain content- requiring that clients support responses with a certain content-
coding ([I-D.ietf-httpbis-semantics], Section 8.4.1) instead of coding ([I-D.ietf-httpbis-semantics], Section 8.4.1) instead of
negotiating for it ([I-D.ietf-httpbis-semantics], Section 12.5.3) negotiating for it ([I-D.ietf-httpbis-semantics], Section 12.5.3)
means that otherwise conformant clients cannot interoperate with the means that otherwise conformant clients cannot interoperate with the
application. Applications can encourage the implementation of such application. Applications can encourage the implementation of such
features, though. features, though.
4.4. Specifying URLs 4.4. Specifying URLs
In HTTP, the server resources that clients interact with are In HTTP, the server resources that clients interact with are
skipping to change at page 18, line 27 skipping to change at page 18, line 27
Table 1 Table 1
As noted in [I-D.ietf-httpbis-semantics], a user agent is allowed to As noted in [I-D.ietf-httpbis-semantics], a user agent is allowed to
automatically follow a 3xx redirect that has a Location response automatically follow a 3xx redirect that has a Location response
header field, even if they don't understand the semantics of the header field, even if they don't understand the semantics of the
specific status code. However, they aren't required to do so; specific status code. However, they aren't required to do so;
therefore, if an application using HTTP desires redirects to be therefore, if an application using HTTP desires redirects to be
automatically followed, it needs to explicitly specify the automatically followed, it needs to explicitly specify the
circumstances when this is required. circumstances when this is required.
Redirects can be cached (when appropriate cache directives are
present), but beyond that they are not 'sticky' -- i.e., redirection
of a URI will not result in the client assuming that similar URIs
(e.g., with different query parameters) will also be redirected.
Applications using HTTP are encouraged to specify that 301 and 302 Applications using HTTP are encouraged to specify that 301 and 302
responses change the subsequent request method from POST (but no responses change the subsequent request method from POST (but no
other method) to GET, to be compatible with browsers. Generally, other method) to GET, to be compatible with browsers. Generally,
when a redirected request is made, its header fields are copied from when a redirected request is made, its header fields are copied from
the original request's. However, they can be modified by various the original request's. However, they can be modified by various
mechanisms; e.g., sent Authorization ([I-D.ietf-httpbis-semantics]) mechanisms; e.g., sent Authorization ([I-D.ietf-httpbis-semantics])
and Cookie ([I-D.ietf-httpbis-rfc6265bis]) header fields will change and Cookie ([I-D.ietf-httpbis-rfc6265bis]) header fields will change
if the origin (and sometimes path) of the request changes. An if the origin (and sometimes path) of the request changes. An
application using HTTP should specify if any request header fields application using HTTP should specify if any request header fields
that it defines need to be modified or removed upon a redirect; that it defines need to be modified or removed upon a redirect;
skipping to change at page 19, line 13 skipping to change at page 19, line 19
(usually because a format does not allow it). (usually because a format does not allow it).
When the conditions above are not met, it is usually better to convey When the conditions above are not met, it is usually better to convey
application-specific information in other places; e.g., the message application-specific information in other places; e.g., the message
content or the URL query string. content or the URL query string.
New header fields MUST be registered, as per New header fields MUST be registered, as per
[I-D.ietf-httpbis-semantics]. [I-D.ietf-httpbis-semantics].
See [I-D.ietf-httpbis-semantics], Section 16.3.2 for guidelines to See [I-D.ietf-httpbis-semantics], Section 16.3.2 for guidelines to
consider when minting new header fields. consider when minting new header fields. [RFC8941] provides a common
[I-D.ietf-httpbis-header-structure] provides a common structure for structure for new header fields, and avoids many issues in their
new header fields, and avoids many issues in their parsing and parsing and handling; it is RECOMMENDED that new header fields use
handling; it is RECOMMENDED that new header fields use it. it.
It is RECOMMENDED that header field names be short (even when field It is RECOMMENDED that header field names be short (even when field
compression is used, there is an overhead) but appropriately compression is used, there is an overhead) but appropriately
specific. In particular, if a header field is specific to an specific. In particular, if a header field is specific to an
application, an identifier for that application can form a prefix to application, an identifier for that application can form a prefix to
the header field name, separated by a "-". the header field name, separated by a "-".
For example, if the "example" application needs to create three For example, if the "example" application needs to create three
headers, they might be called "example-foo", "example-bar" and header fields, they might be called "example-foo", "example-bar" and
"example-baz". Note that the primary motivation here is to avoid "example-baz". Note that the primary motivation here is to avoid
consuming more generic field names, not to reserve a portion of the consuming more generic field names, not to reserve a portion of the
namespace for the application; see [RFC6648] for related namespace for the application; see [RFC6648] for related
considerations. considerations.
The semantics of existing HTTP header fields MUST NOT be re-defined The semantics of existing HTTP header fields MUST NOT be re-defined
without updating their registration or defining an extension to them without updating their registration or defining an extension to them
(if allowed). For example, an application using HTTP cannot specify (if allowed). For example, an application using HTTP cannot specify
that the "Location" header field has a special meaning in a certain that the "Location" header field has a special meaning in a certain
context. context.
See Section 4.9 for the interaction between headers and HTTP caching; See Section 4.9 for the interaction between header fields and HTTP
in particular, request header fields that are used to "select" a caching; in particular, request header fields that are used to
response have impact there, and need to be carefully considered. "select" a response have impact there, and need to be carefully
considered.
See Section 4.10 for considerations regarding header fields that See Section 4.10 for considerations regarding header fields that
carry application state (e.g., Cookie). carry application state (e.g., Cookie).
4.8. Defining Message Payloads 4.8. Defining Message Content
There are many potential formats for payloads; for example, JSON Common syntactic conventions for message contents include JSON
[RFC8259], XML [XML], and CBOR [RFC7049]. Best practices for their [RFC8259], XML [XML], and CBOR [RFC7049]. Best practices for their
use are out of scope for this document. use are out of scope for this document.
Applications should register distinct media types for each format Applications should register distinct media types for each format
they define; this makes it possible to identify them unambiguously they define; this makes it possible to identify them unambiguously
and negotiate for their use. See [RFC6838] for more information. and negotiate for their use. See [RFC6838] for more information.
4.9. Leveraging HTTP Caching 4.9. Leveraging HTTP Caching
HTTP caching [I-D.ietf-httpbis-cache] is one of the primary benefits HTTP caching [I-D.ietf-httpbis-cache] is one of the primary benefits
skipping to change at page 20, line 29 skipping to change at page 20, line 39
4.9.1. Freshness 4.9.1. Freshness
Assigning even a short freshness lifetime ([I-D.ietf-httpbis-cache], Assigning even a short freshness lifetime ([I-D.ietf-httpbis-cache],
Section 4.2) -- e.g., 5 seconds -- allows a response to be reused to Section 4.2) -- e.g., 5 seconds -- allows a response to be reused to
satisfy multiple clients, and/or a single client making the same satisfy multiple clients, and/or a single client making the same
request repeatedly. In general, if it is safe to reuse something, request repeatedly. In general, if it is safe to reuse something,
consider assigning a freshness lifetime. consider assigning a freshness lifetime.
The most common method for specifying freshness is the max-age The most common method for specifying freshness is the max-age
response directive ([I-D.ietf-httpbis-cache], Section 5.2.2.9). The response directive ([I-D.ietf-httpbis-cache], Section 5.2.2.1). The
Expires header field ([I-D.ietf-httpbis-cache], Section 5.3) can also Expires header field ([I-D.ietf-httpbis-cache], Section 5.3) can also
be used, but it is not necessary; all modern cache implementations be used, but it is not necessary; all modern cache implementations
support Cache-Control, and specifying freshness as a delta is usually support Cache-Control, and specifying freshness as a delta is usually
more convenient and less error-prone. more convenient and less error-prone.
It is not necessary to add the public response directive
([I-D.ietf-httpbis-cache], Section 5.2.2.9) to cache most responses;
it is only necessary when it's desirable to store an authenticated
response.
In some situations, responses without explicit cache freshness In some situations, responses without explicit cache freshness
directives will be stored and served using a heuristic freshness directives will be stored and served using a heuristic freshness
lifetime; see [I-D.ietf-httpbis-cache], Section 4.2.2. As the lifetime; see [I-D.ietf-httpbis-cache], Section 4.2.2. As the
heuristic is not under control of the application, it is generally heuristic is not under control of the application, it is generally
preferable to set an explicit freshness lifetime, or make the preferable to set an explicit freshness lifetime, or make the
response explicitly uncacheable. response explicitly uncacheable.
If caching of a response is not desired, the appropriate response If caching of a response is not desired, the appropriate response
directive is "Cache-Control: no-store". This only need be sent in directive is "Cache-Control: no-store". Other directives are not
situations where the response might be cached; see necessary, and no-store only need be sent in situations where the
[I-D.ietf-httpbis-cache], Section 3. Note that "Cache-Control: no- response might be cached; see [I-D.ietf-httpbis-cache], Section 3.
cache" allows a response to be stored, just not reused by a cache Note that "Cache-Control: no-cache" allows a response to be stored,
without validation; it does not prevent caching (despite its name). just not reused by a cache without validation; it does not prevent
caching (despite its name).
For example, this response cannot be stored or reused by a cache: For example, this response cannot be stored or reused by a cache:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/example+xml Content-Type: application/example+xml
Cache-Control: no-store Cache-Control: no-store
[content] [content]
4.9.2. Stale Responses 4.9.2. Stale Responses
skipping to change at page 22, line 8 skipping to change at page 22, line 17
handled; if they have a concept like a validity period, this will handled; if they have a concept like a validity period, this will
need to be calculated considering the age of the response (see need to be calculated considering the age of the response (see
[I-D.ietf-httpbis-cache], Section 4.2.3). [I-D.ietf-httpbis-cache], Section 4.2.3).
One way to address this is to explicitly specify that all responses One way to address this is to explicitly specify that all responses
be fresh upon use. be fresh upon use.
4.9.4. Varying Content Based Upon the Request 4.9.4. Varying Content Based Upon the Request
If an application uses a request header field to change the If an application uses a request header field to change the
response's headers or content, authors should point out that this has response's header fields or content, authors should point out that
implications for caching; in general, such resources need to either this has implications for caching; in general, such resources need to
make their responses uncacheable (e.g., with the "no-store" cache- either make their responses uncacheable (e.g., with the "no-store"
control directive defined in [I-D.ietf-httpbis-cache], cache-control directive defined in [I-D.ietf-httpbis-cache],
Section 5.2.2.3) or send the Vary response header field Section 5.2.2.3) or send the Vary response header field
([I-D.ietf-httpbis-semantics], Section 12.5.5) on all responses from ([I-D.ietf-httpbis-semantics], Section 12.5.5) on all responses from
that resource (including the "default" response). that resource (including the "default" response).
For example, this response: For example, this response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/example+xml Content-Type: application/example+xml
Cache-Control: max-age=60 Cache-Control: max-age=60
ETag: "sa0f8wf20fs0f" ETag: "sa0f8wf20fs0f"
skipping to change at page 22, line 42 skipping to change at page 23, line 5
Applications can use stateful cookies [I-D.ietf-httpbis-rfc6265bis] Applications can use stateful cookies [I-D.ietf-httpbis-rfc6265bis]
to identify a client and/or store client-specific data to to identify a client and/or store client-specific data to
contextualise requests. contextualise requests.
When used, it is important to carefully specify the scoping and use When used, it is important to carefully specify the scoping and use
of cookies; if the application exposes sensitive data or capabilities of cookies; if the application exposes sensitive data or capabilities
(e.g., by acting as an ambient authority), exploits are possible. (e.g., by acting as an ambient authority), exploits are possible.
Mitigations include using a request-specific token to assure the Mitigations include using a request-specific token to assure the
intent of the client. intent of the client.
4.11. Making Multiple Requests
Clients often need to send multiple requests to perform a task.
In HTTP/1, parallel requests are most often supported by opening
multiple connections. Application performance can be impacted when
too many simultaneous connections are used, because connections'
congestion control will not be coordinated. Furthermore, it can be
difficult for applications to decide when and to select which
connection to use to issue a given request, further impacting
performance.
HTTP/2 and HTTP/3 offer multiplexing to applications, removing the
need to use multiple connections. However, application performance
can still be significantly affected by how the server chooses to
prioritize responses. Depending on the application, it might be best
for the server to determine the priority of responses, or for the
client to hint its priorities to the server (see, e.g.,
[I-D.ietf-httpbis-priority]).
In all versions of HTTP, requests are made independently -- you can't
rely on the relative order of two requests to guarantee processing
order. This is because they might be sent over a multiplexed
protocol by an intermediary, sent to different origin servers, or the
server might even perform processing in a different order. If two
requests need strict ordering, the only reliable way to assure the
outcome is to issue the second request when the final response to the
first has begun.
Applications MUST NOT make assumptions about the relationship between Applications MUST NOT make assumptions about the relationship between
separate requests on a single transport connection; doing so breaks separate requests on a single transport connection; doing so breaks
many of the assumptions of HTTP as a stateless protocol, and will many of the assumptions of HTTP as a stateless protocol, and will
cause problems in interoperability, security, operability and cause problems in interoperability, security, operability and
evolution. evolution.
4.11. Client Authentication 4.12. Client Authentication
Applications can use HTTP authentication [I-D.ietf-httpbis-semantics] Applications can use HTTP authentication [I-D.ietf-httpbis-semantics]
to identify clients. The Basic authentication scheme [RFC7617] MUST to identify clients. The Basic authentication scheme [RFC7617] MUST
NOT be used unless the underlying transport is authenticated, NOT be used unless the underlying transport is authenticated,
integrity-protected and confidential (e.g., as provided the "HTTPS" integrity-protected and confidential (e.g., as provided the "HTTPS"
URI scheme, or another using TLS). The Digest scheme [RFC7616] MUST URI scheme, or another using TLS). The Digest scheme [RFC7616] MUST
NOT be used unless the underlying transport is similarly secure, or NOT be used unless the underlying transport is similarly secure, or
the chosen hash algorithm is not "MD5". the chosen hash algorithm is not "MD5".
With HTTPS, clients might also be authenticated using certificates With HTTPS, clients might also be authenticated using certificates
[RFC5246]. [RFC5246].
When used, it is important to carefully specify the scoping and use When used, it is important to carefully specify the scoping and use
of authentication; if the application exposes sensitive data or of authentication; if the application exposes sensitive data or
capabilities (e.g., by acting as an ambient authority), exploits are capabilities (e.g., by acting as an ambient authority), exploits are
possible. Mitigations include using a request-specific token to possible. Mitigations include using a request-specific token to
assure the intent of the client. assure the intent of the client.
4.12. Co-Existing with Web Browsing 4.13. Co-Existing with Web Browsing
Even if there is not an intent for an application to be used with a Even if there is not an intent for an application to be used with a
Web browser, its resources will remain available to browsers and Web browser, its resources will remain available to browsers and
other HTTP clients. other HTTP clients.
This means that all such applications that use HTTP need to consider This means that all such applications that use HTTP need to consider
how browsers will interact with them, particularly regarding how browsers will interact with them, particularly regarding
security. security.
For example, if an application's state can be changed using a POST For example, if an application's state can be changed using a POST
skipping to change at page 25, line 5 skipping to change at page 25, line 39
Cache-Control: max-age=3600 Cache-Control: max-age=3600
Referrer-Policy: no-referrer Referrer-Policy: no-referrer
[content] [content]
If an application has browser compatibility as a goal, client If an application has browser compatibility as a goal, client
interaction ought to be defined in terms of [FETCH], since that is interaction ought to be defined in terms of [FETCH], since that is
the abstraction that browsers use for HTTP; it enforces many of these the abstraction that browsers use for HTTP; it enforces many of these
best practices. best practices.
4.13. Maintaining Application Boundaries 4.14. Maintaining Application Boundaries
Because the origin [RFC6454] is how many HTTP capabilities are Because the origin [RFC6454] is how many HTTP capabilities are
scoped, applications also need to consider how deployments might scoped, applications also need to consider how deployments might
interact with other applications (including Web browsing) on the same interact with other applications (including Web browsing) on the same
origin. origin.
For example, if Cookies [I-D.ietf-httpbis-rfc6265bis] are used to For example, if Cookies [I-D.ietf-httpbis-rfc6265bis] are used to
carry application state, they will be sent with all requests to the carry application state, they will be sent with all requests to the
origin by default, unless scoped by path, and the application might origin by default, unless scoped by path, and the application might
receive cookies from other applications on the origin. This can lead receive cookies from other applications on the origin. This can lead
skipping to change at page 25, line 39 skipping to change at page 26, line 26
use of a particular name, but instead let deployments configure them. use of a particular name, but instead let deployments configure them.
Consideration should be given to scoping them to part of the origin, Consideration should be given to scoping them to part of the origin,
using their specified mechanisms for doing so. using their specified mechanisms for doing so.
Modern Web browsers constrain the ability of content from one origin Modern Web browsers constrain the ability of content from one origin
to access resources from another, to avoid leaking private to access resources from another, to avoid leaking private
information. As a result, applications that wish to expose cross- information. As a result, applications that wish to expose cross-
origin data to browsers will need to implement the CORS protocol; see origin data to browsers will need to implement the CORS protocol; see
[FETCH]. [FETCH].
4.14. Using Server Push 4.15. Using Server Push
HTTP/2 adds the ability for servers to "push" request/response pairs HTTP/2 adds the ability for servers to "push" request/response pairs
to clients in [RFC7540], Section 8.2. While server push seems like a to clients in [RFC7540], Section 8.2. While server push seems like a
natural fit for many common application semantics (e.g., "fanout" and natural fit for many common application semantics (e.g., "fanout" and
publish/subscribe), a few caveats should be noted: publish/subscribe), a few caveats should be noted:
* Server push is hop-by-hop; that is, it is not automatically * Server push is hop-by-hop; that is, it is not automatically
forwarded by intermediaries. As a result, it might not work forwarded by intermediaries. As a result, it might not work
easily (or at all) with proxies, reverse proxies, and Content easily (or at all) with proxies, reverse proxies, and Content
Delivery Networks. Delivery Networks.
skipping to change at page 26, line 32 skipping to change at page 27, line 18
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. Allowing Versioning and Evolution 4.16. Allowing Versioning and Evolution
It's often necessary to introduce new features into application It's often necessary to introduce new features into application
protocols, and change existing ones. protocols, and change existing ones.
In HTTP, backwards-incompatible changes are possible using a number In HTTP, backwards-incompatible changes are possible using a number
of mechanisms: of mechanisms:
* Using a distinct link relation type [RFC8288] to identify a URL * Using a distinct link relation type [RFC8288] to identify a URL
for a resource that implements the new functionality. for a resource that implements the new functionality.
skipping to change at page 27, line 14 skipping to change at page 27, line 48
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
use of 'http' URLs, to provide authentication, integrity and use of 'http' URLs, to provide authentication, integrity and
confidentiality, as well as mitigate pervasive monitoring attacks. confidentiality, as well as mitigate pervasive monitoring attacks.
Section 4.12 highlights the implications of Web browsers' Section 4.13 highlights the implications of Web browsers'
capabilities on applications that use HTTP. capabilities on applications that use HTTP.
Section 4.13 discusses the issues that arise when applications are Section 4.14 discusses the issues that arise when applications are
deployed on the same origin as Web sites (and other applications). deployed on the same origin as Web sites (and other applications).
Section 4.14 highlights risks of using HTTP/2 server push in a manner Section 4.15 highlights risks of using HTTP/2 server push in a manner
other than specified. other than specified.
Applications that use HTTP in a manner that involves modification of Applications that use HTTP in a manner that involves modification of
implementations -- for example, requiring support for a new URI implementations -- for example, requiring support for a new URI
scheme, or a non-standard method -- risk having those implementations scheme, or a non-standard method -- risk having those implementations
"fork" from their parent HTTP implementations, with the possible "fork" from their parent HTTP implementations, with the possible
result that they do not benefit from patches and other security result that they do not benefit from patches and other security
improvements incorporated upstream. improvements incorporated upstream.
6.1. Privacy Considerations 6.1. Privacy Considerations
skipping to change at page 28, line 22 skipping to change at page 29, line 16
great care needs to be taken, since any ability to observe its great care needs to be taken, since any ability to observe its
environment can be used as an opportunity to both fingerprint the environment can be used as an opportunity to both fingerprint the
client and to obtain and manipulate private data (including session client and to obtain and manipulate private data (including session
information). For example, access to high-resolution timers (even information). For example, access to high-resolution timers (even
indirectly) can be used to profile the underlying hardware, creating indirectly) can be used to profile the underlying hardware, creating
a unique identifier for the system. Applications are advised to a unique identifier for the system. Applications are advised to
avoid allowing the use of mobile code where possible; when it cannot avoid allowing the use of mobile code where possible; when it cannot
be avoided, the resulting system's security properties need be be avoided, the resulting system's security properties need be
carefully scrutinised. carefully scrutinised.
--- back
# Changes from RFC 3205
[RFC3205] captured the Best Current Practice in the early 2000's,
based on the concerns facing protocol designers at the time. Use of
HTTP has changed considerably since then, and as a result this
document is substantially different. As a result, the changes are
too numerous to list individually.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-httpbis-semantics] [I-D.ietf-httpbis-semantics]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-14, 12 January 2021, httpbis-semantics-14, 12 January 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
14>. 14>.
skipping to change at page 31, line 28 skipping to change at page 32, line 5
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/rfc/rfc7807>. <https://www.rfc-editor.org/rfc/rfc7807>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
[I-D.ietf-httpbis-header-structure] [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for
Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
HTTP", Work in Progress, Internet-Draft, draft-ietf- <https://www.rfc-editor.org/rfc/rfc8941>.
httpbis-header-structure-19, 3 June 2020,
<https://tools.ietf.org/html/draft-ietf-httpbis-header-
structure-19>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and [XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, 26 November 2008, xml-20081126, 26 November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>. <https://www.w3.org/TR/2008/REC-xml-20081126>.
[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/rfc/rfc7049>. October 2013, <https://www.rfc-editor.org/rfc/rfc7049>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
<https://www.rfc-editor.org/rfc/rfc5861>. <https://www.rfc-editor.org/rfc/rfc5861>.
[I-D.ietf-httpbis-priority]
Oku, K. and L. Pardue, "Extensible Prioritization Scheme
for HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-priority-03, 11 January 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-priority-
03>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/rfc/rfc7617>. <https://www.rfc-editor.org/rfc/rfc7617>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/rfc/rfc7616>. <https://www.rfc-editor.org/rfc/rfc7616>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
skipping to change at page 32, line 33 skipping to change at page 33, line 13
<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>. <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints",
RFC 8297, DOI 10.17487/RFC8297, December 2017, RFC 8297, DOI 10.17487/RFC8297, December 2017,
<https://www.rfc-editor.org/rfc/rfc8297>. <https://www.rfc-editor.org/rfc/rfc8297>.
[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/rfc/rfc3205>. <https://www.rfc-editor.org/rfc/rfc3205>.
Appendix A. Changes from RFC 3205
[RFC3205] captured the Best Current Practice in the early 2000's,
based on the concerns facing protocol designers at the time. Use of
HTTP has changed considerably since then, and as a result this
document is substantially different. As a result, the changes are
too numerous to list individually.
Author's Address Author's Address
Mark Nottingham Mark Nottingham
Prahran VIC Prahran VIC
Australia Australia
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
 End of changes. 32 change blocks. 
63 lines changed or deleted 108 lines changed or added

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