HTTP Alternative Services
Extracted elements (30)
Alternative services do not replace the origin for any resource and are not visible to software above the access mechanism. They are analogous to DNS CNAME or SRV records — alternative routing information that does not change the identity or security context (including TLS certificate validation against the origin host name, not the alternative's) of the resource being accessed.
The Alt-Used header field was introduced to allow alternative services to detect loops, differentiate load-balanced traffic, and identify intended destinations, because introducing this information after a protocol is in use has proven to be problematic.
The ALPN protocol name 'http/1.1', registered by RFC 7301 Section 6, identifies HTTP/1.1 over TLS. An ALPN protocol name implicitly includes TLS unless specified otherwise in its definition, so the h2c (cleartext HTTP/2) protocol cannot be used as an alternative service for origins requiring TLS authentication.
A client configured to use a proxy for a given request SHOULD NOT directly connect to an alternative service for that request, but instead route it through the proxy.
A client MUST NOT use a TLS-based alternative service unless the client supports TLS Server Name Indication (SNI), to support conservation of IP addresses on the alternative service host.
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. Unknown Alt-Svc parameters MUST be ignored and alt-values containing them MUST be processed as if the unknown parameter was not present.
An ALTSVC frame on stream 0 with empty Origin information is invalid and MUST be ignored. An ALTSVC frame on a stream other than stream 0 containing non-empty Origin information is invalid and MUST be ignored. A device acting as a server MUST ignore ALTSVC frames.
Changes to host, port, and protocol when using an alternative service MUST NOT be propagated to the application using HTTP; from the application's standpoint, the URI being accessed and all information derived from it (scheme, host, and port) are the same as before.
Clients MUST have reasonable assurances that the alternative service is under control of and valid for the whole origin, established through use of a TLS-based protocol with the certificate checks defined in RFC 2818. Clients MAY impose additional criteria.
Clients MUST ignore 'persist' parameters with values other than '1'. When an Alt-Svc response header field is received from an origin, its value invalidates and replaces all cached alternative services for that origin.
Clients receiving 421 (Misdirected Request) from an alternative service MUST remove the corresponding entry from its alternative service cache for that origin. An Alt-Svc header field in a 421 response MUST be ignored.
Clients SHOULD remove from cache all alternative services that lack the 'persist' flag with value '1' when they detect a network change, when information about network state is available.
If a client supporting this specification becomes aware of an alternative service, the client SHOULD use that alternative service for all requests to the associated origin as soon as it is available, provided the alternative service information is fresh and the security properties are desirable compared to the existing connection.
If the connection to the alternative service does not negotiate the expected protocol (e.g., ALPN fails to negotiate h2, or an Upgrade request to h2c is not accepted), the connection to the alternative service MUST be considered to have failed.
Internationalized domain names appearing in the Alt-Svc header field or the ALTSVC HTTP/2 frame MUST be expressed using A-labels (per RFC 5890 Section 2.3.2.1).
The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT forward ALTSVC frames, though it can use the information to form new ALTSVC frames to send to its own clients.
When using an alternative service, clients SHOULD include an Alt-Used header field in all requests.
When using HTTP/2, servers SHOULD instead send an ALTSVC frame rather than an Alt-Svc header field. A single ALTSVC frame can be sent for a connection; a new frame is not needed for every request.
Using alternative services implies connecting to a new server-supplied host name; servers could use unique names to track client requests across networks, especially when the 'persist' flag is used. In a user agent, any alternative service information MUST be removed when origin-specific data (e.g., cookies) is cleared.
An Alternative Service is identified by the combination of an ALPN protocol name (per RFC 7301), a host (per RFC 3986 Section 3.2.2), and a port (per RFC 3986 Section 3.2.3). Alternative services are considered authoritative for an origin's resources and do not replace or change the origin for any given resource.
The Alt-Svc 'ma' (max-age) parameter specifies the freshness lifetime in delta-seconds. When not present, the default freshness lifetime is 24 hours. The 'persist' parameter with value '1' hints that the alternative service should survive network configuration changes.
The Alt-Used HTTP header field identifies the alternative service in use in requests, using the syntax: Alt-Used = uri-host [ ":" port ]. It is intended to allow alternative services to detect loops, differentiate traffic for load balancing, and identify intended traffic destinations.
This document creates the 'Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry' with Expert Review procedure. Initial registrations include the 'ma' and 'persist' parameters, each pointing to Section 3.1.
This document registers the Alt-Svc and Alt-Used HTTP header fields in the 'Message Headers' registry, and registers the ALTSVC frame type (code 0xa) in the 'HTTP/2 Frame Type' registry.
An attacker that can inject alternative services and listen at the advertised port can hijack an origin. On servers with user-controlled pages on shared ports or less-privileged ports, an attacker can redirect traffic for an entire origin to an attacker-controlled port using the Alt-Svc header field. This risk is mitigated by the host authentication requirements in Section 2.1.
Server-side applications may confuse connection context with security context (e.g., equating port 443 with https://), which can lead to sending sensitive data over an insecure alternative service. Servers should use the URI scheme as carried by the protocol (e.g., ':scheme' in HTTP/2) rather than connection properties to determine security context.
When the ALPN protocol is changed via an alternative service, the security properties of the new connection may differ. Clients cannot blindly use alternative services but must evaluate that security requirements of specifications, implementations, and end users are met — for example, an 'https://' URI must not be redirected to a protocol without end-to-end encryption.
When the host is changed via alternative services, attackers could hijack communication by masquerading as an origin. Alternative services could be used to persist such attacks by directing traffic to an attacker's service with a large freshness lifetime. Implementations MUST perform certificate-pinning validation on alternative services just as for direct connections to the origin.
The Alt-Svc header field uses the ABNF: Alt-Svc = clear / 1#alt-value; alt-value = alternative *( OWS ";" OWS parameter ); alternative = protocol-id "=" alt-authority; alt-authority = quoted-string containing [ uri-host ] ":" port. ALPN protocol names with non-token octets MUST be percent-encoded using uppercase hex digits.
The ALTSVC HTTP/2 frame (type 0xa, decimal 10) payload contains: Origin-Len (16-bit unsigned integer), an optional Origin field (ASCII serialization of an origin), and Alt-Svc-Field-Value (remaining octets, identical to the Alt-Svc header field value). The frame defines no flags.