2. Concetti di servizi alternativi

Questa specifica definisce un nuovo concetto in HTTP, il "Servizio Alternativo" (Alternative Service). Quando un'origine [RFC6454] ha risorse accessibili attraverso una diversa combinazione protocollo/host/porta, si dice che ha un servizio alternativo disponibile.

Un servizio alternativo può essere utilizzato per interagire con le risorse su un server di origine in una posizione separata sulla rete, possibilmente utilizzando una diversa configurazione del protocollo. I servizi alternativi sono considerati autorevoli per le risorse di un'origine, nel senso della [RFC7230], Sezione 9.1.

Ad esempio, un'origine:

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

potrebbe dichiarare che le sue risorse sono accessibili anche presso il servizio alternativo:

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

Per loro natura, i servizi alternativi sono esplicitamente alla granularità di un'origine; non possono essere applicati selettivamente alle risorse all'interno di un'origine.

I servizi alternativi non sostituiscono né modificano l'origine per una data risorsa; in generale, non sono visibili al software "al di sopra" del meccanismo di accesso. Il servizio alternativo è essenzialmente un'informazione di routing alternativa che può anche essere utilizzata per raggiungere l'origine nello stesso modo in cui i record DNS CNAME o SRV definiscono le informazioni di routing a livello di risoluzione dei nomi. Ogni origine mappa a un insieme di questi percorsi -- il percorso predefinito deriva dall'origine stessa e gli altri percorsi sono introdotti in base alle informazioni sui servizi alternativi.

Inoltre, è importante notare che il primo membro di una tupla di servizio alternativo è diverso dal componente "schema" di un'origine; è più specifico, identificando non solo la versione principale del protocollo utilizzato, ma potenzialmente anche le opzioni di comunicazione per quel protocollo.

Ciò significa che i client che utilizzano un servizio alternativo possono modificare l'host, la porta e il protocollo che utilizzano per recuperare le risorse, ma queste modifiche NON DEVONO essere propagate all'applicazione che utilizza HTTP; da questo punto di vista, l'URI a cui si accede e tutte le informazioni derivate da esso (schema, host e porta) sono le stesse di prima.

È importante notare che ciò include il suo contesto di sicurezza; in particolare, quando viene utilizzato TLS [RFC5246] per l'autenticazione, il servizio alternativo dovrà presentare un certificato per il nome host dell'origine, non per quello del servizio alternativo. Allo stesso modo, il campo di intestazione Host ([RFC7230], Sezione 5.4) deriva ancora dall'origine, non dal servizio alternativo (proprio come avverrebbe se fosse utilizzato un CNAME).

Le modifiche POSSONO, tuttavia, essere rese visibili in strumenti di debug, console, ecc.

Formalmente, un servizio alternativo è identificato dalla combinazione di:

• Un nome di protocollo ALPN (Application Layer Protocol Negotiation), come da [RFC7301]
• Un host, come da [RFC3986], Sezione 3.2.2
• Una porta, come da [RFC3986], Sezione 3.2.3

Il nome del protocollo ALPN viene utilizzato per identificare il protocollo applicativo o la suite di protocolli utilizzati dal servizio alternativo. Si noti che ai fini di questa specifica, un nome di protocollo ALPN include implicitamente TLS nella suite di protocolli che identifica, a meno che non sia specificato diversamente nella sua definizione. In particolare, il nome ALPN "http/1.1", registrato dalla Sezione 6 della [RFC7301], identifica HTTP/1.1 su TLS.

Inoltre, ogni servizio alternativo DEVE avere una durata di freschezza, espressa in secondi (vedi Sezione 2.2).

Ci sono molti modi in cui un client potrebbe scoprire il/i servizio/i alternativo/i associato/i a un'origine. Questo documento descrive due di questi meccanismi: il campo di intestazione HTTP "Alt-Svc" (Sezione 3) e il tipo di frame HTTP/2 "ALTSVC" (Sezione 4).

Il resto di questa sezione descrive i requisiti comuni ai servizi alternativi, indipendentemente da come vengono scoperti.

2.1. Autenticazione dell'host

I client DEVONO avere ragionevoli garanzie che il servizio alternativo sia sotto il controllo di e valido per l'intera origine. Ciò mitiga l'attacco descritto nella Sezione 9.2.

Ai fini di questo documento, "ragionevoli garanzie" possono essere stabilite utilizzando un protocollo basato su TLS con i controlli dei certificati definiti nella [RFC2818]. I client POSSONO imporre criteri aggiuntivi per stabilire ragionevoli garanzie.

