4. Identificatori in HTTP

Gli Uniform Resource Identifiers (URI) [URI] sono utilizzati in tutto HTTP come mezzo per identificare le risorse (Sezione 3.1).

4.1. Riferimenti URI

I riferimenti URI sono utilizzati per indirizzare le richieste, indicare reindirizzamenti e definire relazioni.

Le definizioni di "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", "path-abempty", "segment" e "query" sono adottate dalla sintassi generica URI. Una regola "absolute-path" è definita per gli elementi di protocollo che possono contenere un componente di percorso non vuoto. (Questa regola differisce leggermente dalla regola path-abempty di RFC 3986, che consente un percorso vuoto, e dalla regola path-absolute, che non consente percorsi che iniziano con "//".) Una regola "partial-URI" è definita per gli elementi di protocollo che possono contenere un URI relativo ma non un componente di frammento.

URI-reference = <URI-reference, see [URI], Section 4.1>
absolute-URI  = <absolute-URI, see [URI], Section 4.3>
relative-part = <relative-part, see [URI], Section 4.2>
authority     = <authority, see [URI], Section 3.2>
uri-host      = <host, see [URI], Section 3.2.2>
port          = <port, see [URI], Section 3.2.3>
path-abempty  = <path-abempty, see [URI], Section 3.3>
segment       = <segment, see [URI], Section 3.3>
query         = <query, see [URI], Section 3.4>

absolute-path = 1*( "/" segment )
partial-URI   = relative-part [ "?" query ]

Ogni elemento di protocollo in HTTP che consente un riferimento URI indicherà nella sua produzione ABNF se l'elemento consente qualsiasi forma di riferimento (URI-reference), solo un URI in forma assoluta (absolute-URI), solo i componenti di percorso e query opzionali (partial-URI), o una combinazione di quanto sopra. Salvo diversa indicazione, i riferimenti URI sono analizzati relativamente all'URI di destinazione (Sezione 7.1).

È RACCOMANDATO (RECOMMENDED) che tutti i mittenti e destinatari supportino, come minimo, URI con lunghezze di 8000 ottetti negli elementi di protocollo. Si noti che ciò implica che alcune strutture e rappresentazioni su filo (ad esempio, la riga di richiesta in HTTP/1.1) saranno necessariamente più grandi in alcuni casi.

4.2. Schemi URI correlati a HTTP

IANA mantiene il registro degli Schemi URI [BCP35] su https://www.iana.org/assignments/uri-schemes/. Sebbene le richieste possano indirizzarsi a qualsiasi schema URI, i seguenti schemi sono inerenti ai server HTTP:

Schema URI	Descrizione	Sezione
http	Hypertext Transfer Protocol	4.2.1
https	Hypertext Transfer Protocol Secure	4.2.2

Tabella 2

Si noti che la presenza di un URI "http" o "https" non implica che ci sia sempre un server HTTP all'origine identificata in ascolto per connessioni. Chiunque può creare un URI, indipendentemente dal fatto che un server esista e se quel server attualmente mappa quell'identificatore a una risorsa. La natura delegata dei nomi registrati e degli indirizzi IP crea uno spazio dei nomi federato indipendentemente dalla presenza o meno di un server HTTP.

4.2.1. Schema URI http

Lo schema URI "http" è qui definito per creare identificatori all'interno dello spazio dei nomi gerarchico governato da un potenziale server di origine HTTP in ascolto per connessioni TCP ([TCP]) su una porta specificata.

http-URI = "http" "://" authority path-abempty [ "?" query ]

Il server di origine per un URI "http" è identificato dal componente authority, che include un identificatore host ([URI], Sezione 3.2.2) e un numero di porta opzionale ([URI], Sezione 3.2.3). Se il sottocomponente porta è vuoto o non fornito, la porta TCP 80 (la porta riservata per i servizi WWW) è la porta predefinita. L'origine determina chi ha il diritto di rispondere in modo autorevole alle richieste che mirano alla risorsa identificata, come definito nella Sezione 4.3.2.

Un mittente NON DEVE (MUST NOT) generare un URI "http" con un identificatore host vuoto. Un destinatario che elabora un tale riferimento URI DEVE rifiutarlo come non valido.

Il componente di percorso gerarchico e il componente di query opzionale identificano la risorsa di destinazione all'interno dello spazio dei nomi di quel server di origine.

4.2.2. Schema URI https

