< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/