IBM Cloud Docs
Utilizzo delle funzioni Edge

Utilizzo delle funzioni Edge

IBM Cloud® Internet Services Le funzioni Edge consentono di creare o modificare applicazioni esistenti, senza dover configurare o mantenere l'infrastruttura, utilizzando un ambiente di esecuzione serverless. Le funzioni Edge possono essere definite e caricate sul cloud edge per elaborare le richieste prima che raggiungano l'origine. CIS Le funzioni Edge possono essere utilizzate per modificare richieste e risposte dell' HTTP, effettuare richieste parallele o generare risposte dal cloud edge.

Come funzionano le funzioni edge

Le funzioni Edge associano le azioni agli URI in base a un dominio definito. Questa associazione è chiamata trigger. Le richieste in arrivo al tuo sito vengono intercettate al limite del cloud e confrontate con i trigger nel tuo account o dominio. Se l' URL e della richiesta corrisponde all'URI del trigger, viene eseguita l'azione associata al trigger.

Le funzioni Edge sono modellate sull'API Service Worker disponibile nei moderni browser web e utilizzano la stessa API ogni volta che è possibile.

L'API Service Worker consente di intercettare qualsiasi richiesta effettuata al tuo sito. Dopo che il tuo sito JavaScript ha gestito la richiesta, puoi scegliere di inviare un numero qualsiasi di richieste secondarie al tuo sito o ad altri, e infine restituire una risposta al tuo visitatore.

A differenza dei processi di lavoro dei servizi standard, le funzioni edge vengono eseguite sui server edge CIS, non nel browser dell'utente. Ciò significa che puoi essere certo che il tuo codice venga eseguito in un ambiente affidabile, dove non può essere aggirato da client dannosi. Ciò significa anche che l'utente non deve utilizzare un browser moderno che supporti i service worker: è possibile persino intercettare le richieste provenienti da client API che non sono browser.

Internamente, le funzioni Edge utilizzano lo stesso motore V8 JavaScript, che viene utilizzato nel browser Chrome per eseguire i lavoratori sulla nostra infrastruttura. V8 compila dinamicamente il tuo codice JavaScript in codice macchina ultra veloce, migliorando le prestazioni. Ciò consente al codice di essere eseguito in microsecondi e al nostro server periferico di eseguire molte migliaia di script al secondo.

Mentre le funzioni edge utilizzano V8, non utilizzano Node.js. Le API JavaScript disponibili all'interno dei nodi di lavoro sono implementate direttamente da noi. Utilizzare direttamente V8 consente al codice di essere eseguito in modo più efficiente e con i controlli di sicurezza necessari per proteggere i clienti e l'infrastruttura.

Gestione delle proprietà di richiesta delle funzioni edge

Qui, discutiamo le API di runtime Cloudflare per funzioni edge CIS. Il runtime delle funzioni edge fornisce le seguenti API Cloudflare per l'uso da parte degli script in esecuzione sul server perimetrale cloud.

Sintassi del costruttore

new Request(input [, init])

Parametri costruttore

  • input: Può essere una USVString che contiene l' URL, oppure un oggetto Request esistente. Si noti che la proprietà " url " è immutabile, quindi quando si modifica una richiesta e si cambia " URL ", è necessario passare il nuovo " URL " in questo parametro.

  • init (facoltativo): un oggetto opzioni che contiene impostazioni personalizzate da applicare alla richiesta. I valori validi sono:

    • method: il metodo di richiesta, come GET o POST
    • headers: un oggetto Headers
      • body: qualsiasi testo da aggiungere alla richiesta. Le richieste che utilizzano i metodi GET o HEAD non possono avere un corpo.

      • redirect: la modalità rispettata quando la richiesta viene richiamata. Il valore predefinito per le richieste generate dal fetchEvent in entrata dal gestore eventi è manual. Valore predefinito per le richieste appena create (in altre parole, new Request (url) ) è follow. Opzioni valide:

        • follow: se una risposta di reindirizzamento viene restituita al fetch, un altro fetch viene attivato in base all'intestazione Location nella risposta finché non viene restituito un codice non di reindirizzamento. Ad esempio, await fetch(..) non potrebbe mai restituire un reindirizzamento 301.
        • manual: le risposte di reindirizzamento restituiscono un richiamo.