Ad esempio, se l'host dell'origine è "www.example.com" e un'alternativa è offerta su "other.example.com" con il protocollo "h2", e il certificato offerto è valido per "www.example.com", il client può utilizzare l'alternativa. Tuttavia, se uno dei due viene offerto con il protocollo "h2c", il client non può utilizzarlo, perché non esiste un meccanismo (al momento della pubblicazione di questa specifica) in quel protocollo per stabilire la relazione tra l'origine e l'alternativa.

2.2. Caching dei servizi alternativi

I meccanismi per scoprire i servizi alternativi associano ad essi anche una durata di freschezza; ad esempio, il campo di intestazione Alt-Svc utilizza il parametro "ma".

I client possono scegliere di utilizzare un servizio alternativo invece dell'origine in qualsiasi momento quando è considerato fresco; vedi Sezione 2.4 per raccomandazioni specifiche.

I client con connessioni esistenti a un servizio alternativo non hanno bisogno di smettere di usarlo quando scade la sua durata di freschezza; il meccanismo di caching ha lo scopo di limitare la durata per la quale un servizio alternativo può essere utilizzato per stabilire nuove connessioni, non di limitare l'uso delle connessioni esistenti.

I servizi alternativi sono completamente autorevoli per l'origine in questione, inclusa la capacità di cancellare o aggiornare le voci di servizi alternativi memorizzate nella cache, estendere le durate di freschezza e qualsiasi altra autorità che il server di origine avrebbe.

Quando vengono utilizzati servizi alternativi per inviare un client al server più ottimale, un cambiamento nella configurazione di rete potrebbe rendere i valori memorizzati nella cache non ottimali. Pertanto, i client DOVREBBERO rimuovere dalla cache tutti i servizi alternativi che non hanno il flag "persist" con valore "1" quando rilevano un tale cambiamento, quando sono disponibili informazioni sullo stato della rete.

2.3. Richiesta di Server Name Indication

Un client NON DEVE utilizzare un servizio alternativo basato su TLS a meno che il client non supporti TLS Server Name Indication (SNI). Ciò supporta la conservazione degli indirizzi IP sull'host del servizio alternativo.

Si noti che le informazioni SNI fornite nel TLS dal client saranno quelle dell'origine, non dell'alternativa (proprio come il valore del campo di intestazione HTTP Host).

2.4. Utilizzo dei servizi alternativi

Per loro natura, i servizi alternativi sono OPZIONALI: i client non sono tenuti a utilizzarli. Tuttavia, è vantaggioso che i client si comportino in modo prevedibile quando vengono utilizzati servizi alternativi dai server, per favorire scopi come il bilanciamento del carico.

Pertanto, se un client che supporta questa specifica viene a conoscenza di un servizio alternativo, il client DOVREBBE utilizzare quel servizio alternativo per tutte le richieste all'origine associata non appena è disponibile, a condizione che le informazioni sul servizio alternativo siano fresche (Sezione 2.2) e che le proprietà di sicurezza del protocollo del servizio alternativo siano desiderabili, rispetto alla connessione esistente. Un servizio alternativo praticabile viene quindi trattato come l'origine in ogni aspetto; ciò include la capacità di pubblicizzare servizi alternativi.

Se un client viene a conoscenza di più servizi alternativi, sceglie il più adatto secondo i propri criteri, tenendo presenti le proprietà di sicurezza. Ad esempio, un'origine potrebbe pubblicizzare più servizi alternativi per notificare ai client il supporto per più versioni di HTTP.

Un client configurato per utilizzare un proxy per una determinata richiesta NON DOVREBBE connettersi direttamente a un servizio alternativo per questa richiesta, ma instradarla invece attraverso quel proxy.

Quando un client utilizza un servizio alternativo per una richiesta, può indicarlo al server utilizzando il campo di intestazione Alt-Used (Sezione 5).

Il client non ha bisogno di bloccare le richieste su una connessione esistente; può essere utilizzata fino a quando la connessione alternativa non viene stabilita. Tuttavia, se le proprietà di sicurezza della connessione esistente sono deboli (ad esempio, HTTP/1.1 in chiaro), potrebbe avere senso bloccare fino a quando la nuova connessione non è completamente disponibile per evitare la fuga di informazioni.

Inoltre, se la connessione al servizio alternativo fallisce o non risponde, il client PUÒ ripiegare sull'utilizzo dell'origine o di un altro servizio alternativo. Si noti, tuttavia, che questa potrebbe essere la base di un attacco di downgrade, perdendo così qualsiasi proprietà di sicurezza avanzata del servizio alternativo. Se la connessione al servizio alternativo non negozia il protocollo previsto (ad esempio, ALPN non riesce a negoziare h2 o una richiesta di aggiornamento a h2c non viene accettata), la connessione al servizio alternativo DEVE essere considerata fallita.