Lo schema URI "https" è qui definito per creare identificatori all'interno dello spazio dei nomi gerarchico governato da un potenziale server di origine in ascolto per connessioni TCP su una porta specificata e capace di stabilire una connessione TLS ([TLS13]) che è stata protetta per la comunicazione HTTP. In questo contesto, "protetto" (secured) significa specificamente che il server è stato autenticato come agente per conto dell'autorità identificata e che tutta la comunicazione HTTP con quel server ha protezione di riservatezza e integrità accettabile sia per il client che per il server.

https-URI = "https" "://" authority path-abempty [ "?" query ]

Il server di origine per un URI "https" è identificato dal componente authority, che include un identificatore host ([URI], Sezione 3.2.2) e un numero di porta opzionale ([URI], Sezione 3.2.3). Se il sottocomponente porta è vuoto o non fornito, la porta TCP 443 (la porta riservata per HTTP su TLS) è la porta predefinita. L'origine determina chi ha il diritto di rispondere in modo autorevole alle richieste che mirano alla risorsa identificata, come definito nella Sezione 4.3.3.

Un mittente NON DEVE (MUST NOT) generare un URI "https" con un identificatore host vuoto. Un destinatario che elabora un tale riferimento URI DEVE rifiutarlo come non valido.

Il componente di percorso gerarchico e il componente di query opzionale identificano la risorsa di destinazione all'interno dello spazio dei nomi di quel server di origine.

Un client DEVE assicurarsi che le sue richieste HTTP per una risorsa "https" siano protette, prima di essere comunicate, e che accetti solo risposte protette a tali richieste. Si noti che la definizione di quali meccanismi crittografici sono accettabili per client e server è solitamente negoziata e può cambiare nel tempo.

Le risorse rese disponibili tramite lo schema "https" non hanno identità condivisa con lo schema "http". Sono origini distinte con spazi dei nomi separati. Tuttavia, le estensioni di HTTP definite come applicabili a tutte le origini con lo stesso host, come il protocollo Cookie [COOKIE], consentono alle informazioni impostate da un servizio di influire sulla comunicazione con altri servizi all'interno di un gruppo corrispondente di domini host. Tali estensioni dovrebbero essere progettate con grande cura per prevenire che le informazioni ottenute da una connessione protetta vengano inavvertitamente scambiate in un contesto non protetto.

4.2.3. Normalizzazione e confronto http(s)

Gli URI con uno schema "http" o "https" sono normalizzati e confrontati secondo i metodi definiti nella Sezione 6 di [URI], utilizzando i valori predefiniti descritti sopra per ciascuno schema.

HTTP non richiede l'uso di un metodo specifico per determinare l'equivalenza. Ad esempio, una chiave di cache potrebbe essere confrontata come una semplice stringa, dopo la normalizzazione basata sulla sintassi o dopo la normalizzazione basata sullo schema.

La normalizzazione basata sullo schema (Sezione 6.2.3 di [URI]) degli URI "http" e "https" coinvolge le seguenti regole aggiuntive:

• Se la porta è uguale alla porta predefinita per uno schema, la forma normale è omettere il sottocomponente porta.

• Quando non viene utilizzato come destinazione di una richiesta OPTIONS, un componente di percorso vuoto è equivalente a un percorso assoluto di "/", quindi la forma normale è fornire un percorso di "/" invece.

• Lo schema e l'host non sono case-sensitive e normalmente forniti in minuscolo; tutti gli altri componenti sono confrontati in modo case-sensitive.

• I caratteri diversi da quelli nel set "reserved" sono equivalenti ai loro ottetti codificati in percentuale: la forma normale è non codificarli (vedere Sezioni 2.1 e 2.2 di [URI]).

Ad esempio, i seguenti tre URI sono equivalenti:

http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html

Due URI HTTP che sono equivalenti dopo la normalizzazione (utilizzando qualsiasi metodo) possono essere assunti per identificare la stessa risorsa, e qualsiasi componente HTTP PUÒ (MAY) eseguire la normalizzazione. Di conseguenza, risorse distinte NON DOVREBBERO (SHOULD NOT) essere identificate da URI HTTP che sono equivalenti dopo la normalizzazione (utilizzando qualsiasi metodo definito nella Sezione 6.2 di [URI]).

4.2.4. Deprecazione di userinfo negli URI http(s)