Proprietà

Tutte le proprietà di un oggetto Request in ingresso (event.request) sono di sola lettura. Per modificare una richiesta, è necessario creare un oggetto Request e passare le opzioni da modificare al relativo costruttore.

  • body: un semplice getter che espone un ReadableStream del contenuto.
  • bodyUsed: un booleano che dichiara se il corpo è stato utilizzato in una risposta.
  • cf: un oggetto che contiene dati forniti dai nostri partner di Cloudflare.
  • headers: contiene l'oggetto Headers associato per la richiesta.
  • method: il metodo di richiesta, come GET o POST, associato alla richiesta.
  • redirect: la modalità di reindirizzamento da utilizzare ( follow o manual).
  • url: Contiene l' URL a della richiesta.

L'oggetto cf

Oltre alle proprietà sull'oggetto Request standard, è possibile utilizzare un oggetto request.cf per controllare il modo in cui vengono applicate le funzioni e altre informazioni personalizzate fornite da Cloudflare. Ad esempio,

  if (request.cf.asn == 64512) {
    return new Response('Block the ASN 64512 response')
  }

Se si sta utilizzando https://cloudflareworkers.com per scrivere e verificare gli script, il contenuto di request.cf non è disponibile in modalità anteprima. È necessario essere in produzione per eseguire tale contenuto.

Queste proprietà contengono informazioni speciali da una richiesta in entrata per aiutare con la logica della tua applicazione. Tutti i piani hanno accesso a:

  • asn: ASN della richiesta in entrata (ad esempio, 395747).
  • colo: il codice aeroporto di tre lettere del centro dati che ha raggiunto la richiesta (ad esempio, "DFW").
  • weight: Il peso richiesto dal browser per l'impostazione della priorità HTTP/2.
  • exclusive: L'indicatore esclusivo HTTP/2 richiesto dal browser (1 per browser basati su Chromium, 0 per altri).
  • ID flusso group: HTTP/2 per il gruppo di richiesta (diverso da zero solo per Firefox).
  • group-weight: peso HTTP/2 per il gruppo di richiesta (diverso da zero solo per Firefox).
  • tlsCipher: la cifratura per la connessione a CIS (ad esempio "AEAD-AES128-GCM-SHA256").
  • country: il codice paese di due lettere della richiesta in entrata. Lo stesso valore viene fornito nell'intestazione CF-IPCountry (ad esempio, "US").
  • tlsClientAuth: impostato solo quando abilitato per mTLS. L'oggetto ha le seguenti proprietà: certIssuerDNLegacy, certIssuerDN, certIssuerDNRFC2253, certSubjectDNLegacy, certVerified, certNotAfter, certSubjectDN, certFingerprintSHA1, certNotBefore, certSerial, certPresented, certSubjectDNRFC2253
  • tlsVersion: la versione TLS della connessione a CIS (ad esempio, TLSv1.3).

I piani Standard e Enterprise hanno accesso a:

  • requestPriority: le informazioni di priorità richieste dal browser nell'oggetto richiesta (ad esempio, “weight=192;exclusive=0;group=3;group-weight=127”).
  • city: città della richiesta in entrata (ad esempio, "Austin").
  • continent: il continente della richiesta in entrata (ad esempio, "NA").
  • httpProtocol: Protocollo HTTP (ad esempio, "HTTP/2").
  • latitude: latitudine della richiesta in entrata (ad esempio, "30.27130").
  • longitude: longitudine della richiesta in entrata (ad esempio, "-97.74260").
  • postalCode: PostalCode della richiesta in entrata (ad esempio, "78701").
  • region: se noto, il nome ISO 3166-2 per la regione di primo livello associata all'indirizzo IP della richiesta in entrata. Se non è noto, è una stringa vuota (ad esempio, "Texas").
  • regionCode: se noto, il codice ISO 3166-2 per la region di primo livello associato all'indirizzo IP della richiesta in entrata. Se non è noto, è una stringa vuota (ad esempio, "TX").
  • timezone: fuso orario della richiesta in entrata (ad esempio, "America/Chicago").

