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