< draft-ietf-httpbis-bcp56bis-05.txt   draft-ietf-httpbis-bcp56bis-06.txt >
HTTP M. Nottingham HTTP M. Nottingham
Internet-Draft May 1, 2018 Internet-Draft July 1, 2018
Obsoletes: 3205 (if approved) Obsoletes: 3205 (if approved)
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: November 2, 2018 Expires: January 2, 2019
On the use of HTTP as a Substrate Building Protocols with HTTP
draft-ietf-httpbis-bcp56bis-05 draft-ietf-httpbis-bcp56bis-06
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 January 2, 2019.
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 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . 26 7.1. Normative References . . . . . . . . . . . . . . . . . . 26
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 29 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Changes from RFC 3205 . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
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
reasons, including: reasons, including:
o familiarity by implementers, specifiers, administrators, o familiarity by implementers, specifiers, administrators,
developers and users, developers and users,
skipping to change at page 7, line 7 skipping to change at page 7, line 13
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 20, line 43 skipping to change at page 20, line 43
4.11. Client Authentication 4.11. Client Authentication
Applications that use HTTP MAY use HTTP authentication [RFC7235] to Applications that use HTTP MAY use HTTP authentication [RFC7235] to
identify clients. The Basic authentication scheme [RFC7617] MUST NOT identify clients. The Basic authentication scheme [RFC7617] MUST NOT
be used unless the underlying transport is authenticated, integrity- be used unless the underlying transport is authenticated, integrity-
protected and confidential (e.g., as provided the "HTTPS" URL scheme, protected and confidential (e.g., as provided the "HTTPS" URL scheme,
or another using TLS). The Digest scheme [RFC7616] MUST NOT be used or another using TLS). The Digest scheme [RFC7616] MUST NOT be used
unless the underlying transport is similarly secure, or the chosen unless the underlying transport is similarly secure, or the chosen
hash algorithm is not "MD5". hash algorithm is not "MD5".
With HTTPS, clients might also be authenticated using certificates
[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.12. Co-Existing with Web Browsing
Even if there is not an intent for an application that uses HTTP to Even if there is not an intent for an application that uses HTTP to
be used with a Web browser, its resources will remain available to be used with a Web browser, its resources will remain available to
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 24, line 38 skipping to change at page 25, line 7
Section 4.14 highlights risks of using HTTP/2 server push in a manner Section 4.14 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 URL implementations - for example, requiring support for a new URL
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
HTTP clients can expose a variety of information to servers. Besides
information that's explicitly sent as part of an application's
operation (for example, names and other user-entered data), and "on
the wire" (which is one of the reasons https is recommended in
Section 4.4.2), other information can be gathered through less
obvious means - often by connecting activities of a user over time.
This includes session information, tracking the client through
fingerprinting, and mobile code.
Session information includes things like the IP address of the
client, TLS session tickets, Cookies, ETags stored in the client's
cache, and other stateful mechanisms. Applications are advised to
avoid using session mechanisms unless they are unavoidable or
necessary for operation, in which case these risks needs to be
documented. When they are used, implementations should be encouraged
to allow clearing such state.
Fingerprinting uses unique aspects of a client's messages and
behaviours to connect disparate requests and connections. For
example, the User-Agent request header conveys specific information
about the implementation; the Accept-Language request header conveys
the users' preferred language. In combination, a number of these
markers can be used to uniquely identify a client, impacting its
control over its data. As a result, applications are advised to
specify that clients should only emit the information they need to
function in requests.
Finally, if an application exposes the ability to run mobile code,
great care needs to be taken, since any ability to observe its
environment can be used as an opportunity to both fingerprint the
client and to obtain and manipulate private data (including session
information). For example, access to high-resolution timers (even
indirectly) can be used to profile the underlying hardware, creating
a unique identifier for the system. Applications are advised avoid
allowing the use of mobile code where possible; when it cannot be
avoided, the resulting system's security properties need be carefully
scrutinised.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
skipping to change at page 26, line 46 skipping to change at page 28, line 7
<https://www.w3.org/TR/2016/WD-CSP3-20160913>. <https://www.w3.org/TR/2016/WD-CSP3-20160913>.
[FETCH] WHATWG, "Fetch - Living Standard", n.d., [FETCH] WHATWG, "Fetch - Living Standard", n.d.,
<https://fetch.spec.whatwg.org>. <https://fetch.spec.whatwg.org>.
[HTML5] WHATWG, "HTML - Living Standard", n.d., [HTML5] WHATWG, "HTML - Living Standard", n.d.,
<https://html.spec.whatwg.org>. <https://html.spec.whatwg.org>.
[I-D.ietf-httpbis-header-structure] [I-D.ietf-httpbis-header-structure]
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-06 (work in progress),
March 2018. June 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,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
DOI 10.17487/RFC4791, March 2007, DOI 10.17487/RFC4791, March 2007,
<https://www.rfc-editor.org/info/rfc4791>. <https://www.rfc-editor.org/info/rfc4791>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007, DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>. <https://www.rfc-editor.org/info/rfc4918>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
[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/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. 24 change blocks. 
53 lines changed or deleted 118 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/