draft-ietf-httpbis-alt-svc-07.txt   draft-ietf-httpbis-alt-svc-08.txt 
HTTP Working Group M. Nottingham HTTP Working Group M. Nottingham
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track P. McManus Intended status: Standards Track P. McManus
Expires: November 16, 2015 Mozilla Expires: March 23, 2016 Mozilla
J. Reschke J. Reschke
greenbytes greenbytes
May 15, 2015 September 20, 2015
HTTP Alternative Services HTTP Alternative Services
draft-ietf-httpbis-alt-svc-07 draft-ietf-httpbis-alt-svc-08
Abstract Abstract
This document specifies "alternative services" for HTTP, which allow This document specifies "alternative services" for HTTP, which allow
an origin's resources to be authoritatively available at a separate an origin's resources to be authoritatively available at a separate
network location, possibly accessed with a different protocol network location, possibly accessed with a different protocol
configuration. configuration.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 16, 2015. This Internet-Draft will expire on March 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 10 skipping to change at page 3, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2. Alternative Services Concepts . . . . . . . . . . . . . . . . 5 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 5
2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 6 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 7
2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7
2.3. Requiring Server Name Indication . . . . . . . . . . . . . 7 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 7
2.4. Using Alternative Services . . . . . . . . . . . . . . . . 7 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 8
3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 8 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 8
3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 10 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11
4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 11 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12
5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 12 5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 13
6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 12 6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Header Field Registrations . . . . . . . . . . . . . . . . 13 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 14
7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 13 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15
8. Internationalization Considerations . . . . . . . . . . . . . 14 7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 14 7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 15
9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 14 8. Internationalization Considerations . . . . . . . . . . . . . 15
9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.4. Tracking Clients Using Alternative Services . . . . . . . 15 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16
9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 15 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.4. Tracking Clients Using Alternative Services . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 17 publication) . . . . . . . . . . . . . . . . . . . . 19
A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 17 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 19
A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 17 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 19
A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 17 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 19
A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 17 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 19
A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 17 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 20
A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 18 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 20
A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 18 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 20
A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 18 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 20
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 19 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 21
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
HTTP [RFC7230] conflates the identification of resources with their HTTP [RFC7230] conflates the identification of resources with their
location. In other words, "http://" (and "https://") URLs are used location. In other words, "http://" (and "https://") URLs are used
to both name and find things to interact with. to both name and find things to interact with.
In some cases, it is desirable to separate identification and In some cases, it is desirable to separate identification and
location in HTTP; keeping the same identifier for a resource, but location in HTTP; keeping the same identifier for a resource, but
interacting with it at a different location on the network. interacting with it at a different location on the network.
For example: For example:
o An origin server might wish to redirect a client to a different o An origin server might wish to redirect a client to a different
server when it needs to go down for maintenance, or it has found a server when it is under load, or it has found a server in a
server in a location that is more local to the client. location that is more local to the client.
o An origin server might wish to offer access to its resources using o An origin server might wish to offer access to its resources using
a new protocol (such as HTTP/2, see [RFC7540]) or one using a new protocol (such as HTTP/2, see [RFC7540]) or one using
improved security (such as Transport Layer Security (TLS), see improved security (such as Transport Layer Security (TLS), see
[RFC5246]). [RFC5246]).
o An origin server might wish to segment its clients into groups of o An origin server might wish to segment its clients into groups of
capabilities, such as those supporting Server Name Indication capabilities, such as those supporting Server Name Indication
(SNI, see Section 3 of [RFC6066]) and those not supporting it, for (SNI, see Section 3 of [RFC6066]) and those not supporting it, for
operational purposes. operational purposes.
This specification defines a new concept in HTTP, "Alternative This specification defines a new concept in HTTP, "Alternative
Services", that allows an origin server to nominate additional means Services", that allows an origin server to nominate additional means
of interacting with it on the network. It defines a general of interacting with it on the network. It defines a general
framework for this in Section 2, along with specific mechanisms for framework for this in Section 2, along with specific mechanisms for
advertising their existence using HTTP header fields (Section 3) or advertising their existence using HTTP header fields (Section 3) or
HTTP/2 frames (Section 4), plus a way to indicate that an alternative HTTP/2 frames (Section 4), plus a way to indicate that an alternative
service was used (Section 5). service was used (Section 5).
It also introduces a new status code in Section 6, so that origin It also endorses the status code 421 (Misdirected Request)
servers (or their nominated alternatives) can indicate that they are (Section 6) that origin servers (or their nominated alternatives) can
not authoritative for a given origin, in cases where the wrong use to indicate that they are not authoritative for a given origin,
location is used. in cases where the wrong location is used.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the Augmented BNF defined in [RFC5234] along with This document uses the Augmented BNF defined in [RFC5234] along with
the "#rule" extension defined in Section 7 of [RFC7230]. The rules the "#rule" extension defined in Section 7 of [RFC7230]. The rules
below are defined in [RFC7230] and [RFC7234]: below are defined in [RFC5234], [RFC7230], and [RFC7234]:
DIGIT = <DIGIT, see [RFC5234], Appendix B.1>
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, see [RFC7230], Section 3.2.3>
delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1> delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1>
port = <port, see [RFC7230], Section 2.7> port = <port, see [RFC7230], Section 2.7>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6> quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6> token = <token, see [RFC7230], Section 3.2.6>
uri-host = <uri-host, see [RFC7230], Section 2.7> uri-host = <uri-host, see [RFC7230], Section 2.7>
2. Alternative Services Concepts 2. Alternative Services Concepts
This specification defines a new concept in HTTP, the "alternative This specification defines a new concept in HTTP, the "alternative
skipping to change at page 5, line 44 skipping to change at page 5, line 45
By their nature, alternative services are explicitly at the By their nature, alternative services are explicitly at the
granularity of an origin; i.e., they cannot be selectively applied to granularity of an origin; i.e., they cannot be selectively applied to
resources within an origin. resources within an origin.
Alternative services do not replace or change the origin for any Alternative services do not replace or change the origin for any
given resource; in general, they are not visible to the software given resource; in general, they are not visible to the software
"above" the access mechanism. The alternative service is essentially "above" the access mechanism. The alternative service is essentially
alternative routing information that can also be used to reach the alternative routing information that can also be used to reach the
origin in the same way that DNS CNAME or SRV records define routing origin in the same way that DNS CNAME or SRV records define routing
information at the name resolution level. Each origin maps to a set information at the name resolution level. Each origin maps to a set
of these routes -- the default route is derived from origin itself of these routes -- the default route is derived from thr origin
and the other routes are introduced based on alternative-protocol itself and the other routes are introduced based on alternative-
information. protocol information.
Furthermore, it is important to note that the first member of an Furthermore, it is important to note that the first member of an
alternative service tuple is different from the "scheme" component of alternative service tuple is different from the "scheme" component of
an origin; it is more specific, identifying not only the major an origin; it is more specific, identifying not only the major
version of the protocol being used, but potentially communication version of the protocol being used, but potentially communication
options for that protocol. options for that protocol.
This means that clients using an alternative service can change the This means that clients using an alternative service can change the
host, port and protocol that they are using to fetch resources, but host, port and protocol that they are using to fetch resources, but
these changes MUST NOT be propagated to the application that is using these changes MUST NOT be propagated to the application that is using
skipping to change at page 6, line 24 skipping to change at page 6, line 25
need to present a certificate for the origin's host name, not that of need to present a certificate for the origin's host name, not that of
the alternative. Likewise, the Host header field ([RFC7230], Section the alternative. Likewise, the Host header field ([RFC7230], Section
5.4) is still derived from the origin, not the alternative service 5.4) is still derived from the origin, not the alternative service
(just as it would if a CNAME were being used). (just as it would if a CNAME were being used).
The changes MAY, however, be made visible in debugging tools, The changes MAY, however, be made visible in debugging tools,
consoles, etc. consoles, etc.
Formally, an alternative service is identified by the combination of: Formally, an alternative service is identified by the combination of:
o An Application Layer Protocol Negotiation (ALPN) protocol, as per o An Application Layer Protocol Negotiation (ALPN) protocol name, as
[RFC7301] per [RFC7301]
o A host, as per [RFC3986], Section 3.2.2 o A host, as per [RFC3986], Section 3.2.2
o A port, as per [RFC3986], Section 3.2.3 o A port, as per [RFC3986], Section 3.2.3
The ALPN protocol name is used to identify the application protocol
or suite of protocols used by the alternative service. Note that for
the purpose of this specification, an ALPN protocol name implicitly
includes TLS in the suite of protocols it identifies, unless
specified otherwise in its definition. In particular, the ALPN name
"http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1
over TLS.
Additionally, each alternative service MUST have: Additionally, each alternative service MUST have:
o A freshness lifetime, expressed in seconds; see Section 2.2 o A freshness lifetime, expressed in seconds; see Section 2.2
There are many ways that a client could discover the alternative There are many ways that a client could discover the alternative
service(s) associated with an origin. This document describes two service(s) associated with an origin. This document describes two
such mechanisms: an HTTP header field (Section 3) and an HTTP/2 frame such mechanisms: an HTTP header field (Section 3) and an HTTP/2 frame
type (Section 4). type (Section 4).
The remainder of this section describes requirements that are common The remainder of this section describes requirements that are common
skipping to change at page 7, line 23 skipping to change at page 7, line 34
freshness lifetime with them; for example, the Alt-Svc header field freshness lifetime with them; for example, the Alt-Svc header field
uses the "ma" parameter. uses the "ma" parameter.
Clients MAY choose to use an alternative service instead of the Clients MAY choose to use an alternative service instead of the
origin at any time when it is considered fresh; see Section 2.4 for origin at any time when it is considered fresh; see Section 2.4 for
specific recommendations. specific recommendations.
Clients with existing connections to an alternative service do not Clients with existing connections to an alternative service do not
need to stop using it when its freshness lifetime ends; i.e., the need to stop using it when its freshness lifetime ends; i.e., the
caching mechanism is intended for limiting how long an alternative caching mechanism is intended for limiting how long an alternative
service can be used for establishing new requests, not limiting the service can be used for establishing new connections, not limiting
use of existing ones. the use of existing ones.
Clients ought to consider that changes in network configurations can When alternative services are used to send a client to the most
result in suboptimal or compromised cached alternative services. optimal server, a change in network configuration can result in
cached values becoming suboptimal. Therefore, clients SHOULD remove
from cache all alternative services that lack the "persist" flag with
the value "1" when they detect such a change (when information about
network state is available).
2.3. Requiring Server Name Indication 2.3. Requiring Server Name Indication
A client MUST only use a TLS-based alternative service if the client A client MUST only use a TLS-based alternative service if the client
also supports TLS Server Name Indication (SNI). This supports the also supports TLS Server Name Indication (SNI). This supports the
conservation of IP addresses on the alternative service host. conservation of IP addresses on the alternative service host.
Note that the SNI information provided in TLS by the client will be Note that the SNI information provided in TLS by the client will be
that of the origin, not the alternative (as will the Host HTTP header that of the origin, not the alternative (as will the Host HTTP header
field-value). field-value).
skipping to change at page 8, line 12 skipping to change at page 8, line 25
security properties of the alternative service protocol are security properties of the alternative service protocol are
desirable, as compared to the existing connection. desirable, as compared to the existing connection.
If a client becomes aware of multiple alternative services, it MAY If a client becomes aware of multiple alternative services, it MAY
choose the most suitable according to its own criteria (again, choose the most suitable according to its own criteria (again,
keeping security properties in mind). For example, an origin might keeping security properties in mind). For example, an origin might
advertise multiple alternative services to notify clients of support advertise multiple alternative services to notify clients of support
for multiple versions of HTTP; or, an alternative service might for multiple versions of HTTP; or, an alternative service might
itself advertise an alternative. itself advertise an alternative.
A client configured to use a proxy for a given request SHOULD NOT
directly connect to an alternative service for it, but instead route
it through that proxy.
When a client uses an alternative service for a request, it can When a client uses an alternative service for a request, it can
indicate this to the server using the Alt-Used header field indicate this to the server using the Alt-Used header field
(Section 5). (Section 5).
The client does not need to block requests on any existing The client does not need to block requests on any existing
connection; it can be used until the alternative connection is connection; it can be used until the alternative connection is
established. However, if the security properties of the existing established. However, if the security properties of the existing
connection are weak (e.g. cleartext HTTP/1.1) then it might make connection are weak (e.g. cleartext HTTP/1.1) then it might make
sense to block until the new connection is fully available in order sense to block until the new connection is fully available in order
to avoid information leakage. to avoid information leakage.
skipping to change at page 8, line 35 skipping to change at page 9, line 5
alternative service. Note, however, that this could be the basis of alternative service. Note, however, that this could be the basis of
a downgrade attack, thus losing any enhanced security properties of a downgrade attack, thus losing any enhanced security properties of
the alternative service. the alternative service.
3. The Alt-Svc HTTP Header Field 3. The Alt-Svc HTTP Header Field
An HTTP(S) origin server can advertise the availability of An HTTP(S) origin server can advertise the availability of
alternative services to clients by adding an Alt-Svc header field to alternative services to clients by adding an Alt-Svc header field to
responses. responses.
Alt-Svc = 1#( alternative *( OWS ";" OWS parameter ) ) Alt-Svc = clear / 1#alt-value
clear = %x63.6C.65.61.72; "clear", case-sensitive
alt-value = alternative *( OWS ";" OWS parameter )
alternative = protocol-id "=" alt-authority alternative = protocol-id "=" alt-authority
protocol-id = token ; percent-encoded ALPN protocol identifier protocol-id = token ; percent-encoded ALPN protocol name
alt-authority = quoted-string ; containing [ uri-host ] ":" port alt-authority = quoted-string ; containing [ uri-host ] ":" port
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
The field value consists either of a list of values, each of which
indicating one alternative service, or the keyword "clear".
A field value containing the special value "clear" indicates that the
origin requests all alternatives for that origin to be invalidated
(including those specified in the same response, in case of an
invalid reply containing both "clear" and alternative services).
ALPN protocol names are octet sequences with no additional ALPN protocol names are octet sequences with no additional
constraints on format. Octets not allowed in tokens ([RFC7230], constraints on format. Octets not allowed in tokens ([RFC7230],
Section 3.2.6) MUST be percent-encoded as per Section 2.1 of Section 3.2.6) MUST be percent-encoded as per Section 2.1 of
[RFC3986]. Consequently, the octet representing the percent [RFC3986]. Consequently, the octet representing the percent
character "%" (hex 25) MUST be percent-encoded as well. character "%" (hex 25) MUST be percent-encoded as well.
In order to have precisely one way to represent any ALPN protocol In order to have precisely one way to represent any ALPN protocol
name, the following additional constraints apply: name, the following additional constraints apply:
1. Octets in the ALPN protocol MUST NOT be percent-encoded if they 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if
are valid token characters except "%", and they are valid token characters except "%", and
2. When using percent-encoding, uppercase hex digits MUST be used. 2. When using percent-encoding, uppercase hex digits MUST be used.
With these constraints, recipients can apply simple string comparison With these constraints, recipients can apply simple string comparison
to match protocol identifiers. to match protocol identifiers.
The "alt-authority" component consists of an OPTIONAL uri-host The "alt-authority" component consists of an OPTIONAL uri-host
("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port
number. number.
skipping to change at page 9, line 42 skipping to change at page 10, line 26
| ALPN protocol name | protocol-id | Note | | ALPN protocol name | protocol-id | Note |
+--------------------+-------------+---------------------+ +--------------------+-------------+---------------------+
| h2 | h2 | No escaping needed | | h2 | h2 | No escaping needed |
+--------------------+-------------+---------------------+ +--------------------+-------------+---------------------+
| w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped |
+--------------------+-------------+---------------------+ +--------------------+-------------+---------------------+
| x%y | x%25y | "%" needs escaping | | x%y | x%25y | "%" needs escaping |
+--------------------+-------------+---------------------+ +--------------------+-------------+---------------------+
Alt-Svc MAY occur in any HTTP response message, regardless of the Alt-Svc MAY occur in any HTTP response message, regardless of the
status code. status code. Note that recipients of Alt-Svc are free to ignore the
header field (and indeed need to in some situations; see Sections 2.1
and 6).
The Alt-Svc field value can have multiple values: The Alt-Svc field value can have multiple values:
Alt-Svc: h2c=":8000", h2=":443" Alt-Svc: h2c=":8000", h2=":443"
When multiple values are present, the order of the values reflects
the server's preference (with the first value being the most
preferred alternative).
The value(s) advertised by Alt-Svc can be used by clients to open a The value(s) advertised by Alt-Svc can be used by clients to open a
new connection to one or more alternative services immediately, or new connection to an alternative service. Subsequent requests can
simultaneously with subsequent requests on the same connection. start using this new connection immediately, or can continue using
the existing connection while the new connection is created.
When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC
frame (Section 4). A single ALTSVC frame can be sent for a frame (Section 4). A single ALTSVC frame can be sent for a
connection; a new frame is not needed for every request. connection; a new frame is not needed for every request. Note that,
despite this recommendation, Alt-Svc header fields remain valid in
responses delivered over HTTP/2.
This specification defines two parameters: "ma" and "persist",
defined in Section 3.1. Unknown parameters MUST be ignored, that is
the values (alt-value) they appear in MUST be processed as if the
unknown parameter was not present.
New parameters can be defined in extension specifications (see
Section 7.3 for registration details).
Note that all field elements that allow "quoted-string" syntax MUST Note that all field elements that allow "quoted-string" syntax MUST
be processed as per Section 3.2.6 of [RFC7230]. be processed as per Section 3.2.6 of [RFC7230].
3.1. Caching Alt-Svc Header Field Values 3.1. Caching Alt-Svc Header Field Values
When an alternative service is advertised using Alt-Svc, it is When an alternative service is advertised using Alt-Svc, it is
considered fresh for 24 hours from generation of the message. This considered fresh for 24 hours from generation of the message. This
can be modified with the 'ma' (max-age) parameter: can be modified with the 'ma' (max-age) parameter:
skipping to change at page 10, line 47 skipping to change at page 11, line 48
alternative service is only fresh for the 30 seconds from when this alternative service is only fresh for the 30 seconds from when this
response was received, minus estimated transit time. response was received, minus estimated transit time.
Note that the freshness lifetime for HTTP caching (here, 600 seconds) Note that the freshness lifetime for HTTP caching (here, 600 seconds)
does not affect caching of Alt-Svc values. does not affect caching of Alt-Svc values.
When an Alt-Svc response header field is received from an origin, its When an Alt-Svc response header field is received from an origin, its
value invalidates and replaces all cached alternative services for value invalidates and replaces all cached alternative services for
that origin. that origin.
By default, cached alternative services will be cleared when the
client detects a network change. Alternative services that are
intended to be longer-lived (e.g., those that are not specific to the
client access network) can carry the "persist" parameter with a value
"1" as a hint that the service is potentially useful beyond a network
configuration change.
persist = 1DIGIT
For example:
Alt-Svc: h2=":443"; ma=2592000; persist=1
This specification only a defines a single value for "persist";
others can be defined in future specifications. Clients MUST ignore
"persist" parameters with unknown values.
See Section 2.2 for general requirements on caching alternative See Section 2.2 for general requirements on caching alternative
services. services.
4. The ALTSVC HTTP/2 Frame 4. The ALTSVC HTTP/2 Frame
The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the
availability of an alternative service to an HTTP/2 client. availability of an alternative service to an HTTP/2 client.
The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints
that do not support this frame can safely ignore it. that do not support this frame can safely ignore it.
skipping to change at page 11, line 50 skipping to change at page 13, line 20
alternative service is applicable to. alternative service is applicable to.
Alt-Svc-Field-Value: A sequence of octets (length determined by Alt-Svc-Field-Value: A sequence of octets (length determined by
subtracting the length of all preceding fields from the frame subtracting the length of all preceding fields from the frame
length) containing a value identical to the Alt-Svc field value length) containing a value identical to the Alt-Svc field value
defined in Section 3 (ABNF production "Alt-Svc"). defined in Section 3 (ABNF production "Alt-Svc").
The ALTSVC frame does not define any flags. The ALTSVC frame does not define any flags.
The ALTSVC frame is intended for receipt by clients; a server that The ALTSVC frame is intended for receipt by clients; a server that
receives an ALTSVC frame MUST treat it as a connection error of type receives an ALTSVC frame can safely ignore it.
PROTOCOL_ERROR.
An ALTSVC frame on stream 0 with empty (length 0) "Origin" An ALTSVC frame on stream 0 with empty (length 0) "Origin"
information is invalid and MUST be ignored. An ALTSVC frame on a information is invalid and MUST be ignored. An ALTSVC frame on a
stream other than stream 0 containing non-empty "Origin" information stream other than stream 0 containing non-empty "Origin" information
is invalid and MUST be ignored. is invalid and MUST be ignored.
The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT
forward ALTSVC frames, though it can use the information contained in forward ALTSVC frames, though it can use the information contained in
ALTSVC frames in forming new ALTSVC frames to send to its own ALTSVC frames in forming new ALTSVC frames to send to its own
clients. clients.
skipping to change at page 13, line 12 skipping to change at page 14, line 29
authoritative for the requested resource. This can be used to authoritative for the requested resource. This can be used to
indicate that an alternative service is not authoritative; see indicate that an alternative service is not authoritative; see
Section 2). Section 2).
Clients receiving 421 (Misdirected Request) from an alternative Clients receiving 421 (Misdirected Request) from an alternative
service MUST remove the corresponding entry from its alternative service MUST remove the corresponding entry from its alternative
service cache (see Section 2.2) for that origin. Regardless of the service cache (see Section 2.2) for that origin. Regardless of the
idempotency of the request method, they MAY retry the request, either idempotency of the request method, they MAY retry the request, either
at another alternative server, or at the origin. at another alternative server, or at the origin.
A 421 (Misdirected Request) response MAY carry an Alt-Svc header An Alt-Svc header field in a 421 (Misdirected Request) response MUST
field. be ignored.
7. IANA Considerations 7. IANA Considerations
7.1. Header Field Registrations 7.1. Header Field Registrations
HTTP header fields are registered within the "Message Headers" HTTP header fields are registered within the "Message Headers"
registry maintained at registry maintained at
<https://www.iana.org/assignments/message-headers/>. <https://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so their This document defines the following HTTP header fields, so their
skipping to change at page 14, line 5 skipping to change at page 15, line 16
This document registers the ALTSVC frame type in the HTTP/2 Frame This document registers the ALTSVC frame type in the HTTP/2 Frame
Types registry ([RFC7540], Section 11.2). Types registry ([RFC7540], Section 11.2).
Frame Type: ALTSVC Frame Type: ALTSVC
Code: 0xa Code: 0xa
Specification: Section 4 of this document Specification: Section 4 of this document
7.3. Alt-Svc Parameter Registry
The HTTP Alt-Svc Parameter Registry defines the name space for the
cache directives. It will be created and maintained at (the
suggested URI)
<http://www.iana.org/assignments/http-alt-svc-parameters>.
7.3.1. Procedure
A registration MUST include the following fields:
o Parameter Name
o Pointer to specification text
Values to be added to this name space require IETF Review (see
[RFC5226], Section 4.1).
7.3.2. Registrations
The HTTP Alt-Svc Parameter Registry is to be populated with the
registrations below:
+-------------------+-------------+
| Alt-Svc Parameter | Reference |
+-------------------+-------------+
| ma | Section 3.1 |
| persist | Section 3.1 |
+-------------------+-------------+
8. Internationalization Considerations 8. Internationalization Considerations
An internationalized domain name that appears in either the header An internationalized domain name that appears in either the header
field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed
using A-labels ([RFC5890], Section 2.3.2.1). using A-labels ([RFC5890], Section 2.3.2.1).
9. Security Considerations 9. Security Considerations
9.1. Changing Ports 9.1. Changing Ports
skipping to change at page 15, line 32 skipping to change at page 17, line 25
Therefore, clients cannot blindly use alternative services, but Therefore, clients cannot blindly use alternative services, but
instead evaluate the option(s) presented to assure that security instead evaluate the option(s) presented to assure that security
requirements and expectations (of specifications, implementations and requirements and expectations (of specifications, implementations and
end users) are met. end users) are met.
9.4. Tracking Clients Using Alternative Services 9.4. Tracking Clients Using Alternative Services
Choosing an alternative service implies connecting to a new, server- Choosing an alternative service implies connecting to a new, server-
supplied host name. By using many different (potentially unique) supplied host name. By using many different (potentially unique)
host names, servers could conceivably track client requests. host names, servers could conceivably track client requests. Such
tracking could follow users across multiple networks, when the
"persist" flag is used.
Clients concerned by the additional fingerprinting can choose to Clients concerned by the additional fingerprinting can choose to
ignore alternative service advertisements. ignore alternative service advertisements.
In a user agent, any alternative service information MUST be removed In a user agent, any alternative service information MUST be removed
when origin-specific data is cleared (for instance, when cookies are when origin-specific data is cleared (for instance, when cookies are
cleared). cleared).
9.5. Confusion Regarding Request Scheme 9.5. Confusion Regarding Request Scheme
Alternative Services MUST NOT be advertised for a protocol that is Alternative Services MUST NOT be advertised for a protocol that is
not designed to carry the scheme. In particular, HTTP/1.1 over TLS not designed to carry the scheme. In particular, HTTP/1.1 over TLS
cannot carry safely requests for http resources. cannot safely carry requests for http resources.
10. References 10. References
10.1. Normative References 10.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, March 1997, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008, Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <http://www.rfc-editor.org/info/rfc5890>.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011, Extension Definitions", RFC 6066, DOI 10.17487/RFC6066,
<http://www.rfc-editor.org/info/rfc6066>. January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011, <http://www.rfc-editor.org/info/rfc6454>. DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>. <http://www.rfc-editor.org/info/rfc7234>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, July 2014, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
<http://www.rfc-editor.org/info/rfc7301>. July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol version 2", RFC 7540, May 2015, Transfer Protocol version 2", RFC 7540, DOI 10.17487/
RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>. <http://www.rfc-editor.org/info/rfc7540>.
10.2. Informative References 10.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004, <http://www.rfc-editor.org/info/rfc3864>. September 2004, <http://www.rfc-editor.org/info/bcp90>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008, (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
Appendix A. Change Log (to be removed by RFC Editor before publication) Appendix A. Change Log (to be removed by RFC Editor before publication)
A.1. Since draft-nottingham-httpbis-alt-svc-05 A.1. Since draft-nottingham-httpbis-alt-svc-05
This is the first version after adoption of This is the first version after adoption of
draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It
only contains editorial changes. only contains editorial changes.
skipping to change at page 19, line 5 skipping to change at page 21, line 8
(<https://github.com/httpwg/http-extensions/issues/44>). (<https://github.com/httpwg/http-extensions/issues/44>).
"browser" -> "user agent" "browser" -> "user agent"
(<https://github.com/httpwg/http-extensions/pull/61>). (<https://github.com/httpwg/http-extensions/pull/61>).
ABNF for "parameter" ABNF for "parameter"
(<https://github.com/httpwg/http-extensions/issues/65>). (<https://github.com/httpwg/http-extensions/issues/65>).
Updated HTTP/2 reference. Updated HTTP/2 reference.
A.9. Since draft-ietf-httpbis-alt-svc-07
Alt-Svc alternative cache invalidation
(<https://github.com/httpwg/http-extensions/issues/16>).
Unexpected Alt-Svc frames
(<https://github.com/httpwg/http-extensions/issues/18>).
Associating Alt-Svc header with an origin
(<https://github.com/httpwg/http-extensions/issues/21>).
ALPN identifiers in Alt-Svc
(<https://github.com/httpwg/http-extensions/issues/43>).
Number of alternate services used
(<https://github.com/httpwg/http-extensions/issues/58>).
Proxy and .pac interaction
(<https://github.com/httpwg/http-extensions/issues/62>).
Need to define extensibility for alt-svc parameters
(<https://github.com/httpwg/http-extensions/issues/69>).
Persistence of alternates across network changes
(<https://github.com/httpwg/http-extensions/issues/71>).
Alt-Svc header with 421 status
(<https://github.com/httpwg/http-extensions/issues/75>).
Incorporate several editorial improvements suggested by Mike Bishop
(<https://github.com/httpwg/http-extensions/pull/77>,
<https://github.com/httpwg/http-extensions/pull/78>).
Alt-Svc response header field in HTTP/2 frame
(<https://github.com/httpwg/http-extensions/issues/87>).
Appendix B. Acknowledgements Appendix B. Acknowledgements
Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy
Podjarny, Herve Ruellan, Martin Thomson, Matthew Kerwin, Paul Podjarny, Herve Ruellan, Martin Thomson, Matthew Kerwin, Mike Bishop,
Hoffman, Richard Barnes, Stephen Farrell, Stephen Ludin, and Will Paul Hoffman, Richard Barnes, Stephen Farrell, Stephen Ludin, and
Chan for their feedback and suggestions. Will Chan for their feedback and suggestions.
The Alt-Svc header field was influenced by the design of the The Alt-Svc header field was influenced by the design of the
Alternate-Protocol header field in SPDY. Alternate-Protocol header field in SPDY.
Authors' Addresses Authors' Addresses
Mark Nottingham Mark Nottingham
Akamai Akamai
EMail: mnot@mnot.net EMail: mnot@mnot.net
 End of changes. 47 change blocks. 
80 lines changed or deleted 222 lines changed or added

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