< draft-ietf-httpbis-alt-svc-04.txt		draft-ietf-httpbis-alt-svc-05.txt >
	HTTPbis Working Group M. Nottingham		HTTPbis Working Group M. Nottingham
	Internet-Draft Akamai		Internet-Draft Akamai
	Intended status: Standards Track P. McManus		Intended status: Standards Track P. McManus
	Expires: April 30, 2015 Mozilla		Expires: June 4, 2015 Mozilla
	J. Reschke		J. Reschke
	greenbytes		greenbytes
	October 27, 2014		December 1, 2014
	HTTP Alternative Services		HTTP Alternative Services
	draft-ietf-httpbis-alt-svc-04		draft-ietf-httpbis-alt-svc-05
	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 April 30, 2015.		This Internet-Draft will expire on June 4, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 2, line 32 ¶		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 . . . . . . . . . . . . . . . . . . . 6		2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . 10
	4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 10		4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 10
	5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 12		5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 11
	6. The 421 Not Authoritative HTTP Status Code . . . . . . . . . . 13		6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Header Field Registrations . . . . . . . . . . . . . . . . 13		7.1. Header Field Registrations . . . . . . . . . . . . . . . . 12
	7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 14		7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 13
	8. Internationalization Considerations . . . . . . . . . . . . . 14		8. Internationalization Considerations . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 14		9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 13
	9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 14		9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 14
	9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 15		9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 14
	9.4. Tracking Clients Using Alternative Services . . . . . . . 15		9.4. Tracking Clients Using Alternative Services . . . . . . . 15
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 16		11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . . 16
	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) . . . . . . . . . . . . . . . . . . . . 16
	A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 17		A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 16
	A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 17		A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 16
	A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 17		A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 16
	A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 17		A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 17
	A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 18		A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 17
			A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 17
	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.
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	with the origin of that stream.		with the origin of that stream.
	An ALTSVC frame from a server to a client on stream 0 indicates that		An ALTSVC frame from a server to a client on stream 0 indicates that
	the conveyed alternative service is associated with the origin		the conveyed alternative service is associated with the origin
	contained in the Origin field of the frame. An association with an		contained in the Origin field of the frame. An association with an
	origin that the client does not consider authoritative for the		origin that the client does not consider authoritative for the
	current connection MUST be ignored.		current connection MUST be ignored.
	The ALTSVC frame type is 0xa (decimal 10).		The ALTSVC frame type is 0xa (decimal 10).
	0 1 2 3		The payload of an ALTSVC frame is identical to the payload of the
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		Alt-Svc field value defined in Section 3 (ABNF production "Alt-Svc").
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Max-Age (32) |
	+-------------------------------+---------------+---------------+
	| Port (16) | Proto-Len (8) |
	+-------------------------------+---------------+---------------+
	| Protocol-ID (*) |
	+---------------+-----------------------------------------------+
	| Host-Len (8) | Host (*) ...
	+---------------+-----------------------------------------------+
	| Origin? (*) ...
	+---------------------------------------------------------------+
	ALTSVC Frame Payload
	The ALTSVC frame contains the following fields:
	Max-Age: An unsigned, 32-bit integer indicating the freshness
	lifetime of the alternative service association, as per
	Section 2.2.
	Port: An unsigned, 16-bit integer indicating the port that the
	alternative service is available upon.
	Proto-Len: An unsigned, 8-bit integer indicating the length, in
	octets, of the Protocol-ID field.
	Protocol-ID: A sequence of bytes (length determined by "Proto-Len")
	containing the ALPN protocol identifier of the alternative
	service.
	Host-Len: An unsigned, 8-bit integer indicating the length, in
	octets, of the Host header field.
	Host: A sequence of characters (length determined by "Host-Len")
	containing an ASCII string indicating the host that the
	alternative service is available upon.
	Origin: An OPTIONAL sequence of characters (length determined by
	subtracting the length of all preceding fields from the frame
	length) containing the ASCII serialization of an origin
	([RFC6454], Section 6.2) that the alternate service is applicable
	to.
	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 MUST treat it as a connection error of type
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	An ALTSVC frame on a client-initiated stream containing non-empty		An ALTSVC frame on a client-initiated stream containing non-empty
	"Origin" information is invalid and MUST be ignored. Likewise, an		"Origin" information is invalid and MUST be ignored. Likewise, an
	ALTSVC frame on stream 0 with empty (length 0) "Origin" information		ALTSVC frame on stream 0 with empty (length 0) "Origin" information
	skipping to change at page 13, line 15 ¶		skipping to change at page 12, line 18 ¶
	For example:		For example:
	GET /thing HTTP/1.1		GET /thing HTTP/1.1
	Host: origin.example.com		Host: origin.example.com
	Alt-Used: 1		Alt-Used: 1
	The extension parameters (ext-param) are reserved for future use;		The extension parameters (ext-param) are reserved for future use;
	specifications that want to define an extension will need to update		specifications that want to define an extension will need to update
	this document (and ought to introduce an extension registry).		this document (and ought to introduce an extension registry).
	6. The 421 Not Authoritative HTTP Status Code		6. The 421 Misdirected Request HTTP Status Code
	The 421 (Not Authoritative) status code is defined in [HTTP2],		The 421 (Misdirected Request) status code is defined in Section 9.1.2
	Section 9.1.2 to indicate that the current server instance is not		of [HTTP2] to indicate that the current server instance is not
	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 (Not Authoritative) from an alternative service		Clients receiving 421 (Misdirected Request) from an alternative
	MUST remove the corresponding entry from its alternative service		service MUST remove the corresponding entry from its alternative
	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 (Not Authoritative) response MAY carry an Alt-Svc header field.		A 421 (Misdirected Request) response MAY carry an Alt-Svc header
			field.
	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 15, line 41 ¶		skipping to change at page 15, line 7 ¶
	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
	The Alt-Used header field (Section 5) provides a server with one		Choosing an alternative service implies connecting to a new, server-
	additional bit of information that can be used to correlate requests.		supplied host name. By using many different (potentially unique)
			host names, servers could conceivably track client requests.
	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 browser, any alternative service information MUST be removed		In a browser, 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).
	10. Acknowledgements		10. Acknowledgements
	skipping to change at page 16, line 19 ¶		skipping to change at page 15, line 32 ¶
	Chan for their feedback and suggestions.		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.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol version 2", draft-ietf-httpbis-http2-14		Transfer Protocol version 2", draft-ietf-httpbis-http2-16
	(work in progress), July 2014.		(work in progress), November 2014.
	[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, March 1997.
	[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, January 2005.
	[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, January 2008.
	skipping to change at page 18, line 16 ¶		skipping to change at page 17, line 29 ¶
	Renamed "Alt-Svc-Used" to "Alt-Used"		Renamed "Alt-Svc-Used" to "Alt-Used"
	(<https://github.com/httpwg/http-extensions/issues/17>).		(<https://github.com/httpwg/http-extensions/issues/17>).
	Clarify ALTSVC Origin information requirements		Clarify ALTSVC Origin information requirements
	(<https://github.com/httpwg/http-extensions/issues/19>).		(<https://github.com/httpwg/http-extensions/issues/19>).
	Remove/tune language with respect to tracking risks (see		Remove/tune language with respect to tracking risks (see
	<https://github.com/httpwg/http-extensions/issues/34>).		<https://github.com/httpwg/http-extensions/issues/34>).
			A.6. Since draft-ietf-httpbis-alt-svc-04
			Mention tracking by alt-svc host name in Security Considerations
			(<https://github.com/httpwg/http-extensions/issues/36>).
			"421 (Not Authoritative)" -> "421 (Misdirected Request)".
			Allow the frame to carry multiple indicator and use the same payload
			formats for both
			(<https://github.com/httpwg/http-extensions/issues/37>).
	Authors' Addresses		Authors' Addresses
	Mark Nottingham		Mark Nottingham
	Akamai		Akamai
	EMail: mnot@mnot.net		EMail: mnot@mnot.net
	URI: https://www.mnot.net/		URI: https://www.mnot.net/
	Patrick McManus		Patrick McManus
	Mozilla		Mozilla
	EMail: mcmanus@ducksong.com		EMail: mcmanus@ducksong.com
	URI: https://mozillians.org/u/pmcmanus/		URI: https://mozillians.org/u/pmcmanus/
	Julian F. Reschke		Julian F. Reschke
	greenbytes GmbH		greenbytes GmbH
	EMail: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
End of changes. 18 change blocks.
	78 lines changed or deleted		49 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/