La sintassi generica URI per l'autorità include anche un sottocomponente userinfo ([URI], Sezione 3.2.1) per includere informazioni di autenticazione utente nell'URI. In quel sottocomponente, l'uso del formato "user:password" è deprecato.

Alcune implementazioni utilizzano il componente userinfo per la configurazione interna delle informazioni di autenticazione, come nelle opzioni di invocazione dei comandi, nei file di configurazione o negli elenchi di segnalibri, anche se tale utilizzo potrebbe esporre un identificatore utente o una password.

Un mittente NON DEVE (MUST NOT) generare il sottocomponente userinfo (e il suo delimitatore "@") quando un riferimento URI "http" o "https" viene generato all'interno di un messaggio come URI di destinazione o valore di campo.

Prima di utilizzare un riferimento URI "http" o "https" ricevuto da una fonte non attendibile, un destinatario DOVREBBE (SHOULD) analizzare userinfo e trattare la sua presenza come un errore; probabilmente viene utilizzato per oscurare l'autorità allo scopo di attacchi di phishing.

4.2.5. Riferimenti http(s) con identificatori di frammento

Gli identificatori di frammento consentono l'identificazione indiretta di una risorsa secondaria, indipendentemente dallo schema URI, come definito nella Sezione 3.5 di [URI]. Alcuni elementi di protocollo che fanno riferimento a un URI consentono l'inclusione di un frammento, mentre altri no. Sono distinti dall'uso della regola ABNF per elementi in cui il frammento è consentito; altrimenti, viene utilizzata una regola specifica che esclude i frammenti.

Nota: Il componente identificatore di frammento non fa parte della definizione dello schema per uno schema URI (vedere Sezione 4.3 di [URI]), quindi non appare nelle definizioni ABNF per gli schemi URI "http" e "https" sopra.

4.3. Accesso autorevole

L'accesso autorevole si riferisce alla dereferenziazione di un identificatore dato, allo scopo di accedere alla risorsa identificata, in un modo che il client ritiene autorevole (controllato dal proprietario della risorsa). Il processo per determinare se l'accesso è concesso è definito dallo schema URI e spesso utilizza dati all'interno dei componenti URI, come il componente authority quando viene utilizzata la sintassi generica. Tuttavia, l'accesso autorevole non è limitato al meccanismo identificato.

La Sezione 4.3.1 definisce il concetto di origine come aiuto per tali usi, e le sottosezioni successive spiegano come stabilire che un peer ha l'autorità di rappresentare un'origine.

Vedere la Sezione 17.1 per considerazioni sulla sicurezza relative alla stabilizione dell'autorità.

4.3.1. Origine URI

L'"origine" (origin) per un URI dato è la tripla di schema, host e porta dopo la normalizzazione dello schema e dell'host in minuscolo e la normalizzazione della porta per rimuovere eventuali zeri iniziali. Se la porta è elisa dall'URI, viene utilizzata la porta predefinita per quello schema. Ad esempio, l'URI

https://Example.Com/happy.js

avrebbe l'origine

{ "https", "example.com", "443" }

che può anche essere descritto come il prefisso URI normalizzato con porta sempre presente:

https://example.com:443

Ogni origine definisce il proprio spazio dei nomi e controlla come gli identificatori all'interno di quello spazio dei nomi sono mappati alle risorse. A sua volta, il modo in cui l'origine risponde alle richieste valide, coerentemente nel tempo, determina la semantica che gli utenti assoceranno a un URI, e l'utilità di quella semantica è ciò che alla fine trasforma questi meccanismi in una risorsa a cui gli utenti faranno riferimento e accederanno in futuro.

Due origini sono distinte se differiscono nello schema, nell'host o nella porta. Anche quando può essere verificato che la stessa entità controlla due origini distinte, i due spazi dei nomi sotto quelle origini sono distinti a meno che non siano esplicitamente aliasati da un server autorevole per quell'origine.

L'origine è anche utilizzata all'interno di HTML e protocolli Web correlati, oltre lo scopo di questo documento, come descritto in [RFC6454].

4.3.2. Origini http

Sebbene HTTP sia indipendente dal protocollo di trasporto, lo schema "http" (Sezione 4.2.1) è specifico per l'associazione dell'autorità con chiunque controlli il server di origine in ascolto per connessioni TCP sulla porta indicata di qualsiasi host sia identificato all'interno del componente authority. Questo è un senso molto debole di autorità perché dipende sia dai meccanismi di risoluzione dei nomi specifici del client che dalla comunicazione che potrebbe non essere protetta da un attaccante sul percorso. Tuttavia, è un minimo sufficiente per legare gli identificatori "http" a un server di origine per una risoluzione coerente all'interno di un ambiente affidabile.