Tutti i piani possono impostare queste funzioni sulle richieste in uscita.

  • cacheEverything: questa opzione forza CIS a memorizzare nella cache la risposta per questa richiesta, indipendentemente dalle intestazioni visualizzate nella risposta. Ciò equivale a impostare la regola della pagina "Livello cache" su "Cache Everything" (ad esempio, true).

  • scrapeShield: attiva / disattiva ScrapeShield (ad esempio, false).

  • polish: impostare la modalità polacca Cloudflare. I valori possibili sono "lossy", "lossless" o "off" (ad esempio, lossless).

  • minify: ottimizzazione del sito web per abilitare / disabilitare Cloudflare Autominify per vari tipi di file. Il valore è un oggetto contenente campi booleani per javascript, css e html (ad esempio, { javascript: true, css: true, html: false }).

  • mirage: ottimizzazione immagine per abilitare / disabilitare il miraggio Cloudflare. Quando si specifica questa opzione, il valore deve essere sempre false (ad esempio, false).

  • cacheTtl: questa opzione forza CIS a memorizzare nella cache la risposta per questa richiesta, indipendentemente dalle intestazioni visualizzate nella risposta. Ciò equivale a impostare due regole di pagina: "Edge Cache TTL" e "Cache Level" (per "Cache Everything"; ad esempio,300).

  • resolveOverride: reindirizza la richiesta a un server di origine alternativo. È possibile utilizzarlo per implementare il bilanciamento del carico su diverse origini (ad esempio us-east.example.com).

    Per motivi di sicurezza, l'hostname impostato in 'resolveOverride deve essere proxy sulla stessa zona 'CIS della richiesta in arrivo. Altrimenti, l'impostazione viene ignorata. Gli host CNAME sono consentiti, quindi per risolvere a un host sotto un dominio diverso o un dominio solo DNS, dichiarare prima un record CNAME all'interno della mappatura DNS della propria zona per il nome host esterno, impostare il proxy su CIS, quindi impostare resolveOverride per puntare a quel record CNAME.

Solo Enterprise

  • cacheKey: la chiave della cache di una richiesta è ciò che determina se due richieste sono "uguali" ai fini della memorizzazione nella cache. Se una richiesta ha la stessa chiave cache di una richiesta precedente, possiamo fornire la stessa risposta memorizzata nella cache per entrambi (ad esempio, 'some-key').
  • cacheTtlByStatus: questa opzione rappresenta una versione della funzione cacheTtl che sceglie un TTL basato sul codice di stato della risposta. Se la risposta a questa richiesta ha un codice di stato corrispondente, CIS memorizza nella cache per il tempo indicato e sovrascrive le istruzioni della cache inviate dall'origine (ad esempio, { "200-299": 86400, 404: 1, "500-599": 0 }). CIS aderisce ancora ai livelli di cache standard, quindi per impostazione predefinita sovrascrive il comportamento della cache per i file statici. Se si desidera memorizzare nella cache risorse non statiche, è necessario impostare un livello di cache pari a "memorizza tutto nella cache" utilizzando una regola di pagina.

Uno script di funzioni Edge viene eseguito dopo le funzioni di sicurezza di CIS, ma prima di tutto. Pertanto, uno script delle funzioni Edge non può influire sul funzionamento delle funzioni di sicurezza (poiché sono già terminate), ma può influire su altre funzioni, come l'ottimizzazione delle dimensioni delle immagini o il modo in cui la risposta viene memorizzata nella cache all'edge.

L'aggiornamento dell'oggetto cf è simile alla modifica di una richiesta. È possibile aggiungere l'oggetto cf ad un Request passando un oggetto personalizzato a fetch.

// Disable ScrapeShield for this request.
fetch(event.request, { cf: { scrapeShield: false } })

Impostazioni non valide o con nome non corretto nell'oggetto cf vengono ignorate in modalità non presidiata. Fare attenzione a verificare che si sta ottenendo il comportamento desiderato.

Casi di utilizzo della funzione Edge

Questi esempi sono solo a scopo dimostrativo e non sono progettati per essere utilizzati nella produzione.