RFC 7838

HTTP Alternative Services

📅 published April 2016, from ietf

HTTP Alternative Services 🦋

Okay bestie, this one is RFC 7838 and it's a Standards Track doc, so it's the real deal 💅. It came out in April 2016 and has ISSN 2070-1721. The authors are M. Nottingham (Akamai), P. McManus (Mozilla), and J. Reschke (greenbytes). The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 🌸.

Abstract ✨

This doc specifies "Alternative Services" for HTTP. The idea is that an origin's resources can be authoritatively available at a separate network location, possibly reached with a different protocol configuration 🧚.

Status of This Memo 📜

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7838. 🔗

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 🙈.

Table of Contents 🗺️

1. Introduction ....................................................2
   1.1. Notational Conventions .....................................3
2. Alternative Services Concepts ...................................3
   2.1. Host Authentication ........................................5
   2.2. Alternative Service Caching ................................6
   2.3. Requiring Server Name Indication ...........................6
   2.4. Using Alternative Services .................................6
3. The Alt-Svc HTTP Header Field ...................................8
   3.1. Caching Alt-Svc Header Field Values .......................10
4. The ALTSVC HTTP/2 Frame ........................................11
5. The Alt-Used HTTP Header Field .................................13
6. The 421 (Misdirected Request) HTTP Status Code .................13
7. IANA Considerations ............................................13
   7.1. Header Field Registrations ................................13
   7.2. The ALTSVC HTTP/2 Frame Type ..............................14
   7.3. Alt-Svc Parameter Registry ................................14
        7.3.1. Procedure ..........................................14
        7.3.2. Registrations ......................................15
8. Internationalization Considerations ............................15
9. Security Considerations ........................................15
   9.1. Changing Ports ............................................15
   9.2. Changing Hosts ............................................15
   9.3. Changing Protocols ........................................16
   9.4. Tracking Clients Using Alternative Services ...............17
   9.5. Confusion regarding Request Scheme ........................17
10. References ....................................................18
   10.1. Normative References .....................................18
   10.2. Informative References ...................................19
Acknowledgements ..................................................19
Authors' Addresses ................................................20

1. Introduction ✨

HTTP [RFC7230] kinda mixes up what a resource is with where it lives. "http://" and "https://" URIs are used both to name things and to find them 💅.

Sometimes it's useful to separate identification from location in HTTP. You keep the same identifier for a resource, but you interact with it at a different spot on the network 🦋.

For example:

  • An origin server might want to redirect a client to a different server when it's under load, or when it has found a server that's more local to the client.
  • An origin server might want to offer access to its resources using a new protocol, such as HTTP/2 [RFC7540], or one with improved security, such as Transport Layer Security (TLS) [RFC5246].
  • An origin server might want to segment its clients into groups of capabilities, such as those that support Server Name Indication (SNI) (Section 3 of [RFC6066]), for operational purposes.

This spec introduces a new HTTP concept called "Alternative Services," which lets an origin server nominate extra ways of interacting with it on the network 🧚. Section 2 gives the general framework. Section 3 covers advertising alternatives with HTTP header fields, and Section 4 covers doing it with HTTP/2 frames. Section 5 is a way to say that an alternative service was used 💖.

It also endorses the status code 421 (Misdirected Request) (Section 6). Origin servers, or their nominated alternatives, can use it to say they aren't authoritative for a given origin, in cases where the wrong location got used 🙈.