Se l'identificatore host è fornito come indirizzo IP, il server di origine è il listener (se presente) sulla porta TCP indicata a quell'indirizzo IP. Se l'host è un nome registrato, il nome registrato è un identificatore indiretto da utilizzare con un servizio di risoluzione dei nomi, come DNS, per trovare un indirizzo per un server di origine appropriato.

Quando un URI "http" viene utilizzato in un contesto che richiede l'accesso alla risorsa indicata, un client PUÒ (MAY) tentare l'accesso risolvendo l'identificatore host in un indirizzo IP, stabilendo una connessione TCP a quell'indirizzo sulla porta indicata e inviando su quella connessione un messaggio di richiesta HTTP contenente un target di richiesta che corrisponde all'URI target del client (Sezione 7.1).

Se il server risponde a tale richiesta con un messaggio di risposta HTTP non provvisorio, come descritto nella Sezione 15, allora quella risposta è considerata una risposta autorevole alla richiesta del client.

Si noti, tuttavia, che quanto sopra non è l'unico mezzo per ottenere una risposta autorevole, né implica che una risposta autorevole sia sempre necessaria (vedere [CACHING]). Ad esempio, il campo di intestazione Alt-Svc [ALTSVC] consente a un server di origine di identificare altri servizi che sono anche autorevoli per quell'origine. L'accesso alle risorse identificate "http" potrebbe anche essere fornito da protocolli al di fuori dello scopo di questo documento.

4.3.3. Origini https

Lo schema "https" (Sezione 4.2.2) associa l'autorità in base alla capacità di un server di utilizzare una chiave privata che corrisponde a un certificato che il client considera affidabile per il server di origine identificato. Un client tipicamente si affiderà a una catena di fiducia, trasmessa da qualche ancora di fiducia prearrangiata o configurata, al fine di considerare un certificato affidabile (Sezione 4.3.4).

In HTTP/1.1 e versioni precedenti, un client attribuirebbe autorità a un server solo quando comunica su una connessione stabilita e protetta con successo che è specificamente realizzata con l'host dell'origine dell'URI. L'instaurazione della connessione e la verifica del certificato erano utilizzate come prova di autorità.

In HTTP/2 e HTTP/3, un client attribuirà autorità a un server quando comunica su una connessione stabilita e protetta con successo se l'host dell'origine dell'URI corrisponde a uno qualsiasi degli host presenti nel certificato del server e il client ritiene di poter aprire una connessione a quell'host per quell'URI. In effetti, il client eseguirà una query DNS per verificare che l'host dell'origine contenga lo stesso indirizzo IP del server della connessione che è stata stabilita. Un server di origine può rimuovere questa restrizione inviando un frame ORIGIN equivalente [RFC8336].

I valori host e porta del target della richiesta sono trasmessi su ogni richiesta HTTP, identificando l'origine e distinguendola da altri spazi dei nomi che potrebbero essere controllati dallo stesso server (Sezione 7.2). È responsabilità dell'origine assicurarsi che qualsiasi servizio fornito con il controllo sulla chiave privata del suo certificato sia ugualmente responsabile della gestione dello spazio dei nomi "https" corrispondente o almeno preparato a rifiutare richieste che sembrano mal indirizzate (Sezione 7.4).

Un server di origine potrebbe non essere disposto a elaborare richieste per determinati URI target anche quando è autorevole per essi. Ad esempio, quando un host esegue servizi distinti su porte diverse (ad es., 443 contro 8000), il controllo dell'URI target sul server di origine è necessario (anche dopo che la connessione è stata protetta) perché un attaccante di rete potrebbe far sì che le connessioni per una porta vengano ricevute su un'altra porta. Il mancato controllo dell'URI target potrebbe consentire a tale attaccante di sostituire la risposta a un URI target (ad es., "https://example.com/foo") con una risposta apparentemente autorevole da un'altra porta (ad es., "https://example.com:8000/foo").

Si noti che lo schema "https" non si basa su TCP e sul numero di porta connesso per associare l'autorità, poiché entrambi sono al di fuori della comunicazione protetta e quindi non possono essere considerati attendibili come definitivi. Pertanto, la comunicazione HTTP può avvenire su qualsiasi canale protetto, come definito nella Sezione 4.2.2, inclusi protocolli che non utilizzano TCP.

