UrlPrefix Strings (Stringhe UrlPrefix)

  • Articolo

Nell'API server HTTP un URLPrefix è una stringa Unicode (UTF-16) wide-character con un modulo 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 è senza distinzione tra maiuscole e minuscole. A seconda del modo in cui viene specificata la parte host, un UrlPrefix rientra in una delle quattro categorie di routing seguenti, descritte in dettaglio di seguito:

Carattere jolly forte
Esplicita
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 sempre essere seguito da un carattere di barra ("/"). Si tratta di una stringa di prefisso che indica un sottoalbero nello 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 è senza distinzione tra maiuscole e minuscole.

Esempi di URLPrefixes formati correttamente sono:

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

categorie Host-Specifier

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

Caratteri jolly forti (segno più)

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

Un carattere jolly sicuro è utile quando un'applicazione deve servire le richieste indirizzate a una o più relativeURI, indipendentemente dal modo in cui le 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 indirizzi HOST e/o 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 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 Caratteri jolly deboli associati 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 corrispondente a un carattere jolly sicuro o url esplicito. L'indirizzo IP accetta uno dei due moduli nell'elemento host:

Stringa letterale IPv4

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

Stringa letterale IPv6

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

Gli identificatori host con caratteri jolly con associazione IP sono destinati alle applicazioni che variano il contenuto che servono in base alla route eseguita dalle richieste in ingresso. Non basarsi sugli identificatori host con caratteri jolly deboli associato 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 corrispondente a un carattere jolly sicuro, esplicito o associato a ip con carattere debole UrlPrefix.

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

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 tra loro. È possibile registrare urlprefissi in conflitto purché si trovino in categorie diverse. Solo all'interno della stessa categoria un conflitto causa un tentativo di prenotazione non riuscita.

Ad esempio, sarebbe possibile riservare sia urlPrefix esplicito che urlPrefix in conflitto urlPrefix https://www.adatum.com:80/vroot/https://+:80/vroot/, poiché appartengono a categorie diverse. Tuttavia, un tentativo successivo di riservare https://+:80/vroot/ a un utente diverso avrà esito negativo perché sarebbe in conflitto con una prenotazione esistente nella propria categoria.

Comportamento di routing

Quando si esegue il routing di 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 server HTTP ha esito negativo sulla richiesta. Ciò impedisce a una registrazione con priorità inferiore di essere in grado di raccogliere le richieste non destinate. Lo stato dell'errore è 400 ("Richiesta non valida") anziché 503 ("Servizio non disponibile"), perché una restituzione di 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 di richiesta associata a tale registrazione. La richiesta viene sempre indirizzata alla coda associata all'URLPrefix più lungo corrispondente all'interno di una categoria.

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

  1. Carattere jolly forte
  2. Esplicita
  3. IP-Bound carattere jolly debole
  4. Carattere jolly debole

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

Regola di corrispondenza più lunga

All'interno di ogni categoria UrlPrefix, l'API SERVER HTTP indirizza una richiesta alla coda associata all'URLPrefix più lungo corrispondente. Si supponga, ad esempio, che i due urlPrefissi seguenti siano 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 Queue1 e una richiesta per https://www.adatum.com:80/dir/sna/snadefault.htm queue2. Instrada una richiesta per https://www.adatum.com:80/dir/app.htm Queue1 perché la https://www.adatum.com:80/ corrispondenza completa più lunga è con urlPrefix, non con https://www.adatum.com:80/dir/sna urlPrefix.