Stringhe urlPrefix

Nell'API server HTTP un UrlPrefix è una stringa Unicode wide (UTF-16) con un formato canonico che specifica una sezione dello spazio dei nomi URL. Viene usato per riservare una sezione dello spazio dei nomi URL per un account utente o registrare una sezione dello spazio dei nomi URL per un processo.

Formato urlPrefix

Un urlPrefix ha la sintassi seguente:

"scheme://host:port/relativeURI"

Lo schema, l'host e gli elementi di porta di un UrlPrefix devono essere presenti e non vuoti e devono rispettare le regole seguenti:

schema

Deve essere http o https, tutto in minuscolo.

host

Deve essere un nome di dominio completo, una stringa letterale IPv4 o IPv6 o un carattere jolly. A differenza dello schema, che deve essere minuscolo, la parte host non fa distinzione tra maiuscole e minuscole. A seconda della modalità di specifica della parte host, un UrlPrefix rientra in una delle quattro categorie di routing seguenti, descritte più in dettaglio di seguito:

Carattere jolly sicuro

Esplicito

Carattere jolly debole associato a IP

Carattere jolly debole

porta

Stringa numerica decimale che non inizia con zero e che rappresenta un numero di porta TCP valido (da 1 a 65.535). Questo valore non può essere un carattere jolly.

relativeURI

L'elemento relativeURI è facoltativo, ma se presente deve essere sempre seguito da un carattere barra ("/"). Si tratta di una stringa di prefisso che indica un sottoalbero all'interno dello spazio dei nomi del computer specificato rispetto allo schema, ai valori di host e porta. A differenza dello schema, che deve essere minuscolo, la parte relativeURI non fa distinzione tra maiuscole e minuscole.

Esempi di URLPrefixes correttamente formati sono:

• https://www.adatum.com:80/vroot/
• https://adatum.com:443/secure/database/
• https://+:80/vroot/

categorie di Host-Specifier

Per flessibilità e facilità d'uso, l'API server HTTP supporta quattro modi diversi per specificare gli host. Le quattro categorie di identificatori host sono elencate di seguito in ordine di precedenza:

carattere jolly sicuro (segno più)

Quando l'elemento host di un UrlPrefix è costituito da un singolo segno più (+), UrlPrefix corrisponde a tutti i nomi host possibili nel contesto dello schema, della porta e degli elementi relativeURI e rientra nella categoria con caratteri jolly sicuri.

Un carattere jolly sicuro è utile quando un'applicazione deve gestire le richieste indirizzate a uno o più relativeURI, indipendentemente dal modo in cui tali richieste arrivano nel computer o dal sito specificato nelle intestazioni host. L'uso di un carattere jolly sicuro in questa situazione evita la necessità di specificare un elenco completo di host e/o indirizzi IP.

esplicito

Un nome host esplicito, ad esempio un nome di dominio completo nell'elemento host, inserisce un UrlPrefix nella categoria esplicita. Questo tipo di elemento host viene confrontato direttamente con le intestazioni Host delle richieste in ingresso.

Le specifiche dell'host esplicite sono utili per applicazioni multisito, ad esempio server Web che forniscono contenuto diverso a seconda del sito a cui è stata indirizzata la richiesta.

carattere jolly debole associato a IP

Quando un indirizzo IP viene visualizzato come elemento host, urlPrefix rientra nella categoria Carattere jolly debole associato a IP. Questo tipo di UrlPrefix corrisponde a qualsiasi nome host per l'interfaccia IP specificata con lo schema, la porta e l'URI relativo specificati e che non è già stato confrontato con un carattere jolly sicuro o un URLPrefix esplicito. L'indirizzo IP accetta una delle due forme nell'elemento host:

stringa letterale IPv4

Un valore letterale IPv4 è costituito da quattro numeri decimali punteggiati, ognuno nell'intervallo da 0 a 255, ad esempio 192.168.0.0.

stringa letterale IPv6

Una stringa letterale IPv6 è racchiusa tra parentesi quadre e contiene numeri esadecimale separati da due punti; ad esempio: [::1] o [3ffe:ffff::6ECB:0101].

