draft-ietf-httpbis-alt-svc-09.txt   draft-ietf-httpbis-alt-svc-10.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: May 20, 2016 Mozilla Expires: June 17, 2016 Mozilla
J. Reschke J. Reschke
greenbytes greenbytes
November 17, 2015 December 15, 2015
HTTP Alternative Services HTTP Alternative Services
draft-ietf-httpbis-alt-svc-09 draft-ietf-httpbis-alt-svc-10
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)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
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 May 20, 2016. This Internet-Draft will expire on June 17, 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 17 skipping to change at page 3, line 17
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 . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 8 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 8
3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 9 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 9
3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11
4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12
5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 13 5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 14
6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14 6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Header Field Registrations . . . . . . . . . . . . . . . . 14 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 14
7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15
7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15 7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15
7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 15 7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 15
8. Internationalization Considerations . . . . . . . . . . . . . 15 8. Internationalization Considerations . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 16
9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17
9.4. Tracking Clients Using Alternative Services . . . . . . . 17 9.4. Tracking Clients Using Alternative Services . . . . . . . 18
9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 20 publication) . . . . . . . . . . . . . . . . . . . . 20
A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20
A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20
A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 20 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 20
A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21
A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21
A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21
A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 21 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 21
A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 21 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 22
A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22
A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 22 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23 A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 24
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
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://") URIs 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 is under load, or it has found a server in a server when it is under load, or it has found a server in a
skipping to change at page 5, line 15 skipping to change at page 5, line 15
DIGIT = <DIGIT, see [RFC5234], Appendix B.1> 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
service". When an origin (see [RFC6454]) has resources that are Service". When an origin (see [RFC6454]) has resources that are
accessible through a different protocol / host / port combination, it accessible through a different protocol / host / port combination, it
is said to have an alternative service available. is said to have an alternative service available.
An alternative service can be used to interact with the resources on An alternative service can be used to interact with the resources on
an origin server at a separate location on the network, possibly an origin server at a separate location on the network, possibly
using a different protocol configuration. Alternative services are using a different protocol configuration. Alternative services are
considered authoritative for an origin's resources, in the sense of considered authoritative for an origin's resources, in the sense of
[RFC7230], Section 9.1. [RFC7230], Section 9.1.
For example, an origin: For example, an origin:
skipping to change at page 5, line 47 skipping to change at page 5, line 47
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 the origin of these routes -- the default route is derived from the origin
itself and the other routes are introduced based on alternative- itself and the other routes are introduced based on alternative-
protocol information. service 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 46 skipping to change at page 6, line 46
specified otherwise in its definition. In particular, the ALPN name specified otherwise in its definition. In particular, the ALPN name
"http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1 "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1
over TLS. 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: the "Alt-Svc" HTTP header field (Section 3) and the
type (Section 4). "ALTSVC" HTTP/2 frame type (Section 4).
The remainder of this section describes requirements that are common The remainder of this section describes requirements that are common
to alternative services, regardless of how they are discovered. to alternative services, regardless of how they are discovered.
2.1. Host Authentication 2.1. Host Authentication
Clients MUST NOT use alternative services with a host that is Clients MUST NOT use alternative services with a host that is
different than the origin's without strong server authentication; different than the origin's without strong server authentication;
this mitigates the attack described in Section 9.2. One way to this mitigates the attack described in Section 9.2. One way to
achieve this is for the alternative to use TLS with a certificate achieve this is for the alternative to use TLS with a certificate
skipping to change at page 8, line 8 skipping to change at page 8, line 8
network state is available). 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).
2.4. Using Alternative Services 2.4. Using Alternative Services
By their nature, alternative services are OPTIONAL: clients do not By their nature, alternative services are OPTIONAL: clients do not
need to use them. However, it is advantageous for clients to behave need to use them. However, it is advantageous for clients to behave
in a predictable way when they are used by servers (e.g., for load in a predictable way when they are used by servers (e.g., for load
balancing). balancing).
Therefore, if a client becomes aware of an alternative service, the Therefore, if a client becomes aware of an alternative service, the
client SHOULD use that alternative service for all requests to the client SHOULD use that alternative service for all requests to the
associated origin as soon as it is available, provided the associated origin as soon as it is available, provided the
alternative service information is fresh (Section 2.2) and the alternative service information is fresh (Section 2.2) and the
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. A viable
alternative service is then treated in every way as the origin; this
includes the ability to advertise alternative services.
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.
itself advertise an alternative.
A client configured to use a proxy for a given request SHOULD NOT A client configured to use a proxy for a given request SHOULD NOT
directly connect to an alternative service for it, but instead route directly connect to an alternative service for this request, but
it through that proxy. 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
skipping to change at page 11, line 7 skipping to change at page 11, line 7
new connection to an alternative service. Subsequent requests can new connection to an alternative service. Subsequent requests can
start using this new connection immediately, or can continue using start using this new connection immediately, or can continue using
the existing connection while the new connection is created. 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. Note that, connection; a new frame is not needed for every request. Note that,
despite this recommendation, Alt-Svc header fields remain valid in despite this recommendation, Alt-Svc header fields remain valid in
responses delivered over HTTP/2. responses delivered over HTTP/2.
Each "alt-value" is followed by an OPTIONAL semicolon-separated list
of additional parameters, each such "parameter" comprising a name and
a value.
This specification defines two parameters: "ma" and "persist", This specification defines two parameters: "ma" and "persist",
defined in Section 3.1. Unknown parameters MUST be ignored, that is 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 the values (alt-value) they appear in MUST be processed as if the
unknown parameter was not present. unknown parameter was not present.
New parameters can be defined in extension specifications (see New parameters can be defined in extension specifications (see
Section 7.3 for registration details). 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.
Alt-Svc: h2=":443"; ma=3600 Syntax:
which indicates the number of seconds since the response was ma = delta-seconds; see [RFC7234], Section 1.2.1
generated the alternative service is considered fresh for.
ma = delta-seconds The delta-seconds value indicates the number of seconds since the
response was generated the alternative service is considered fresh
for.
Alt-Svc: h2=":443"; ma=3600
See Section 4.2.3 of [RFC7234] for details of determining response See Section 4.2.3 of [RFC7234] for details of determining response
age. age.
For example, a response: For example, a response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
Cache-Control: max-age=600 Cache-Control: max-age=600
Age: 30 Age: 30
skipping to change at page 12, line 14 skipping to change at page 12, line 21
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 By default, cached alternative services will be cleared when the
client detects a network change. Alternative services that are client detects a network change. Alternative services that are
intended to be longer-lived (e.g., those that are not specific to the 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 client access network) can carry the "persist" parameter with a value
"1" as a hint that the service is potentially useful beyond a network "1" as a hint that the service is potentially useful beyond a network
configuration change. configuration change.
Syntax:
persist = 1DIGIT persist = 1DIGIT
For example: For example:
Alt-Svc: h2=":443"; ma=2592000; persist=1 Alt-Svc: h2=":443"; ma=2592000; persist=1
This specification only a defines a single value for "persist"; This specification only a defines a single value for "persist";
others can be defined in future specifications. Clients MUST ignore others can be defined in future specifications. Clients MUST ignore
"persist" parameters with unknown values. "persist" parameters with unknown values.
skipping to change at page 13, line 35 skipping to change at page 13, line 45
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.
Receiving an ALTSVC frame is semantically equivalent to receiving an
Alt-Svc header field. As a result, the ALTSVC frame causes
alternative services for the corresponding origin to be replaced.
Note that it would be unwise to mix the use of Alt-Svc header fields
with the use of ALTSVC frames, as the sequence of receipt might be
hard to predict.
5. The Alt-Used HTTP Header Field 5. The Alt-Used HTTP Header Field
The Alt-Used header field is used in requests to indicate the The Alt-Used header field is used in requests to indicate the
identity of the alternative service in use, just as the Host header identity of the alternative service in use, just as the Host header
field (Section 5.4 of [RFC7230]) identifies the host and port of the field (Section 5.4 of [RFC7230]) identifies the host and port of the
origin. origin.
Alt-Used = uri-host [ ":" port ] Alt-Used = uri-host [ ":" port ]
Alt-Used is intended to allow alternative services to detect loops, Alt-Used is intended to allow alternative services to detect loops,
differentiate traffic for purposes of load balancing, and generally differentiate traffic for purposes of load balancing, and generally
to ensure that it is possible to identify the intended destination of to ensure that it is possible to identify the intended destination of
traffic, since introducing this information after a protocol is in traffic, since introducing this information after a protocol is in
use has proven to be problematic. use has proven to be problematic.
When using an alternative service, clients SHOULD include a Alt-Used When using an alternative service, clients SHOULD include an Alt-Used
header field in all requests. header field in all requests.
As the Alt-Used header field might be used by the server for tracking
the client, a client MAY choose not to include it in its requests for
protecting its privacy (see Section 9.4).
For example: For example:
GET /thing HTTP/1.1 GET /thing HTTP/1.1
Host: origin.example.com Host: origin.example.com
Alt-Used: alternate.example.net Alt-Used: alternate.example.net
6. The 421 Misdirected Request HTTP Status Code 6. The 421 Misdirected Request HTTP Status Code
The 421 (Misdirected Request) status code is defined in Section 9.1.2 The 421 (Misdirected Request) status code is defined in Section 9.1.2
of [RFC7540] to indicate that the current server instance is not of [RFC7540] to indicate that the current server instance is not
skipping to change at page 15, line 18 skipping to change at page 15, line 32
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 7.3. Alt-Svc Parameter Registry
The HTTP Alt-Svc Parameter Registry defines the name space for the The HTTP Alt-Svc Parameter Registry defines the name space for
cache directives. It will be created and maintained at (the parameters. It will be created and maintained at (the suggested URI)
suggested URI)
<http://www.iana.org/assignments/http-alt-svc-parameters>. <http://www.iana.org/assignments/http-alt-svc-parameters>.
7.3.1. Procedure 7.3.1. Procedure
A registration MUST include the following fields: A registration MUST include the following fields:
o Parameter Name o Parameter Name
o Pointer to specification text o Pointer to specification text
skipping to change at page 16, line 49 skipping to change at page 17, line 13
origin. origin.
For example, if an attacker can convince a user agent to send all For example, if an attacker can convince a user agent to send all
traffic for "innocent.example.org" to "evil.example.com" by traffic for "innocent.example.org" to "evil.example.com" by
successfully associating it as an alternative service, they can successfully associating it as an alternative service, they can
masquerade as that origin. This can be done locally (see mitigations masquerade as that origin. This can be done locally (see mitigations
in Section 9.1) or remotely (e.g., by an intermediary as a man-in- in Section 9.1) or remotely (e.g., by an intermediary as a man-in-
the-middle attack). the-middle attack).
This is the reason for the requirement in Section 2.1 that any This is the reason for the requirement in Section 2.1 that any
alternative service with a host different to the origin's be strongly alternative service with a host different from the origin's be
authenticated with the origin's identity; i.e., presenting a strongly authenticated with the origin's identity; i.e., presenting a
certificate for the origin proves that the alternative service is certificate for the origin proves that the alternative service is
authorized to serve traffic for the origin. authorized to serve traffic for the origin.
However, this authorization is only as strong as the method used to However, this authorization is only as strong as the method used to
authenticate the alternative service. In particular, there are well- authenticate the alternative service. In particular, there are well-
known exploits to make an attacker's certificate appear as known exploits to make an attacker's certificate appear as
legitimate. legitimate.
Alternative services could be used to persist such an attack; for Alternative services could be used to persist such an attack; for
example, an intermediary could man-in-the-middle TLS-protected example, an intermediary could man-in-the-middle TLS-protected
skipping to change at page 17, line 30 skipping to change at page 17, line 43
other requirements around which certificates are acceptable for other requirements around which certificates are acceptable for
alternative services. alternative services.
9.3. Changing Protocols 9.3. Changing Protocols
When the ALPN protocol is changed due to the use of an alternative When the ALPN protocol is changed due to the use of an alternative
service, the security properties of the new connection to the origin service, the security properties of the new connection to the origin
can be different from that of the "normal" connection to the origin, can be different from that of the "normal" connection to the origin,
because the protocol identifier itself implies this. because the protocol identifier itself implies this.
For example, if a "https://" URI has a protocol advertised that does For example, if an "https://" URI has a protocol advertised that does
not use some form of end-to-end encryption (most likely, TLS), it not use some form of end-to-end encryption (most likely, TLS), it
violates the expectations for security that the URI scheme implies. violates the expectations for security that the URI scheme implies.
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
skipping to change at page 18, line 9 skipping to change at page 18, line 24
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
Some server-side HTTP applications make assumptions about security Some server-side HTTP applications make assumptions about security
based upon connection context; for example, equating being served based upon connection context; for example, equating being served
upon port 443 with the use of a HTTPS URL (and the various security upon port 443 with the use of an "https://" URI (and the various
properties that implies). security properties that implies).
This affects not only the security properties of the connection This affects not only the security properties of the connection
itself, but also the state of the client at the other end of it; for itself, but also the state of the client at the other end of it; for
example, a Web browser treats HTTPS URLs differently than HTTP URLs example, a Web browser treats "https://" URIs differently than
in many ways, not just for purposes of protocol handling. "http://" URIs in many ways, not just for purposes of protocol
handling.
Since one of the uses of Alternative Services is to allow a Since one of the uses of Alternative Services is to allow a
connection to be migrated to a different protocol and port, these connection to be migrated to a different protocol and port, these
applications can become confused about the security properties of a applications can become confused about the security properties of a
given connection, sending information (e.g., cookies, content) that given connection, sending information (e.g., cookies, content) that
is intended for a secure context (e.g., a HTTPS URL) to a client that is intended for a secure context (e.g., an "https://" URI) to a
is not treating it as one. client that is not treating it as one.
This risk can be mitigated in servers by using the URL scheme This risk can be mitigated in servers by using the URI scheme
explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the
"absolute form" of the request target in HTTP/1.1) as an indication "absolute form" of the request target in HTTP/1.1) as an indication
of security context, instead of other connection properties of security context, instead of other connection properties
([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2).
When the protocol does not explicitly carry the scheme (e.g., as is When the protocol does not explicitly carry the scheme (e.g., as is
usually the case for HTTP/1.1 over TLS, servers can, mitigate this usually the case for HTTP/1.1 over TLS, servers can, mitigate this
risk by either assuming that all requests have an insecure context, risk by either assuming that all requests have an insecure context,
or by refraining from advertising alternative services for insecure or by refraining from advertising alternative services for insecure
schemes (such as HTTP). schemes (such as HTTP).
skipping to change at page 23, line 36 skipping to change at page 24, line 5
Alt-svc vs the ability to convey the scheme inside the protocol Alt-svc vs the ability to convey the scheme inside the protocol
(<https://github.com/httpwg/http-extensions/issues/92>). (<https://github.com/httpwg/http-extensions/issues/92>).
Reconciling MAY/can vs. SHOULD Reconciling MAY/can vs. SHOULD
(<https://github.com/httpwg/http-extensions/issues/101>). (<https://github.com/httpwg/http-extensions/issues/101>).
Typo in alt-svc caching example Typo in alt-svc caching example
(<https://github.com/httpwg/http-extensions/issues/117>). (<https://github.com/httpwg/http-extensions/issues/117>).
A.11. Since draft-ietf-httpbis-alt-svc-09
Editorial improvements
(<https://github.com/httpwg/http-extensions/issues/118>,
<https://github.com/httpwg/http-extensions/issues/119>,
<https://github.com/httpwg/http-extensions/issues/120>,
<https://github.com/httpwg/http-extensions/issues/121>,
<https://github.com/httpwg/http-extensions/issues/122>,
<https://github.com/httpwg/http-extensions/issues/123>,
<https://github.com/httpwg/http-extensions/issues/125>,
<https://github.com/httpwg/http-extensions/issues/126>).
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, Mike Bishop, Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew
Paul Hoffman, Richard Barnes, Richard Bradbury, Stephen Farrell, Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury,
Stephen Ludin, and Will Chan for their feedback and suggestions. Stephen Farrell, Stephen Ludin, and 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. 37 change blocks. 
52 lines changed or deleted 79 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/