Quando un URI "https" viene utilizzato in un contesto che richiede l'accesso alla risorsa indicata, un client PUÒ (MAY) tentare l'accesso risolvendo l'identificatore host in un indirizzo IP, stabilendo una connessione TCP a quell'indirizzo sulla porta indicata, proteggendo la connessione end-to-end avviando con successo TLS su TCP con protezione di riservatezza e integrità, e inviando su quella connessione un messaggio di richiesta HTTP contenente un target di richiesta che corrisponde all'URI target del client (Sezione 7.1).

Se il server risponde a tale richiesta con un messaggio di risposta HTTP non provvisorio, come descritto nella Sezione 15, allora quella risposta è considerata una risposta autorevole alla richiesta del client.

Si noti, tuttavia, che quanto sopra non è l'unico mezzo per ottenere una risposta autorevole, né implica che una risposta autorevole sia sempre necessaria (vedere [CACHING]).

4.3.4. Verifica del certificato https

Per stabilire una connessione protetta per dereferenziare un URI, un client DEVE verificare che l'identità del servizio sia una corrispondenza accettabile per il server di origine dell'URI. La verifica del certificato è utilizzata per prevenire l'impersonificazione del server da parte di un attaccante sul percorso o da un attaccante che controlla la risoluzione dei nomi. Questo processo richiede che il client sia configurato con un set di ancore di fiducia.

Tipicamente, un client DEVE utilizzare il processo di validazione definito nella Sezione 6 di [RFC6125] per verificare l'identità del servizio. Il client DEVE costruire un'identità di riferimento dall'host del servizio: se l'host è un indirizzo IP letterale (Sezione 4.3.5), allora l'identità di riferimento è un IP-ID, altrimenti l'host è un nome e l'identità di riferimento è un DNS-ID.

Un client NON DEVE (MUST NOT) utilizzare un'identità di riferimento di tipo CN-ID. Come notato nella Sezione 6.2.1 di [RFC6125], un'identità di riferimento di tipo CN-ID potrebbe essere utilizzata da client più vecchi.

Un client potrebbe essere configurato specificamente per accettare forme alternative di verifica dell'identità del server. Ad esempio, un client potrebbe connettersi a un server il cui indirizzo e nome host sono dinamici, aspettandosi che il servizio presenti un certificato specifico (o uno che corrisponda a un'identità di riferimento definita esternamente), piuttosto che uno che corrisponda all'origine dell'URI target.

In casi speciali, potrebbe essere appropriato per un client ignorare semplicemente l'identità del server, ma deve essere compreso che questo lascia una connessione aperta ad attacchi attivi.

Se il certificato non è valido per l'origine dell'URI target, un user agent DEVE ottenere conferma dall'utente (vedere Sezione 3.5) prima di continuare o terminare la connessione con un errore di certificato errato. I client automatizzati DEVONO registrare l'errore in un log di audit appropriato, se disponibile, e DOVREBBERO (SHOULD) terminare la connessione con un errore di certificato errato. I client automatizzati POSSONO (MAY) fornire un'impostazione di configurazione che disabilita questo controllo ma DEVONO fornire un'impostazione che lo abilita.

4.3.5. Identità di riferimento IP-ID

Un server identificato da un letterale di indirizzo IP nel campo "host" di un URI "https" ha un'identità di riferimento di tipo IP-ID. Un indirizzo IP versione 4 utilizza la regola ABNF "IPv4address", e un indirizzo IP versione 6 utilizza la produzione "IP-literal" con l'opzione "IPv6address"; vedere Sezione 3.2.2 di [URI]. L'identità di riferimento per un IP-ID contiene i byte decodificati dell'indirizzo IP.

Un indirizzo IP versione 4 è di 4 ottetti, e un indirizzo IP versione 6 è di 16 ottetti. L'uso di un IP-ID non è definito per nessun'altra versione IP. Una scelta iPAddress nell'estensione subjectAltName di un certificato non include esplicitamente una versione IP, basandosi invece sulla lunghezza dell'indirizzo per distinguere le versioni; vedere Sezione 4.2.1.6 di [RFC5280].

Un'identità di riferimento di tipo IP-ID corrisponde se l'indirizzo è identico a un valore iPAddress dell'estensione subjectAltName del certificato.