Gestione dei reindirizzamenti HTTP
Panoramica
La gestione del reindirizzamento è un requisito comune sui siti web, spesso utilizzato per reindirizzare URL non esistenti (ad esempio campagne scadute o in seguito a una modifica della struttura del sito web) o per localizzare i contenuti in base al Paese. I reindirizzamenti possono essere gestiti all'origine o presso il CDN. La gestione dei reindirizzamenti a livello CDN potrebbe ridurre il carico sull'origine e ridurre i tempi di risposta. In alcuni casi, come con l'hosting statico (ad esempio S3), i reindirizzamenti non possono essere gestiti sull'origine. I reindirizzamenti su CloudFront vengono gestiti utilizzando le sue funzioni edge.
Decisioni architetturali
I reindirizzamenti possono essere implementati in diversi modi utilizzando le funzioni edge, a seconda delle esigenze. Per progettare l'implementazione migliore per la tua azienda, considera le seguenti domande:
- Con quale frequenza aggiorni la logica di reindirizzamento? L'uso intensivo dei reindirizzamenti in parallelo da parte di diversi team richiede un'implementazione più sofisticata rispetto ai test A/B più semplici e occasionali.
- Quante regole di reindirizzamento hai nella logica? La dimensione del database di reindirizzamento è un fattore da considerare quando si valutano diverse opzioni di archiviazione.
- I reindirizzamenti sono statici o dinamici (ad esempio variano in base al Paese dell'utente o alle funzionalità del dispositivo)? Quando è dinamica, la logica di reindirizzamento deve essere eseguita in un contesto in cui sono disponibili tutti i parametri necessari per variare la risposta.
- Riscrivi l'URL in modo trasparente per l'utente o invii un reindirizzamento 3xx?
Per saperne di più su alcune delle implementazioni dei reindirizzamenti utilizzando le funzioni edge di CloudFront, esamina questo workshop pratico. Nella sezione seguente, condivideremo due implementazioni comuni di Gestione dei reindirizzamenti utilizzando CloudFront.
Casi d'uso comuni
Reindirizzamenti HTTP statici
Se si desidera implementare i reindirizzamenti HTTP con poche regole che cambiano raramente, sarà necessario configurare una funzione CloudFront sull'evento di richiesta del visualizzatore con la logica di reindirizzamento incorporata nel codice della funzione. Quando la logica di reindirizzamento si evolve, è possibile aggiornare il codice della funzione. La nuova logica verrà così applicata agli utenti in pochi secondi.
Ad esempio, la seguente funzione CloudFront, configurata sull'evento di richiesta del visualizzatore, invia una risposta HTTP 3xx agli utenti di Paesi selezionati (Spagna ed Emirati Arabi Uniti) per reindirizzarli alla versione locale di un'applicazione a pagina singola (ad esempio https://example.com/ -> https://example.com/es/). Affinché ciò funzioni, è necessario includere l'intestazione cloudfront-viewer-country nella politica di richiesta di Origin. Essa indica a CloudFront di rendere disponibile questa intestazione nell'oggetto evento della Funzione di CloudFront, utilizzato dalla logica della tua funzione. Bisogna ricordare che in questo codice di esempio l'utente viene reindirizzato in base al suo Paese, a meno che non richieda espressamente una versione dell'applicazione a pagina singola per un Paese diverso.
function handler(event) {
var request = event.request;
var headers = request.headers;
var host = request.headers.host.value;
var supported_countries = ['ie','ae', 'es']; // countries in which you'd like to serve a localized version of your Single Page Application
var defaultCountryIndex = 0; // default country index in the support_countries array. here it is 'ie'
if ((supported_countries.includes(request.uri.substring(1,3))) && ((request.uri.substring(3,4) === '/') || (request.uri.length === 3))) {
// If one of the supported country codes is included in the path (e.g. /es/about) then add index.html when needed to the reauest
return requestWithIndexHTML(request);
} else if ((headers['cloudfront-viewer-country']) && (headers['cloudfront-viewer-country'].value.toLowerCase() !== supported_countries[defaultCountryIndex])){
// Otherwise if the user reauest is coming from one of the supported countries except the default one, then redirect to country specific version (e.g. /about -> /es/about)
var response = {
statusCode: 302,
statusDescription: 'Found',
headers: { location: { value: `https://${host}/${headers['cloudfront-viewer-country'].value.toLowerCase()}${request.uri}` } },
};
return response;
} else {
// Otherwise send rewrite the request to the default country path, add index.html if needed and return
request.uri = '/'+supported_countries[defaultCountryIndex] + request.uri;
return requestWithIndexHTML(request);
}
}
// Add index.html to SPA path when needed
function requestWithIndexHTML(request) {
if (request.uri.endsWith('/')) {
request.uri += 'index.html';
} else if (!request.uri.includes('.')) {
request.uri += '/index.html';
}
return request;
}Reindirizzamenti HTTP in blocco
La funzione CloudFront è anche in grado di supportare mappature di reindirizzamento più ampie con l'uso di CloudFront KeyValueStore, oltre a ciò che è possibile inserire nella dimensione massima della funzione di 10 KB. Ad esempio, è possibile memorizzare gli URI da confrontare nelle chiavi e gli URL di reindirizzamento nel valore. L'URI disponibile nell'oggetto evento della richiesta del visualizzatore può essere valutato per trovare un URI corrispondente e, se ne esiste uno nelle chiavi, la funzione può restituire un reindirizzamento 3xx con il valore associato.
L'utilizzo di KeyValueStore ha anche il vantaggio di disaccoppiare i dati che cambiano regolarmente dal codice. Il KeyValueStore è perfetto come datastore globale (ogni PoP), con lettura a bassa latenza e valori chiave su larga scala (milioni di richieste al secondo).
Requisiti avanzati per i reindirizzamenti HTTP
Una soluzione basata su Lambda@Edge è più adatta a requisiti di reindirizzamento avanzati, che non possono essere soddisfatti dalla dimensione massima di KeyValueStore (5 MB) o dal limite di velocità di modifica di poche chiamate API al secondo. Un esempio è quando molti team di marketing diversi aggiornano quotidianamente centinaia di migliaia di reindirizzamenti di campagne.
In questa architettura, una funzione Lambda@Edge, configurata su un evento di richiesta di origine, viene eseguita su ogni mancato riscontro nella cache per verificare con una archiviazione di regole esterna come S3 o DynamoDB quale regola di reindirizzamento applicare. Le regole vengono gestite direttamente nello storage selezionato, con la possibilità di creare una semplice interfaccia utente per facilitarne la gestione. Un esempio di questa architettura, provvista di un'archiviazione basata su S3 e di un'interfaccia utente di gestione autenticata, è descritto in questo blog .