Gli identificatori host con caratteri jolly deboli associati a IP sono destinati alle applicazioni che variano il contenuto che servono in base alla route eseguita dalle richieste in ingresso. Non fare affidamento sugli identificatori di host con caratteri jolly deboli associati a IP per applicare la sicurezza.

carattere jolly debole (asterisco)

Quando un asterisco (*) viene visualizzato come elemento host, il prefisso UrlPrefix rientra nella categoria con caratteri jolly deboli. Questo tipo di UrlPrefix corrisponde a qualsiasi nome host associato allo schema, alla porta e all'URI relativo specificato che non è già stato confrontato con un carattere jolly sicuro, esplicito o con carattere jolly con associazione IPPrefix.

Questa specifica host può essere usata come catch-all predefinito in alcune circostanze o può essere usata per specificare una sezione estesa dello spazio dei nomi URL senza dover usare molti urlPrefissi.

Rilevamento dei conflitti urlPrefix durante la prenotazione e la registrazione

Ai fini della prenotazione e della registrazione, le quattro diverse categorie di UrlPrefix vengono trattate separatamente, senza fare riferimento l'una all'altra. È possibile registrare urlprefissi in conflitto purché si trovino in categorie diverse. Solo all'interno della stessa categoria un conflitto causa l'esito negativo di un tentativo di prenotazione.

Ad esempio, sarebbe possibile riservare sia l'urlprefix esplicito https://www.adatum.com:80/vroot/ che il carattere jolly forte in conflitto UrlPrefix https://+:80/vroot/, perché appartengono a categorie diverse. Tuttavia, un tentativo successivo di riservare https://+:80/vroot/ a un utente diverso non riuscirebbe perché sarebbe in conflitto con una prenotazione esistente nella propria categoria.

Comportamento di routing

Quando si instrada una richiesta HTTP in ingresso, l'API server HTTP inizia con la categoria con caratteri jolly sicuri e confronta l'URL in ingresso con url registrati e riservati in tale categoria.

Se l'URL in ingresso corrisponde a una prenotazione ma non a una registrazione, l'API del server HTTP non riesce a eseguire la richiesta. Ciò impedisce a una registrazione con priorità più bassa di essere in grado di prelevare le richieste non previste. Lo stato in caso di errore è 400 ("Richiesta non valida") anziché 503 ("Servizio non disponibile"), perché una restituzione 503 viene talvolta interpretata erroneamente dai gateway di bilanciamento del carico come indicante che il server è stato sovraccaricato.

Se viene trovata una registrazione corrispondente all'interno della categoria, la richiesta viene instradata alla coda delle richieste associata a tale registrazione. La richiesta viene sempre instradata alla coda associata al prefisso URLPrefix più lungo all'interno di una categoria.

Se nella categoria non viene trovata alcuna corrispondenza, l'API del server HTTP passa alla categoria esplicita e ripete la stessa procedura. Per riepilogare, l'ordine in cui vengono esaminate le categorie è il seguente:

1. Carattere jolly sicuro
2. Esplicito
3. IP-Bound carattere jolly debole
4. Carattere jolly debole

Se non viene trovata alcuna corrispondenza in una delle categorie, l'API del server HTTP invia una risposta con un codice di stato 400 per indicare che la richiesta non può essere instradata.

Regola corrispondenza più lunga

All'interno di ogni categoria UrlPrefix, l'API del server HTTP instrada una richiesta alla coda associata al prefisso UrlPrefix più lungo corrispondente. Si supponga, ad esempio, che i due urlPrefissi seguenti vengano registrati in code diverse:

• Queue1 https://www.adatum.com:80/
• Queue2 https://www.adatum.com:80/dir/sna/

L'API server HTTP instrada una richiesta per https://www.adatum.com:80/default.htm a Queue1 e una richiesta di https://www.adatum.com:80/dir/sna/snadefault.htm a Queue2. Instrada una richiesta di https://www.adatum.com:80/dir/app.htm a Queue1 perché la corrispondenza completa più lunga è con il https://www.adatum.com:80/ UrlPrefix, non con il https://www.adatum.com:80/dir/sna UrlPrefix.