Direttive del Caddyfile Le direttive sono parole chiave funzionali che appaiono all'interno dei blocchi dei siti. A volte, possono aprire dei blocchi propri che possono contenere delle sottodirettive, ma le direttive non possono essere usate all'interno di altre direttive, a meno che non sia indicato diversamente. Ad esempio, non potete usare basic_auth all'interno di un blocco file_server, poiché file_server non sa come gestire l'autenticazione. Tuttavia, potete usare alcune direttive all'interno di speciali blocchi direttiva come handle e route, poiché sono specificamente progettati per raggruppare le direttive degli handler HTTP. Sintassi Ordine delle direttive Algoritmo di ordinamento Le seguenti direttive sono fornite di serie con Caddy e possono essere utilizzate nell'HTTP Caddyfile: Direttiva Descrizione abort Interrompe la richiesta HTTP acme_server Un server ACME integrato basic_auth Impone l'autenticazione HTTP Basic bind Personalizza l'indirizzo del socket del server encode Codifica (solitamente comprime) le risposte error Genera un errore file_server Serve file dal disco forward_auth Delega l'autenticazione a un servizio esterno fs Imposta il file system da usare per l'I/O dei file handle Un gruppo di direttive mutualmente esclusive handle_errors Definisce le rotte per la gestione degli errori handle_path Come handle, ma rimuove il prefisso del percorso header Imposta o rimuove gli header di risposta import Include snippet o file intercept Intercetta le risposte scritte da altri handler invoke Invoca una rotta nominata log Abilita il logging degli accessi/richieste log_append Aggiunge un campo al log degli accessi log_skip Salta il logging degli accessi per le richieste corrispondenti log_name Sovrascrive i nomi dei logger su cui scrivere map Mappa un valore di input su uno o più output method Cambia internamente il metodo HTTP metrics Configura l'endpoint di esposizione delle metriche di Prometheus php_fastcgi Serve siti PHP tramite FastCGI push Invia contenuti al client utilizzando il server push di HTTP/2 redir Invia un reindirizzamento HTTP al client request_body Manipola il corpo della richiesta request_header Manipola gli header della richiesta respond Invia una risposta fissa al client reverse_proxy Un reverse proxy potente ed estensibile rewrite Riscrive internamente la richiesta root Imposta il percorso della radice del sito route Un gruppo di direttive trattate letteralmente come una singola unità templates Esegue template sulla risposta tls Personalizza le impostazioni TLS tracing Integrazione con il tracciamento di OpenTelemetry try_files Riscrittura che dipende dall'esistenza dei file uri Manipola l'URI vars Imposta variabili arbitrarie Sintassi La sintassi di ogni direttiva apparirà più o meno così: direttiva [<matcher>] <argomenti...> { sottodirettiva [<argomenti...>] } I simboli <carets> indicano i token da sostituire con i valori effettivi. Le [parentesi quadre] indicano parametri opzionali. I puntini di sospensione ... indicano una continuazione, ovvero uno o più parametri o righe. Le sottodirettive sono tipicamente opzionali se non diversamente documentato, anche se non appaiono tra [parentesi quadre]. Matcher La maggior parte — ma non tutte — delle direttive accetta token matcher, che vi permettono di filtrare le richieste. I token matcher sono solitamente opzionali. Le direttive supportano i matcher se vedete questo nella sintassi di una direttiva: [<matcher>] Poiché i token matcher funzionano tutti allo stesso modo, le varie possibilità per il token matcher non verranno descritte in ogni pagina, per ridurre le duplicazioni. Fate invece riferimento alla documentazione dei matcher per una spiegazione dettagliata della sintassi. Ordine delle direttive Molte direttive manipolano la catena degli handler HTTP. L'ordine in cui tali direttive vengono valutate è importante, quindi un ordine predefinito è cablato all'interno di Caddy. Potete sovrascrivere/personalizzare questo ordinamento usando l'opzione globale order o la direttiva route. tracing map vars fs root log_append log_skip log_name header copy_response_headers # solo nel blocco handle_response di reverse_proxy request_body redir # manipolazione della richiesta in entrata method rewrite uri try_files # handler middleware; alcuni avvolgono le risposte basic_auth forward_auth request_header encode push intercept templates # direttive speciali per il routing e il dispacciamento invoke handle handle_path route # handler che tipicamente rispondono alle richieste abort error copy_response # solo nel blocco handle_response di reverse_proxy respond metrics reverse_proxy php_fastcgi file_server acme_server Algoritmo di ordinamento Per facilità d'uso, l'adattatore Caddyfile ordina le direttive secondo le seguenti regole: Le direttive con nomi diversi sono ordinate in base alla loro posizione nell'ordine predefinito. L'ordine predefinito può essere sovrascritto con l'opzione globale order. Le direttive provenienti dai plugin non hanno un ordine, quindi l'opzione globale order o la direttiva route dovrebbero essere usate per impostarne uno. Le direttive con lo stesso nome sono ordinate in base ai loro matcher. La priorità più alta è data a una direttiva con un singolo matcher di percorso. I matcher di percorso sono ordinati per specificità, dal più specifico al meno specifico. In generale, questo viene eseguito ordinando per la lunghezza del matcher di percorso. C'è un'eccezione: se il percorso termina con un * e i percorsi dei due matcher sono altrimenti uguali, il matcher senza * è considerato più specifico e ordinato più in alto. Ad esempio: /foobar è più specifico di /foo /foo è più specifico di /foo* /foo/* è più specifico di /foo* Una direttiva con qualsiasi altro matcher viene ordinata successivamente, nell'ordine in cui appare nel Caddyfile. Questo include i matcher di percorso con più valori e i matcher con nome. Una direttiva senza matcher (che quindi corrisponde a tutte le richieste) viene ordinata per ultima. La direttiva vars ha l'ordinamento per matcher invertito, perché comporta l'impostazione di valori che possono sovrascriversi a vicenda, quindi il matcher più specifico dovrebbe essere valutato per ultimo. Il contenuto della direttiva route ignora tutte le regole sopra citate e preserva l'ordine in cui le direttive appaiono al suo interno.
Project