1.1. Notational Conventions 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This doc uses the Augmented BNF defined in [RFC5234] and updated by [RFC7405], along with the "#rule" extension defined in Section 7 of [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and [RFC7234]:

OWS           = <OWS, see [RFC7230], Section 3.2.3>
delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1>
port          = <port, see [RFC7230], Section 2.7>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token         = <token, see [RFC7230], Section 3.2.6>
uri-host      = <uri-host, see [RFC7230], Section 2.7>

2. Alternative Services Concepts 🌈

This spec defines a new HTTP concept, the "Alternative Service." When an origin [RFC6454] has resources that are reachable through a different protocol/host/port combination, it's said to have an alternative service available 🎀.

An alternative service can be used to interact with the resources on an origin server at a separate location on the network, possibly with a different protocol configuration. Alternative services are considered authoritative for an origin's resources, in the sense of [RFC7230], Section 9.1 👑.

For example, an origin:

("http", "www.example.com", "80")

might declare that its resources are also accessible at the alternative service:

("h2", "new.example.com", "81")

Alternative services are, by nature, explicitly at the granularity of an origin. You can't selectively apply them to resources within an origin 🙅‍♀️.

Alternative services don't replace or change the origin for any given resource. In general, they're not visible to the software "above" the access mechanism. An alternative service is basically alternative routing info that can also be used to reach the origin in the same way that DNS CNAME or SRV records define routing info at the name resolution level. Each origin maps to a set of these routes. The default route is derived from the origin itself, and the other routes get introduced based on alternative-service info 🧭.

Also, the first member of an alternative service tuple is different from the "scheme" component of an origin. It's more specific: it identifies not only the major version of the protocol being used, but potentially the communication options for that protocol as well 🔍.

So clients using an alternative service can change the host, port, and protocol they use to fetch resources. But these changes MUST NOT be propagated to the application that's using HTTP. From that standpoint, the URI being accessed and all info derived from it (scheme, host, and port) are the same as before 🫶.

This includes the security context, and that part is important. When TLS [RFC5246] is used to authenticate, the alternative service will need to present a certificate for the origin's host name, not the alternative's. Likewise, the Host header field ([RFC7230], Section 5.4) is still derived from the origin, not the alternative service, just like it would be if a CNAME were in use 🔐.

The changes MAY, however, be made visible in debugging tools, consoles, and so on 🛠️.

Formally, an alternative service is identified by the combination of:

  • An Application Layer Protocol Negotiation (ALPN) protocol name, as per [RFC7301]
  • A host, as per [RFC3986], Section 3.2.2
  • A port, as per [RFC3986], Section 3.2.3

The ALPN protocol name identifies the application protocol or suite of protocols used by the alternative service. For this spec, an ALPN protocol name implicitly includes TLS in the suite of protocols it identifies, unless its definition says otherwise. In particular, the ALPN name http/1.1, registered by Section 6 of [RFC7301], identifies HTTP/1.1 over TLS 💖.

Also, each alternative service MUST have a freshness lifetime, expressed in seconds (see Section 2.2) ⏰.

There are lots of ways a client could discover the alternative service(s) associated with an origin. This doc describes two: the "Alt-Svc" HTTP header field (Section 3) and the "ALTSVC" HTTP/2 frame type (Section 4) 🦋.

The rest of this section describes requirements that are common to alternative services, no matter how they're discovered ✨.

2.1. Host Authentication 🔐

Clients MUST have reasonable assurances that the alternative service is under the control of, and valid for, the whole origin. This mitigates the attack described in Section 9.2. It's giving security, and it's giving serious 😭.

For the purposes of this doc, "reasonable assurances" can be established through a TLS-based protocol with the certificate checks defined in [RFC2818]. Clients MAY impose additional criteria for establishing reasonable assurances 🎀.

For example, say the origin's host is "www.example.com" and an alternative is offered on "other.example.com" with the "h2" protocol. If the certificate offered is valid for "www.example.com", the client can use the alternative ✅. But if either one is offered with the "h2c" protocol, the client can't use it. The reason is that there's no mechanism in that protocol (at the time this spec was published) to establish the relationship between the origin and the alternative 🙅‍♀️💀.

2.2. Alternative Service Caching ✨

okay so alt services come with a freshness timer too 🕰️💖 the Alt-Svc header uses the "ma" parameter for that, and it's giving very organised vibes 🎀

clients can start using an alternative service instead of the origin whenever it's still fresh 💅 check Section 2.4 for the specific recs, bestie 🫶

clients who already have a connection to an alternative service don't have to drop it when the freshness timer runs out 🦋 the cache is only there to limit how long an alt service can be used for making NEW connections. it's not about cutting off the ones that already exist 🙈

alt services are fully authoritative for the origin 👑 so they can clear or update cached alt service entries, extend freshness lifetimes, and do anything else the origin server itself would be allowed to do. main character energy fr 💀

when alt services are sending a client to the most optimal server, a network config change can make the cached values suboptimal 😭 so clients SHOULD remove every cached alt service that doesn't have "persist" set to "1" once they detect that kind of change, as long as network state info is actually available 🌸

2.3. Requiring Server Name Indication 🎀

a client MUST NOT use a TLS-based alt service unless it supports TLS Server Name Indication (SNI) ✨ this helps conserve IP addresses on the alt service host 🧚

heads up 🚨 the SNI info the client sends in TLS will be the origin's, NOT the alternative's (same goes for the Host HTTP header field value) 💅

2.4. Using Alternative Services 🦋

okay so alt services are OPTIONAL 🌈 clients don't have to use them at all 🫶 but it's highkey helpful when clients act in a predictable way with alt services that servers use, because that helps with stuff like load balancing 🍓

so if a client supporting this spec finds out about an alt service, it SHOULD use that alt service for all requests to the associated origin as soon as it's available 💜 this only works if the alt service info is fresh (Section 2.2) AND the security properties of the alt service protocol are desirable compared to the existing connection ✨ once it's viable, the alt service gets treated in every way as the origin, including the ability to advertise alt services 👑

if a client becomes aware of multiple alt services, it picks the most suitable one by its own criteria, keeping security properties in mind 💅 for example, an origin might advertise several alt services to say it supports multiple HTTP versions 🌸

a client configured to use a proxy for a given request SHOULD NOT directly connect to an alt service for that request 🙈 it should route it through that proxy instead 🎀

when a client uses an alt service for a request, it can tell the server about it with the Alt-Used header field (Section 5) 🫶

the client doesn't need to block requests on an existing connection either 💖 it can keep using it until the alt connection is established 🦋 BUT if the existing connection is weak security-wise (like cleartext HTTP/1.1), it might make sense to block until the new connection is fully ready so info doesn't leak 😭🔥

and if the connection to the alt service fails or doesn't respond, the client MAY fall back to the origin or another alt service 💅 ngl though, this could be the basis of a downgrade attack 💀 which means losing any of the extra security the alt service gave 🚨 also, if the alt connection doesn't negotiate the expected protocol (like ALPN failing to negotiate h2, or an Upgrade request to h2c not being accepted), the connection MUST be considered failed 🫶

3. The Alt-Svc HTTP Header Field 🎀

okay this is the main event bestie 👑 an HTTP(S) origin server can tell clients about alt services by adding an Alt-Svc header field to responses ✨

Alt-Svc       = clear / 1#alt-value
clear         = %s"clear"; "clear", case-sensitive
alt-value     = alternative *( OWS ";" OWS parameter )
alternative   = protocol-id "=" alt-authority
protocol-id   = token ; percent-encoded ALPN protocol name
alt-authority = quoted-string ; containing [ uri-host ] ":" port
parameter     = token "=" ( token / quoted-string )

the field value is either a list of values (each one is a single alt service) or the keyword "clear" 🦋

if the value is "clear", that means the origin wants ALL alternatives for that origin invalidated 🙅‍♀️ (this includes any alt services in the same response too, just in case someone sends a messy reply with both "clear" and alt services 💀)

ALPN protocol names are octet sequences with no extra format rules 🌸 octets that aren't allowed in tokens ([RFC7230], Section 3.2.6) MUST be percent-encoded as per Section 2.1 of [RFC3986] 💖 and because of that, the percent character "%" (hex 25) MUST be percent-encoded too 🙈

to make sure there's exactly one way to write any ALPN protocol name, these extra rules apply 🎀

  1. octets in the ALPN protocol name MUST NOT be percent-encoded if they're valid token characters, except "%" 🧚
  2. when you do percent-encode, uppercase hex digits MUST be used 🔥

with these rules, recipients can just do simple string comparison to match protocol identifiers 💅✨

the "alt-authority" part is an OPTIONAL uri-host ("host" in Section 3.2.2 of [RFC3986]), then a colon (":"), then a port number 🌈

examples time 🎀

Alt-Svc: h2=":8000"

this means the "h2" protocol ([RFC7540]) on the same host, using port 8000 🫶

another one with a host change:

Alt-Svc: h2="new.example.org:80"

this says "h2" is on the host "new.example.org", running on port 80 🦋 quoted-string syntax is needed here because ":" isn't allowed in "token" 💅

protocol name escaping examples 💖

+--------------------+-------------+---------------------+
| ALPN protocol name | protocol-id | Note                |
+--------------------+-------------+---------------------+
| h2                 | h2          | No escaping needed  |
+--------------------+-------------+---------------------+
| w=x:y#z            | w%3Dx%3Ay#z | "=" and ":" escaped |
+--------------------+-------------+---------------------+
| x%y                | x%25y       | "%" needs escaping  |
+--------------------+-------------+---------------------+

Alt-Svc MAY show up in any HTTP response message, no matter the status code 🌸 recipients of Alt-Svc can ignore the header field (and in some situations they're REQUIRED to, see Sections 2.1 and 6) 🙈

the Alt-Svc field value can have multiple values 🎀

Alt-Svc: h2="alt.example.com:8000", h2=":443"

when there are multiple values, their order shows the server's preference, with the first one being the most preferred 👑

clients can use the advertised value(s) to open a NEW connection to an alt service 🦋 requests can start using that new connection right away, or keep using the existing connection while the new one gets made 💅

when using HTTP/2 ([RFC7540]), servers SHOULD send an ALTSVC frame instead (Section 4) ✨ one ALTSVC frame can be sent per connection, so you don't need a new frame for every request 🧚 but even with that recommendation, Alt-Svc header fields are still valid in responses delivered over HTTP/2 💖

each "alt-value" can be followed by an OPTIONAL semicolon-separated list of extra parameters, and each "parameter" has a name and a value 🌈

this spec defines two parameters, "ma" and "persist" (more in Section 3.1) 🎀 unknown parameters MUST be ignored 🙈 meaning the alt-value they're attached to MUST be processed as if that unknown parameter wasn't even there 💀

new parameters can be defined in extension specs (see Section 7.3 for registration details) 🫶

also, every field element that allows "quoted-string" syntax MUST be processed as per Section 3.2.6 of [RFC7230] 💅

3.1. Caching Alt-Svc Header Field Values 🕰️

when an alt service is advertised with Alt-Svc, it's considered fresh for 24 hours from when the message was generated 🌸 you can change that with the "ma" (max-age) parameter 💖

syntax 🎀

ma = delta-seconds; see [RFC7234], Section 1.2.1

the delta-seconds value is how many seconds since the response was generated that the alt service stays fresh 🦋

Alt-Svc: h2=":443"; ma=3600

see Section 4.2.3 of [RFC7234] for how to figure out the response age 🧚

example time 🫶 here's a response:

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=600
Age: 30
Alt-Svc: h2=":8000"; ma=60

this says an alt service is available and usable for the next 60 seconds ✨ BUT the response has already been cached for 30 seconds (per the Age header field value), so the alt service is only fresh for 30 seconds from when the response was received, minus estimated transit time 😭

note that the HTTP caching freshness lifetime (600 seconds here) does NOT affect caching of Alt-Svc values 💅

when an Alt-Svc response header field comes from an origin, its value invalidates and replaces ALL cached alt services for that origin 👑

by default, cached alt services get cleared when the client detects a network change 🌊 but alt services meant to live longer (like ones that aren't specific to the client's access network) can carry the "persist" parameter with the value "1" 🫶 that's a hint saying the service is potentially useful even after a network config change 💖

syntax 🎀

persist = "1"

example 🦋

Alt-Svc: h2=":443"; ma=2592000; persist=1

this spec only defines one value for "persist" ✨ clients MUST ignore "persist" parameters with values other than "1" 🙅‍♀️

see Section 2.2 for the general requirements on caching alt services 💅

4. The ALTSVC HTTP/2 Frame ✨

okay so the ALTSVC HTTP/2 frame ([RFC7540], Section 4) is how a server tells an HTTP/2 client "hey, there's an alternative service you can use" 🧚

it's a non-critical extension to HTTP/2 💅 so endpoints that don't support it just ignore it, per the extensibility rules in Section 4.1 of [RFC7540]. no drama, no crash 🫶

an ALTSVC frame sent from a server to a client on any stream other than stream 0 says the alternative service belongs to the origin of that stream 🦋

an ALTSVC frame on stream 0 is a bit different. the alternative service is tied to whatever origin is in the Origin field of the frame 🌸 and if the client doesn't see that origin as authoritative for the current connection, the association MUST be ignored. no exceptions, bestie 🙅‍♀️

the ALTSVC frame type is 0xa (decimal 10) 🔥

 +-------------------------------+-------------------------------+
 |         Origin-Len (16)       | Origin? (*)                 ...
 +-------------------------------+-------------------------------+
 |                   Alt-Svc-Field-Value (*)                   ...
 +---------------------------------------------------------------+

                        ALTSVC Frame Payload

here's what's inside the payload 👀

  • Origin-Len: an unsigned, 16-bit integer giving the length, in octets, of the Origin field.
  • Origin: an OPTIONAL sequence of characters holding the ASCII serialization of an origin ([RFC6454], Section 6.2) that the alternative service applies to.
  • Alt-Svc-Field-Value: a sequence of octets (its length is whatever is left after subtracting the length of all the preceding fields from the frame length). It holds a value identical to the Alt-Svc field value defined in Section 3 (ABNF production "Alt-Svc").

the ALTSVC frame doesn't define any flags 🤷‍♀️

this frame is meant for clients to receive 💖 a device acting as a server MUST ignore it.

an ALTSVC frame on stream 0 with empty (length 0) Origin information is invalid and MUST be ignored. an ALTSVC frame on any other stream that has non-empty Origin information is also invalid and MUST be ignored. two different rules, same energy: ignore it 🙈

the ALTSVC frame is processed hop-by-hop. an intermediary MUST NOT forward ALTSVC frames, but it can use the info inside them to build new ALTSVC frames for its own clients 🧠

receiving an ALTSVC frame is semantically equivalent to receiving an Alt-Svc header field ✨ so it causes the alternative services for that origin to get replaced. also, mixing Alt-Svc header fields with ALTSVC frames would be unwise, because the order they arrive in might be really hard to predict 💀

5. The Alt-Used HTTP Header Field 🦋

the Alt-Used header field goes in requests to say which alternative service is being used. it's basically the Host header field (Section 5.4 of [RFC7230]) but for the alternative service instead of the origin 🫶

Alt-Used     = uri-host [ ":" port ]

why does this matter? Alt-Used lets alternative services detect loops, split traffic for load balancing, and generally make sure you can tell where traffic is supposed to go. they added this after the protocol was already in use and that turned out to be a whole problem 😭

when a client is using an alternative service, it SHOULD include an Alt-Used header field in all requests 💅

for example:

GET /thing HTTP/1.1
Host: origin.example.com
Alt-Used: alternate.example.net

6. The 421 (Misdirected Request) HTTP Status Code 💅

the 421 (Misdirected Request) status code is defined in Section 9.1.2 of [RFC7540] and it means the current server instance isn't authoritative for the requested resource 🙅‍♀️ it can also be used to say that an alternative service isn't authoritative (see Section 2).

if a client gets a 421 (Misdirected Request) from an alternative service, it MUST remove the matching entry from its alternative service cache (see Section 2.2) for that origin. then, no matter whether the request method is idempotent, it MAY retry the request, either at another alternative server or at the origin 🔁

an Alt-Svc header field in a 421 (Misdirected Request) response MUST be ignored. don't even look at it, periodt 🚫

7. IANA Considerations 🎀

7.1. Header Field Registrations

HTTP header fields get registered in the "Message Headers" registry, which lives at <https://www.iana.org/assignments/message-headers/> 📋

this document defines the following HTTP header fields, so their registry entries were added with the permanent registrations below (see [BCP90]) 🌸

+-------------------+----------+----------+------------+
| Header Field Name | Protocol | Status   | Reference  |
+-------------------+----------+----------+------------+
| Alt-Svc           | http     | standard | Section 3  |
| Alt-Used          | http     | standard | Section 5  |
+-------------------+----------+----------+------------+

the change controller is: "IETF (iesg@ietf.org) -- Internet Engineering Task Force" 👑

7.2. The ALTSVC HTTP/2 Frame Type

this document registers the ALTSVC frame type in the "HTTP/2 Frame Type" registry ([RFC7540], Section 11.2) 🦋

   Frame Type: ALTSVC

   Code: 0xa

   Specification: Section 4 of this document

7.3. Alt-Svc Parameter Registry

the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" is where parameter names live 🗂️ it's been created and will be maintained at <http://www.iana.org/assignments/http-alt-svc-parameters>.

7.3.1. Procedure

a registration MUST include the following fields:

  • Parameter Name
  • Pointer to specification text

values added to this name space require Expert Review (see [RFC5226], Section 4.1) 🧐

7.3.2. Registrations

the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" has been filled in with these registrations ✨

+-------------------+--------------+
| Alt-Svc Parameter | Reference    |
+-------------------+--------------+
| ma                | Section 3.1  |
| persist           | Section 3.1  |
+-------------------+--------------+

8. Internationalization Considerations 🌈

an internationalized domain name that shows up in either the header field (Section 3) or the HTTP/2 frame (Section 4) MUST be written using A-labels ([RFC5890], Section 2.3.2.1) 🌍 no unicode names in there, bestie.

9. Security Considerations 💀

this section is serious, so I'm going to be serious too 😭

9.1. Changing Ports

using an alternative service means accessing an origin's resources on an alternative port, at the very least. so if an attacker can inject alternative services and listen on the advertised port, they can hijack the origin 🚨 on some servers, users are allowed to control personal pages on a shared port and also accept requests on less-privileged ports, which makes this worse.

for example, an attacker who can add HTTP response header fields to some pages can redirect traffic for a whole origin to a different port on the same host using the Alt-Svc header field. if that port is under the attacker's control, they can pretend to be the HTTP server 👻

this risk is mitigated by the requirements in Section 2.1 🛡️

on servers, the risk can also be reduced by limiting who can advertise alternative services and who can open a listening port on that host 🔒

9.2. Changing Hosts

when the host changes because of an alternative service, attackers get a chance to hijack communication to the origin 😱

for example, if an attacker can convince a user agent to send all traffic for "innocent.example.org" to "evil.example.com" by successfully associating it as an alternative service, they can masquerade as that origin. this can happen locally (see the mitigations in Section 9.1) or remotely, for instance through an intermediary doing a man-in-the-middle attack 🕵️‍♀️

this is why Section 2.1 requires clients to have reasonable assurances that the alternative service is under the control of, and valid for, the whole origin. for example, presenting a certificate for the origin proves that the alternative service is authorized to serve traffic for that origin 🎀

but note that this assurance is only as strong as the method used to authenticate the alternative service. in particular, when TLS authentication is used, there are well-known exploits that can make an attacker's certificate look legit 🫠

alternative services could also be used to keep such an attack going. for example, an intermediary could man-in-the-middle TLS-protected communication to a target and then send all traffic to an alternative service with a large freshness lifetime. that way the user agent keeps sending traffic to the attacker even when the intermediary isn't in the picture anymore 😈

implementations MUST perform any certificate-pinning validation (such as [RFC7469]) on alternative services just as they would on direct connections to the origin 📌 implementations might also choose to add other requirements around which certificates are acceptable for alternative services 💜

9.3. Changing Protocols

when the ALPN protocol changes because of an alternative service, the security properties of the new connection to the origin can be different from the "normal" connection, because the protocol identifier itself implies this 🤯

for example, if an "https://" URI has an advertised protocol that doesn't use some form of end-to-end encryption (most likely TLS), that breaks the security expectations the URI scheme implies 😬 so clients cannot use alternative services blindly. they have to evaluate the options presented to make sure the security requirements and expectations of specifications, implementations, and end users are met 🧐

9.4. Tracking Clients Using Alternative Services

choosing an alternative service means connecting to a new, server-supplied host name. by using unique names, servers could track client requests, and that tracking could follow users across multiple networks when the "persist" flag is used 👀

clients that want to stop their requests from being correlated can decide not to use alternative services for multiple requests that otherwise wouldn't be allowed to be correlated 🫥

in a user agent, any alternative service information MUST be removed when origin-specific data is cleared (typically, when cookies [RFC6265] are cleared) 🍪🧹

9.5. Confusion regarding Request Scheme 🙈

okay bestie, this one is a little spicy 🌶️ some server-side HTTP apps make security assumptions based on the connection they're sitting on. like, if something's being served on port 443, they just assume it's an "https://" URI and all the security goodies that come with it 🔐

this doesn't only mess with the security of the connection itself. it also changes what the client on the other end does 👀 a web browser treats "https://" URIs differently from "http://" URIs in lots of ways, not just for protocol handling 💅

now here's the tea. one of the whole points of Alternative Services is letting a connection move to a different protocol and port, and that's where things get messy 😭 the app can get confused about how secure the connection actually is, and then it sends stuff (like cookies and content) meant for a secure context, like an "https://" URI, to a client that isn't treating it as one. yikes 💀

servers can dodge this by using the URI scheme the protocol explicitly carries as their signal for security context, instead of other connection properties. that means :scheme in HTTP/2 or the "absolute form" of the request target in HTTP/1.1 ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). ✨

when the protocol doesn't explicitly carry the scheme (which is usually the case for HTTP/1.1 over TLS), servers can mitigate the risk in one of two ways. they can either assume that every request has an insecure context, or they can skip advertising alternative services for insecure schemes (like HTTP). 🫶

10. References 📚

10.1. Normative References 💜

10.2. Informative References 🌸

Acknowledgements 🫶

huge thanks to Adam Langley, Bence Beky, Chris Lonvick, Eliot Lear, Erik Nygren, Guy Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury, Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and suggestions. you're all iconic 👑

the Alt-Svc header field was influenced by the design of the Alternate-Protocol header field in SPDY. ✨

Authors' Addresses 💌

Mark Nottingham
Akamai

Email: mnot@mnot.net
URI:   https://www.mnot.net/


Patrick McManus
Mozilla

Email: mcmanus@ducksong.com
URI:   https://mozillians.org/u/pmcmanus/


Julian F. Reschke
greenbytes GmbH

Email: julian.reschke@greenbytes.de
URI:   https://greenbytes.de/tech/webdav/
📦 where this page comes from