Condividi tramite

Routing delle richieste in ingresso

  • Articolo

L'API server HTTP gestisce un database di routing per determinare quale applicazione riceve una richiesta in ingresso. La tabella di routing viene compilata dal database di prenotazione e contiene voci di prenotazione e registrazioni correnti. Quando viene effettuata una registrazione o una prenotazione, viene inserita nel bucket del database di routing che corrisponde al tipo host come indicato di seguito:

  • + : le registrazioni delle porte vengono inserite nel bucket "Carattere jolly sicuro"

  • host: le registrazioni delle porte vengono inserite nel bucket "Esplicito"

  • IP: le registrazioni delle porte vengono inserite nel bucket "Jolly debole associato a IP"

  • * : le registrazioni delle porte vengono inserite nel bucket "Caratteri jolly deboli"

Questi passaggi fanno riferimento anche alle richieste HTTP in ingresso dell'ordine vengono elaborate. Le prenotazioni con caratteri jolly forti prima, quindi la prenotazione esplicita viene controllata seguita da caratteri jolly deboli associati a IP e caratteri jolly deboli. La ricerca si arresta quando viene trovata una corrispondenza in modo che non vengano trovate registrazioni in uno dei bucket rimanenti.

L'algoritmo di routing api HTTP Server individua la corrispondenza migliore per urlPrefix cercando sia le voci di registrazione che le voci di prenotazione del database di routing, a partire dal bucket con caratteri jolly forti e terminando con il bucket con caratteri jolly deboli. La corrispondenza migliore, all'interno di un bucket, è la corrispondenza più lunga nella parte relativa dell'URI dell'URLPrefix (presupponendo una corrispondenza esatta per le parti host, porta e schema dell'URL). Dopo aver trovato una corrispondenza in un bucket, l'algoritmo di routing interrompe la ricerca e ignora tutti i bucket con priorità inferiore.

Si consideri, ad esempio, le registrazioni seguenti (elencate in ordine decrescente di priorità in base ai tipi di bucket:

  • Registrazione: https://+:80/vroot/ registrata dall'applicazione 1

  • Registrazione: https://adatum.com:80/ è registrata dall'applicazione 2

  • Registrazione: https://\*:80/ è registrata dall'applicazione 3

Una richiesta in ingresso per https://adatum.com:80/vroot/subdir/file.htm/ viene recapitata all'applicazione 1. Una richiesta in ingresso per https://adatum.com:80/default.htm/ viene recapitata all'applicazione 2. Una richiesta in ingresso per https://otheradatum.com:80/file.htm/ viene recapitata all'applicazione 3.

Se la corrispondenza migliore è una voce di prenotazione, significa che l'applicazione che deve ricevere la richiesta non è in esecuzione. Si consideri ad esempio la registrazione e la prenotazione seguenti:

  • Registrazione: https://\*:80/vroot/ è registrata dall'applicazione 1, utente A

  • Prenotazione: https://adatum.com:80/ è stata riservata per l'utente B

Una richiesta in ingresso per https://adatum.com:80/vroot/file.htm/ l'applicazione 1 non viene recapitata perché la corrispondenza migliore porta alla voce di prenotazione per l'utente B. Le regole di precedenza vengono applicate in questo caso alla prenotazione con priorità più alta. Se non è attivo alcun processo autorizzato e registrato alle richieste di servizio per l'URL ricevuto, la richiesta viene rifiutata con un codice di stato 400 (richiesta non valida).