Configurazione di Dispatcher configuring-dispatcher

Le sezioni seguenti descrivono come configurare vari aspetti di Dispatcher.

Supporto per IPv4 e IPv6 support-for-ipv-and-ipv

Tutti gli elementi di AEM e Dispatcher possono essere installati nelle reti IPv4 e IPv6. Vedi IPV4 e IPV6.

File di configurazione di Dispatcher dispatcher-configuration-files

Per impostazione predefinita, la configurazione di Dispatcher viene memorizzata nel file di testo dispatcher.any, anche se è possibile modificare il nome e la posizione del file durante l’installazione.

Il file di configurazione contiene una serie di proprietà con valore singolo o più valori che controllano il comportamento di Dispatcher:

Esempio di configurazione strutturata come segue:

# name of the dispatcher
/name "internet-server"

# each farm configures a set off (loadbalanced) renders
/farms
 {
  # first farm entry (label is not important, just for your convenience)
   /website
     {
     /clientheaders
       {
       # List of headers that are passed on
       }
     /virtualhosts
       {
       # List of URLs for this Web site
       }
     /sessionmanagement
       {
       # settings for user authentification
       }
     /renders
       {
       # List of AEM instances that render the documents
       }
     /filter
       {
       # List of filters
       }
     /vanity_urls
       {
       # List of vanity URLs
       }
     /cache
       {
       # Cache configuration
       /rules
         {
         # List of cachable documents
         }
       /invalidate
         {
         # List of auto-invalidated documents
         }
       }
     /statistics
       {
       /categories
         {
         # The document categories that are used for load balancing estimates
         }
       }
     /stickyConnectionsFor "/myFolder"
     /health_check
       {
       # Page gets contacted when an instance returns a 500
       }
     /retryDelay "1"
     /numberOfRetries "5"
     /unavailablePenalty "1"
     /failover "1"
     }
 }

Puoi includere altri file che contribuiscono alla configurazione:

Ad esempio, per includere il file myFarm.any nella configurazione di /farms, utilizza il seguente codice:

/farms
  {
  $include "myFarm.any"
  }

Per specificare un intervallo di file da includere, utilizza l’asterisco (*) come carattere jolly.

Ad esempio, se i file da farm_1.any a farm_5.any contengono la configurazione delle farm da uno a cinque, puoi includerli come segue:

/farms
  {
  $include "farm_*.any"
  }

Utilizzo delle variabili di ambiente using-environment-variables

Puoi utilizzare le variabili di ambiente nelle proprietà con valori stringa nel file dispatcher.any, invece di utilizzare valori a codifica fissa (hard-coding). Per includere il valore di una variabile di ambiente, utilizza il formato ${variable_name}.

Ad esempio, se il file dispatcher.any si trova nella stessa directory della cache, è possibile utilizzare il seguente valore per la proprietà docroot:

/docroot "${PWD}/cache"

Altro esempio: se crei una variabile di ambiente denominata PUBLISH_IP, che memorizza il nome host dell’istanza di pubblicazione di AEM, puoi utilizzare la seguente configurazione della proprietà /renders:

/renders {
  /0001 {
    /hostname "${PUBLISH_IP}"
    /port "8443"
  }
}

Denominazione dell’istanza di Dispatcher naming-the-dispatcher-instance-name

Utilizza la proprietà /name per specificare un nome univoco per identificare l’istanza di Dispatcher. La proprietà /name è una proprietà di alto livello nella struttura della configurazione.

Definizione delle farm defining-farms-farms

La proprietà /farms definisce uno o più set di comportamenti di Dispatcher e ciascun set è associato a siti web o URL diversi. La proprietà /farms può includere una o più farm:

La proprietà /farms è una proprietà di alto livello nella struttura della configurazione. Per definire una farm, aggiungi una proprietà figlio alla proprietà /farms. Utilizza un nome di proprietà che identifichi in modo univoco la farm all’interno dell’istanza di Dispatcher.

La proprietà /farmname ha più valori e contiene altre proprietà che definiscono il comportamento di Dispatcher:

Il valore può includere qualsiasi carattere alfanumerico (a-z, 0-9). L’esempio che segue mostra la definizione dello scheletro per due farm denominate /daycom e /docsdaycom:

#name of dispatcher
/name "day sites"

#farms section defines a list of farms or sites
/farms
{
   /daycom
   {
       ...
   }
   /docdaycom
   {
      ...
   }
}

Ogni proprietà farm può contenere le seguenti proprietà figlio:

Specifica una pagina predefinita (solo IIS): /homepage specify-a-default-page-iis-only-homepage

Specifica delle intestazioni HTTP da trasmettere specifying-the-http-headers-to-pass-through-clientheaders

La proprietà /clientheaders definisce un elenco di intestazioni HTTP che Dispatcher trasmette dalla richiesta HTTP del client al renderer (istanza di AEM).

Per impostazione predefinita, Dispatcher inoltra le intestazioni HTTP standard all’istanza di AEM. In alcune istanze, potrebbe essere utile inoltrare intestazioni aggiuntive o rimuovere intestazioni specifiche:

Se personalizzi il set di intestazioni da trasmettere, devi specificare un elenco completo di intestazioni, incluse quelle che sono normalmente già in uso per impostazione predefinita.

Ad esempio, un’istanza di Dispatcher che gestisce le richieste di attivazione delle pagine per le istanze di pubblicazione richiede l’intestazione PATH nella sezione /clientheaders. L’intestazione PATH abilita la comunicazione tra l’agente di replica e Dispatcher.

Il codice che segue è un esempio di configurazione per /clientheaders:

/clientheaders
  {
  "CSRF-Token"
  "X-Forwarded-Proto"
  "referer"
  "user-agent"
  "authorization"
  "from"
  "content-type"
  "content-length"
  "accept-charset"
  "accept-encoding"
  "accept-language"
  "accept"
  "host"
  "max-forwards"
  "proxy-authorization"
  "proxy-connection"
  "range"
  "cookie"
  "cq-action"
  "cq-handle"
  "handle"
  "action"
  "cqstats"
  "depth"
  "translate"
  "expires"
  "date"
  "dav"
  "ms-author-via"
  "if"
  "lock-token"
  "x-expected-entity-length"
  "destination"
  "PATH"
  }

Identificazione di host virtuali identifying-virtual-hosts-virtualhosts

La proprietà /virtualhosts definisce un elenco di tutte le combinazioni nome host e URI accettate da Dispatcher per questa farm. È possibile utilizzare il carattere asterisco (*) come carattere jolly. I valori della proprietà /virtualhosts utilizzano il seguente formato:

[scheme]host[uri][*]

Nell’esempio seguente, la configurazione gestisce le richieste per i domini .com e .ch di myCompany e per tutti i domini di mySubDivision:

   /virtualhosts
    {
    "www.myCompany.com"
    "www.myCompany.ch"
    "www.mySubDivison.*"
    }

La configurazione che segue gestisce tutte le richieste:

   /virtualhosts
    {
    "*"
    }

Risoluzione dell’host virtuale resolving-the-virtual-host

Quando Dispatcher riceve una richiesta HTTP o HTTPS, trova il valore dell’host virtuale che negli corrisponde alle intestazioni host, uri e scheme della richiesta. Dispatcher valuta i valori delle proprietà virtualhosts nel seguente ordine:

Dispatcher trova il valore dell’host virtuale più corrispondente nel modo seguente:

Pertanto, devi posizionare l’host virtuale predefinito nella parte superiore della proprietà virtualhosts. Posizionalo nella farm più in alto del file dispatcher.any.

Esempio di risoluzione dell’host virtuale example-virtual-host-resolution

L’esempio che segue è un frammento di codice preso da un file dispatcher.any che definisce due farm di Dispatcher e ciascuna farm definisce una proprietà virtualhosts.

/farms
  {
  /myProducts
    {
    /virtualhosts
      {
      "www.mycompany.com/products/*"
      }
    /renders
      {
      /hostname "server1.myCompany.com"
      /port "80"
      }
    }
  /myCompany
    {
    /virtualhosts
      {
      "www.mycompany.com"
      }
    /renders
      {
      /hostname "server2.myCompany.com"
      /port "80"
      }
    }
  }

Utilizzando questo esempio, la tabella che segue mostra gli host virtuali risolti per le richieste HTTP specificate:

Abilitazione di sessioni sicure: /sessionmanagement enabling-secure-sessions-sessionmanagement

Crea una sessione protetta per l’accesso alla farm di rendering, in modo che gli utenti debbano effettuare il login per accedere a qualsiasi pagina della farm. Una volta effettuato il login, gli utenti possono accedere alle pagine della farm. Per informazioni sull’utilizzo di questa funzione con i gruppi utenti chiusi (CUG), vedi Creazione di un gruppo utenti chiuso. Inoltre, vedi Elenco di controllo della sicurezza di Dispatcher prima di andare “live”.

La proprietà /sessionmanagement è una sottoproprietà di /farms.

/sessionmanagement ha diversi sottoparametri:

/directory (obbligatorio)

La directory in cui sono memorizzate le informazioni della sessione. Se la directory non esiste, viene creata.

/sessionmanagement
  {
  /directory "/usr/local/apache/.sessions"
  }

/encode (facoltativo)

Codifica delle informazioni della sessione. Utilizza md5 per la crittografia, utilizzando l’algoritmo md5 oppure hex per la codifica esadecimale. Se crittografi i dati della sessione, un utente con accesso al file system non può leggere il contenuto della sessione. Il valore predefinito è md5.

/header (facoltativo)

Nome dell’intestazione HTTP o del cookie che memorizza le informazioni di autorizzazione. Se memorizzi le informazioni nell’intestazione http, utilizza HTTP:<header-name>. Per memorizzare le informazioni in un cookie, utilizza Cookie:<header-name>. Se non specifichi alcun valore, viene utilizzato HTTP:authorization.

/timeout (facoltativo)

Il numero di secondi prima che la sessione vada in timeout dopo l’ultimo utilizzo. Se non specificato, viene utilizzato "800", quindi sessione va in timeout poco più di 13 minuti dopo l’ultima richiesta dell’utente.

Esempio di configurazione:

/sessionmanagement
  {
  /directory "/usr/local/apache/.sessions"
  /encode "md5"
  /header "HTTP:authorization"
  /timeout "800"
  }

Definizione dei renderer di pagine defining-page-renderers-renders

La proprietà /renders definisce l’URL a cui Dispatcher invia le richieste di rendering di un documento. L’esempio di sezione /renders seguente identifica una singola istanza di AEM per il rendering:

/renders
  {
    /myRenderer
      {
      # hostname or IP of the renderer
      /hostname "aem.myCompany.com"
      # port of the renderer
      /port "4503"
      # connection timeout in milliseconds, "0" (default) waits indefinitely
      /timeout "0"
      }
  }

L’esempio di sezione /renders seguente identifica un’istanza di AEM che viene eseguita sullo stesso computer di Dispatcher:

/renders
  {
    /myRenderer
     {
     /hostname "127.0.0.1"
     /port "4503"
     }
  }

L’esempio di sezione /renders seguente distribuisce le richieste di rendering equamente tra due istanze di AEM:

/renders
  {
    /myFirstRenderer
      {
      /hostname "aem.myCompany.com"
      /port "4503"
      }
    /mySecondRenderer
      {
      /hostname "127.0.0.1"
      /port "4503"
      }
  }

Opzioni di rendering renders-options

/timeout

Specifica il timeout di connessione per l’accesso all’istanza di AEM espresso in millisecondi. Il valore predefinito è "0" e Dispatcher deve attendere indefinitamente.

/receiveTimeout

Specifica il tempo in millisecondi che una risposta può richiedere. Il valore predefinito è "600000" e Dispatcher deve attendere 10 minuti. L’impostazione di "0" elimina il timeout.

Se viene raggiunto il timeout durante l’analisi delle intestazioni di risposta, viene restituito lo stato HTTP 504 (Gateway non valido). Se viene raggiunto il timeout durante la lettura del corpo della risposta, Dispatcher restituisce la risposta incompleta al client. Elimina anche eventuali file memorizzati in cache che potrebbero essere stati scritti.

/ipv4

Specifica se Dispatcher utilizza la funzione getaddrinfo (per IPv6) o la funzione gethostbyname (per IPv4) per ottenere l’indirizzo IP del rendering. Se si imposta il valore 0, viene utilizzato getaddrinfo. Se si imposta il valore 1, viene utilizzato gethostbyname. Il valore predefinito è 0.

La funzione getaddrinfo restituisce un elenco di indirizzi IP. Dispatcher scorre l’elenco degli indirizzi fino a quando non stabilisce una connessione TCP/IP. Pertanto, la proprietà ipv4 è importante quando il nome host di rendering è associato a più indirizzi IP. E, l’host, in risposta alla funzione getaddrinfo, restituisce un elenco di indirizzi IP che sono sempre nello stesso ordine. In questa situazione, utilizza la funzione gethostbyname in modo che l’indirizzo IP con cui Dispatcher si connette sia randomizzato.

L’ELB (Elastic Load Balancing) di Amazon è un servizio che risponde a getaddrinfo con un elenco potenzialmente identico di indirizzi IP.

/secure

Se per la proprietà /secure è impostato il valore "1", Dispatcher utilizza HTTPS per comunicare con l’istanza AEM. Per ulteriori dettagli, consulta la Configurazione del Dispatcher per utilizzare SSL.

/always-resolve

Con la versione di Dispatcher 4.1.6, puoi configurare la proprietà /always-resolve come segue:

Questa proprietà può essere utilizzata anche in caso di problemi di risoluzione degli IP dinamici, come illustrato nell’esempio che segue:

/renders {
  /0001 {
     /hostname "host-name-here"
     /port "4502"
     /ipv4 "1"
     /always-resolve "1"
     }
  }

Configurazione dell’accesso al contenuto configuring-access-to-content-filter

Utilizza la sezione /filter per specificare le richieste HTTP che Dispatcher può accettare. Tutte le altre richieste vengono rimandate al server web con codice di errore 404 (pagina non trovata). Se non esiste alcuna sezione /filter, tutte le richieste vengono accettate.

Nota: le richieste di statfile vengono sempre rifiutate.

La sezione /filter consiste di una serie di regole che negano o consentono l’accesso al contenuto in base ai modelli presenti nella parte della riga della richiesta HTTP. Utilizza una strategia di inserire nell’elenco Consentiti per la tua sezione /filter:

Definizione di un filtro defining-a-filter

Ogni elemento della sezione /filter include un tipo e un modello corrispondenti a un elemento specifico della riga di richiesta o all’intera riga di richiesta. Ciascun filtro può contenere i seguenti elementi:

La parte riga di richiesta delle richieste HTTP the-request-line-part-of-http-requests

HTTP/1.1 definisce la riga di richiesta come segue:

Method Request-URI HTTP-Version<CRLF>

I caratteri <CRLF> rappresentano un ritorno a capo seguito da un avanzamento riga. L’esempio che segue è la riga di richiesta ricevuta quando un cliente richiede la pagina in inglese US del sito WKND:

GET /content/wknd/us/en.html HTTP.1.1<CRLF>

I modelli devono tenere conto dei caratteri di spaziatura nella riga di richiesta e dei caratteri <CRLF>.

Virgolette e apici double-quotes-vs-single-quotes

Quando crei le regole del filtro, utilizza le virgolette "pattern" per i modelli semplici. Se utilizzi Dispatcher 4.2.0 o versioni successive e il modello include un’espressione regolare, devi racchiudere il modello regex '(pattern1|pattern2)' tra apici.

Espressioni regolari regular-expressions

Nelle versioni di Dispatcher successive alla versione 4.2.0, è possibile includere nei modelli dei filtri le espressioni regolari estese POSIX.

Risoluzione dei problemi dei filtri troubleshooting-filters

Se i filtri non si attivano come previsto, abilita la registrazione della traccia in Dispatcher che ti permette di vedere quale filtro intercetta la richiesta.

Esempio di filtro: rifiuta tutto example-filter-deny-all

Nel seguente esempio della sezione “filter”, Dispatcher rifiuterà le richieste di tutti i file. È necessario negare l’accesso a tutti i file e quindi consentire l’accesso ad aree specifiche.

/0001  { /type "deny" /url "*"  }

Le richieste inviate a un’area negata in modo esplicito causano la restituzione del codice di errore 404 (pagina non trovata).

Esempio di filtro: nega l’accesso ad aree specifiche example-filter-deny-access-to-specific-areas

I filtri consentono anche di negare l’accesso a vari elementi, ad esempio pagine ASP e aree sensibili all’interno di un’istanza di pubblicazione. Il filtro che segue nega l’accesso alle pagine ASP:

/0002  { /type "deny" /url "*.asp"  }

Esempio di filtro: abilita le richieste POST example-filter-enable-post-requests

Il filtro di esempio che segue consente l’inoltro di dati di moduli tramite il metodo POST:

/filter {
    /0001  { /glob "*" /type "deny" }
    /0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }
}

Esempio di filtro: consenti l’accesso alla console del flusso di lavoro example-filter-allow-access-to-the-workflow-console

L’esempio che segue mostra un filtro utilizzato per consentire l’accesso esterno alla console del flusso di lavoro:

/filter {
    /0001  { /glob "*" /type "deny" }
    /0002  {  /type "allow"  /url "/libs/cq/workflow/content/console*"  }
}

Se la tua istanza di pubblicazione utilizza il contesto di un’applicazione web (ad esempio, per la pubblicazione), anche questa condizione può essere aggiunta alla definizione del filtro.

/0003   { /type "deny"  /url "/publish/libs/cq/workflow/content/console/archive*"  }

Se hai comunque bisogno di accedere a singole pagine all’interno dell’area riservata, puoi consentire l’accesso a quelle pagine. Ad esempio, per consentire l’accesso alla scheda Archivio nella console del flusso di lavoro, aggiungi la sezione seguente:

/0004  { /type "allow"  /url "/libs/cq/workflow/content/console/archive*"   }

Esempio di filtro: utilizzo di espressioni regolari example-filter-using-regular-expressions

Questo filtro abilita le estensioni nelle directory di contenuto non pubblico utilizzando un’espressione regolare, qui definita qui tra apici:

/005  {  /type "allow" /extension '(css|gif|ico|js|png|swf|jpe?g)' }

Esempio di filtro: filtro per elementi aggiuntivi dell’URL di una richiesta example-filter-filter-additional-elements-of-a-request-url

Di seguito è riportato un esempio di regola che blocca l’acquisizione del contenuto dal percorso /content e dalla relativa sottostruttura, utilizzando i filtri per percorso, selettori ed estensioni:

/006 {
        /type "deny"
        /path "/content/*"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy|sysview|docview|query|jcr:content|_jcr_content|search|childrenlist|ext|assets|assetsearch|[0-9-]+)'
        /extension '(json|xml|html|feed))'
        }

Esempio: sezione /filter example-filter-section

Durante la configurazione di Dispatcher, limita il più possibile l’accesso esterno. L’esempio che segue fornisce un accesso minimo per i visitatori esterni:

Dopo aver creato i filtri, verifica l’accesso alla pagina per garantire la protezione dell’istanza AEM.

La seguente sezione /filter del file dispatcher.any può essere utilizzata come base nel file di configurazione di Dispatcher.

Questo esempio si basa sul file di configurazione predefinito fornito con Dispatcher ed destinato all’utilizzo in un ambiente di produzione. Gli elementi con prefisso # sono disattivati (impostati come commento). Presta attenzione se decidi di attivare uno qualsiasi di questi elementi (rimuovendo la # su quella linea). Questo può avere un impatto sulla sicurezza.

Devi prima negare l’accesso a tutto, quindi consentire l’accesso a elementi specifici (limitati):

  /filter
      {
      # Deny everything first and then allow specific entries
      /0001  { /type "deny" /url "*"  }

      # Open consoles
#     /0011 { /type "allow" /url "/admin/*"  }  # allow servlet engine admin
#     /0012 { /type "allow" /url "/crx/*"    }  # allow content repository
#     /0013 { /type "allow" /url "/system/*" }  # allow OSGi console

      # Allow non-public content directories
#     /0021 { /type "allow" /url "/apps/*"   }  # allow apps access
#     /0022 { /type "allow" /url "/bin/*"    }
      /0023 { /type "allow" /url "/content*" }  # disable this rule to allow mapped content only

#     /0024 { /type "allow" /url "/libs/*"   }
#     /0025 { /type "deny"  /url "/libs/shindig/proxy*" } # if you enable /libs close access to proxy

#     /0026 { /type "allow" /url "/home/*"   }
#     /0027 { /type "allow" /url "/tmp/*"    }
#     /0028 { /type "allow" /url "/var/*"    }

      # Enable extensions in non-public content directories, using a regular expression
      /0041
        {
        /type "allow"
        /extension '(css|gif|ico|js|png|swf|jpe?g)'
        }

      # Enable features
      /0062 { /type "allow" /url "/libs/cq/personalization/*"  }  # enable personalization

      # Deny content grabbing, on all accessible pages, using regular expressions
      /0081
        {
        /type "deny"
        /selectors '((sys|doc)view|query|[0-9-]+)'
        /extension '(json|xml)'
        }
      # Deny content grabbing for /content and its subtree
      /0082
        {
        /type "deny"
        /path "/content/*"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
        /extension '(json|xml|html)'
        }

#     /0087 { /type "allow" /method "GET" /extension 'json' "*.1.json" }  # allow one-level json requests
}

Se scegli di estendere l’accesso, considera le seguenti raccomandazioni:

A seconda dell’installazione, ci potrebbero essere risorse aggiuntive in /libs, /apps o altrove che devono essere rese disponibili. Puoi utilizzare il file access.log come metodo per determinare le risorse a cui si accede esternamente.

Limitazione delle stringhe di query restricting-query-strings

A partire dalla versione 4.1.5 di Dispatcher, utilizza la sezione /filter per limitare le stringhe di query. Si consiglia di consentire esplicitamente le stringhe di query ed escludere la tolleranza generica tramite gli elementi del filtro allow.

Una singola voce può avere glob o una combinazione di method, url, query e version, ma non entrambi. L’esempio che segue consente la stringa di query a=* e nega tutte le altre stringhe di query per gli URL che si risolvono nel nodo /etc:

/filter {
 /0001 { /type "deny" /method "POST" /url "/etc/*" }
 /0002 { /type "allow" /method "GET" /url "/etc/*" /query "a=*" }
}

/filter {
>/0001 { /type "deny" /method "*" /url "/path/*" }
>/0002 { /type "allow" /method "GET" /url "/path/*" }
>/0003 { /type "deny" /method "GET" /url "/path/*" /query "*" }
>/0004 { /type "allow" /method "GET" /url "/path/*" /query "a=*" }
}

Verifica della sicurezza di Dispatcher testing-dispatcher-security

I filtri di Dispatcher devono bloccare l’accesso alle pagine e agli script seguenti sulle istanze di AEM Publish. Utilizza un browser web per tentare di aprire le pagine seguenti come farebbe un visitatore del sito e verifica che venga restituito il codice 404. Se ottiene qualunque altro risultato, regola i filtri.

Dovresti vedere il normale rendering della pagina per /content/add_valid_page.html?debug=layout.

Per determinare se l’accesso in scrittura anonima è abilitato, esegui il comando seguente in un terminale o in un prompt dei comandi. La scrittura di dati nel nodo non dovrebbe essere possibile.

curl -X POST "https://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"

Per tentare di annullare la validità della cache del Dispatcher e assicurarti di ricevere una risposta del codice 403, esegui il seguente comando in un terminale o in un prompt dei comandi:

curl -H "CQ-Handle: /content" -H "CQ-Path: /content" https://yourhostname/dispatcher/invalidate.cache

Abilitazione dell’accesso agli URL personalizzati enabling-access-to-vanity-urls-vanity-urls

Configura Dispatcher per abilitare l’accesso agli URL personalizzati che sono configurati per le pagine AEM.

Quando l’accesso agli URL personalizzati è abilitato, Dispatcher chiama periodicamente un servizio che viene eseguito sull’istanza di rendering per ottenere un elenco di URL personalizzati. Dispatcher memorizza l’elenco in un file locale. Quando una richiesta per una pagina viene negata a causa di un filtro nella sezione /filter, Dispatcher consulta l’elenco degli URL personalizzati. Se l’URL negato è presente nell’elenco, Dispatcher consente l’accesso all’URL personalizzato.

Per abilitare l’accesso agli URL personalizzati, aggiungi una sezione /vanity_urls alla sezione /farms, simile all’esempio che segue:

 /vanity_urls {
      /url "/libs/granite/dispatcher/content/vanityUrls.html"
      /file "/tmp/vanity_urls"
      /delay 300
 }

La sezione /vanity_urls contiene le seguenti proprietà:

Utilizza la procedura seguente per abilitare l’accesso agli URL personalizzati.

Inoltro delle richieste di distribuzione del contenuto: /propagateSyndPost forwarding-syndication-requests-propagatesyndpost

Le richieste di distribuzione del contenuto sono solitamente destinate solo a Dispatcher, pertanto per impostazione predefinita non vengono inviate al renderer (ad esempio, un’istanza AEM).

Se necessario, imposta la proprietà /propagateSyndPost su "1" per inoltrare le richieste di distribuzione del contenuto a Dispatcher. Se impostata, accertati che le richieste POST non siano negate nella sezione del filtro.

Configurazione della cache di Dispatcher: /cache configuring-the-dispatcher-cache-cache

La sezione /cache controlla come Dispatcher memorizza in cache i documenti. Configura diverse sottoproprietà per implementare le strategie di caching:

Un esempio di sezione cache potrebbe essere il seguente:

/cache
  {
  /docroot "/opt/dispatcher/cache"
  /statfile  "/tmp/dispatcher-website.stat"
  /allowAuthorized "0"

  /rules
    {
    # List of files that are cached
    }

  /invalidate
    {
    # List of files that are auto-invalidated
    }
  }

Specifica della directory della cache specifying-the-cache-directory

La proprietà /docroot identifica la directory in cui sono archiviati i file memorizzati in cache.

Se utilizzi più farm, ogni farm deve utilizzare una radice documento diversa.

Denominazione dello statfile naming-the-statfile

La proprietà /statfile identifica il file da utilizzare come statfile. Dispatcher utilizza questo file per registrare l’ora dell’aggiornamento di contenuto più recente. Lo statfile può essere qualsiasi file sul server web.

Lo statfile non ha contenuto. Quando il contenuto viene aggiornato, Dispatcher aggiorna la marca temporale. Lo statfile predefinito è .stat ed è memorizzato nella directory principale dei documenti. Dispatcher blocca l’accesso allo statfile.

Distribuzione di documenti obsoleti in caso di errori serving-stale-documents-when-errors-occur

La proprietà /serveStaleOnError definisce se Dispatcher deve restituire i documenti invalidati quando il server di rendering restituisce un errore. Per impostazione predefinita, quando uno statfile viene toccato e invalida il contenuto memorizzato nella cache, Dispatcher elimina tale contenuto. Questa azione viene eseguita la volta successiva che sarà richiesta.

Se /serveStaleOnError è impostato su "1", Dispatcher non elimina dalla cache il contenuto invalidato. Ovvero, a meno che il server di rendering non restituisca una risposta positiva. Una risposta 5xx da AEM o un timeout della connessione fa in modo che Dispatcher distribuisca il contenuto obsoleto e risponda con lo stato HTTP 111 (riconvalida non riuscita).

Caching nel momento in cui viene utilizzata l’autenticazione caching-when-authentication-is-used

La proprietà /allowAuthorized definisce se le richieste che contengono una delle seguenti informazioni di autenticazione devono essere memorizzate in cache:

Per impostazione predefinita, le richieste che includono queste informazioni di autenticazione non vengono memorizzate in cache, perché l’autenticazione non viene eseguita quando un documento memorizzato in cache viene restituito al client. Questa configurazione impedisce a Dispatcher di distribuire i documenti memorizzati in cache a utenti che non dispongono dei diritti necessari.

Tuttavia, se i tuoi requisiti consentono la memorizzazione in cache dei documenti autenticati, imposta /allowAuthorized su uno:

/allowAuthorized "1"

Specifica dei documenti da memorizzare in cache specifying-the-documents-to-cache

La proprietà /rules definisce quali documenti vengono memorizzati in cache in base al percorso del documento. Indipendentemente dalla proprietà /rules, Dispatcher non memorizza mai in cache un documento nelle seguenti circostanze:

Ciascun elemento della proprietà /rules include un modello glob e un tipo:

Se non hai pagine dinamiche (oltre a quelle già escluse dalle regole di cui sopra), puoi configurare Dispatcher per memorizzare tutto in cache. La sezione delle regole si presenta così:

/rules
  {
    /0000  {  /glob "*"   /type "allow" }
  }

Per informazioni sulle proprietà glob, consulta Progettazione di pattern per le proprietà glob.

Se alcune sezioni della pagina sono dinamiche (ad esempio, un’applicazione di notizie) o all’interno di un gruppo di utenti chiuso, puoi definire le eccezioni:

/rules
  {
   /0000  { /glob "*" /type "allow" }
   /0001  { /glob "/en/news/*" /type "deny" }
   /0002  { /glob "*/private/*" /type "deny"  }
  }

Compressione

Sui server web Apache è possibile comprimere i documenti memorizzati in cache. La compressione consente ad Apache di restituire il documento in formato compresso, se richiesto dal client. La compressione viene eseguita automaticamente abilitando il modulo Apache mod_deflate, ad esempio:

AddOutputFilterByType DEFLATE text/plain

Il modulo è installato per impostazione predefinita con Apache 2.x.

Annullamento della validità dei file per livello di cartella invalidating-files-by-folder-level

Utilizza la proprietà /statfileslevel per annullare la validità dei file memorizzati in cache in base al loro percorso:

Sono interessate solo le risorse lungo il percorso del file invalidato. Prendi in considerazione l’esempio seguente: un sito web utilizza la struttura /content/myWebsite/xx/.. Se imposti statfileslevel su 3, viene creato un file .stat come segue:

Quando un file in /content/myWebsite/xx viene invalidato, viene toccato ogni file .stat a partire dalla docroot in giù fino a /content/myWebsite/xx. Questo vale solo per /content/myWebsite/xx e non per, ad esempio, /content/myWebsite/yy oppure /content/anotherWebSite.

Annullamento automatico della validità dei file memorizzati in cache automatically-invalidating-cached-files

La proprietà /invalidate definisce i documenti che vengono invalidati automaticamente quando il contenuto viene aggiornato.

Con l’annullamento automatico della validità, Dispatcher non elimina i file memorizzati in cache dopo un aggiornamento del contenuto, ma ne verifica la validità quando vengono successivamente richiesti. I documenti nella cache che non vengono invalidati automaticamente rimarranno nella cache fino a quando un aggiornamento del contenuto non li eliminerà esplicitamente.

L’annullamento automatico della validità viene in genere utilizzato per le pagine HTML. Le pagine HTML spesso contengono collegamenti ad altre pagine, rendendo difficile stabilire se un aggiornamento del contenuto influisce su una determinata pagina. Per fare in modo che tutte le pagine pertinenti vengano invalidate quando il contenuto viene aggiornato, conviene invalidare automaticamente tutte le pagine HTML. La configurazione che segue invalida tutte le pagine HTML:

  /invalidate
  {
   /0000  { /glob "*" /type "deny" }
   /0001  { /glob "*.html" /type "allow" }
  }

Per informazioni sulle proprietà glob, consulta Progettazione di pattern per le proprietà glob.

Questa configurazione causa la seguente attività quando /content/wknd/us/en è attivato:

Se offri file PDF e ZIP generati automaticamente per il download, potresti dover annullare automaticamente anche questi file. Esempio di configurazione:

/invalidate
  {
   /0000 { /glob "*" /type "deny" }
   /0001 { /glob "*.html" /type "allow" }
   /0002 { /glob "*.zip" /type "allow" }
   /0003 { /glob "*.pdf" /type "allow" }
  }

L’integrazione AEM con Adobe Analytics fornisce i dati di configurazione in un file analytics.sitecatalyst.js del sito web. Il file di esempio dispatcher.any fornito con Dispatcher include la seguente regola di invalidazione per questo file:

{
   /glob "*/analytics.sitecatalyst.js"  /type "allow"
}

Utilizzo di script di invalidazione personalizzati using-custom-invalidation-scripts

La proprietà /invalidateHandler ti consente di definire uno script che viene richiamato per ogni richiesta di invalidazione ricevuta da Dispatcher.

Lo script viene richiamato con i seguenti argomenti:

Questo metodo può essere utilizzato per coprire diversi casi d’uso. Ad esempio, l’annullamento della validità di altre cache specifiche per l’applicazione o la gestione di casi in cui l’URL esternalizzato di una pagina e la sua posizione nella docroot non corrispondono al percorso del contenuto.

Il seguente esempio di script registra in un file ogni richiesta di annullamento della validità.

/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"

Esempio di script dell’handler di annullamento della validità sample-invalidation-handler-script

#!/bin/bash

printf "%-15s: %s %s" $1 $2 $3>> /opt/dispatcher/logs/invalidate.log

Limitazione dei client che possono effettuare il flushing della cache limiting-the-clients-that-can-flush-the-cache

La proprietà /allowedClients definisce client specifici che sono autorizzati a effettuare il flushing della cache. I modelli globbing vengono confrontati con l’IP.

Il seguente esempio:

/allowedClients
  {
   /0001 { /glob "*.*.*.*"  /type "deny" }
   /0002 { /glob "127.0.0.1" /type "allow" }
  }

Per informazioni sulle proprietà glob, consulta Progettazione di modelli per le proprietà glob.

Ignorare i parametri URL ignoring-url-parameters

La sezione ignoreUrlParams definisce quali parametri URL vengono ignorati quando si stabilisce se una pagina viene memorizzata in cache o viene distribuita dalla cache:

Quando un parametro viene ignorato per una pagina, questa pagine viene memorizzata in cache la prima volta che viene richiesta. Alle successive richieste per quella pagina viene distribuita la pagina dalla cache, indipendentemente dal valore del parametro nella richiesta.

Per specificare quali parametri ignorare, aggiungi regole glob alla proprietà ignoreUrlParams:

Il codice di esempio seguente fa sì che Dispatcher ignori tutti i parametri, tranne il parametro nocache. Dispatcher non memorizza mai in cache gli URL di richiesta che includono il parametro nocache:

/ignoreUrlParams
{
    # ignore-all-url-parameters-by-dispatcher-and-requests-are-cached
    /0001 { /glob "*" /type "allow" }
    # allow-the-url-parameter-nocache-to-bypass-dispatcher-on-every-request
    /0002 { /glob "nocache" /type "deny" }
}

Nell’esempio della configurazione di ignoreUrlParams precedente, la seguente richiesta HTTP causa la memorizzazione nella cache della pagina perché il parametro willbecached viene ignorato:

GET /mypage.html?willbecached=true

Nell’esempio della configurazione ignoreUrlParams, la seguente richiesta HTTP fa in modo che la pagina non venga memorizzata nella cache, perché il parametro nocache non viene ignorato:

GET /mypage.html?nocache=true
GET /mypage.html?nocache=true&willbecached=true

Per informazioni sulle proprietà glob, consulta Progettazione di modelli per le proprietà glob.

Memorizzazione in cache delle intestazioni di risposta HTTP caching-http-response-headers

La proprietà /headers ti consente di definire i tipi di intestazione HTTP che Dispatcher memorizzerà in cache. Alla prima richiesta di una risorsa non memorizzata in cache, tutte le intestazioni che corrispondono a uno dei valori configurati (vedi l’esempio di configurazione sotto riportato) vengono memorizzate in un file separato, accanto al file della cache. Alle successive richieste della risorsa memorizzata in cache, le intestazioni memorizzate vengono aggiunte alla risposta.

Di seguito è riportato un esempio di configurazione predefinita:

/cache {
  ...
  /headers {
    "Cache-Control"
    "Content-Disposition"
    "Content-Type"
    "Expires"
    "Last-Modified"
    "X-Content-Type-Options"
    "Last-Modified"
  }
}

FileETag none

Autorizzazioni per i file della cache di Dispatcher dispatcher-cache-file-permissions

La proprietà mode specifica quali autorizzazioni di file vengono applicate alle nuove directory e ai nuovi file nella cache. Il umask del processo chiamante limita questa impostazione. Si tratta di un numero ottale costruito dalla somma di uno o più dei seguenti valori:

Il valore predefinito è 0755 e consente al proprietario di leggere, scrivere o eseguire ricerche, e al gruppo e altri utenti di leggere o eseguire ricerche.

Limitazione del tocco del file .stat throttling-stat-file-touching

Con la proprietà /invalidate predefinita, ogni attivazione invalida efficacemente tutti i file .html (quando il loro percorso corrisponde alla sezione /invalidate). Su un sito web con un traffico considerevole, le attivazioni multiple e successive aumentano il carico della CPU sul back-end. In questo caso, è auspicabile limitare il numero di interventi sul file .stat in modo da mantenere il sito web più reattivo. A tale scopo, utilizza la proprietà /gracePeriod.

La proprietà /gracePeriod definisce il numero di secondi in cui una risorsa obsoleta e invalidata automaticamente può ancora essere distribuita dalla cache dopo l’ultima attivazione. La proprietà può essere utilizzata in una configurazione in cui, altrimenti, un batch di attivazioni annullerebbe ripetutamente l’intera cache. Il valore consigliato è 2 secondi.

Per ulteriori dettagli, consulta prima /invalidate e /statfileslevel.

Configurazione dell’annullamento della validità della cache basata sul tempo: /enableTTL configuring-time-based-cache-invalidation-enablettl

L’annullamento della validità della cache basato sul tempo dipende dalla proprietà /enableTTL e dalla presenza di intestazioni di scadenza regolari dello standard HTTP. Se imposti la proprietà su 1 (/enableTTL "1"), vengono valutate le intestazioni di risposta dal back-end. Se le intestazioni contengono una data Cache-Control, max-age o Expires, viene creato un file ausiliario vuoto accanto a quello della cache, con un tempo di modifica uguale alla data di scadenza. Quando il file memorizzato nella cache viene richiesto oltre il tempo di modifica, viene automaticamente richiesto nuovamente dal back-end.

Prima della versione 4.3.5 di Dispatcher, la logica di annullamento della validità TTL si basava solo sul valore TTL configurato. Con Dispatcher 4.3.5, vengono presi in considerazione sia il valore TTL impostato sia le regole di annullamento della validità della cache di Dispatcher. Di conseguenza, per un file memorizzato in cache:

Questa nuova implementazione supporta i casi d’uso in cui i file hanno un TTL più lungo (ad esempio, sulla CDN). Tuttavia, tali file possono ancora essere invalidati anche se il TTL non è scaduto. Ciò favorisce l’aggiornamento dei contenuti rispetto al rapporto cache-hit in Dispatcher.

Se invece vuoi applicare a un file solo la logica di scadenza, imposta /enableTTL su 1 ed escludi tale file dal meccanismo standard di annullamento della validità della cache. Ad esempio:

  /invalidate
  {
   /0000  { /glob "*" /type "deny" }
   /0001  { /glob "*.html" /type "allow" }
   /0002  { /glob "*.example.html" /type "deny" }
  }

In tal modo non verrà utilizzato l’annullamento della validità del file .stat e per i file specificati sarà attiva solo la scadenza TTL.

Configurazione del bilanciamento del carico: /statistics configuring-load-balancing-statistics

La sezione /statistics definisce categorie di file per i quali Dispatcher valuta la reattività di ciascun rendering. Dispatcher utilizza i punteggi per determinare a quale rendering inviare una richiesta.

Ogni categoria creata definisce un modello glob. Dispatcher confronta l’URI del contenuto richiesto con questi modelli per determinare la categoria del contenuto richiesto:

Dispatcher supporta un massimo di otto categorie di statistiche. Se definisci più di otto categorie, vengono utilizzate solo le prime otto.

Selezione rendering

Ogni volta che Dispatcher richiede una pagina sottoposta a rendering, utilizza il seguente algoritmo per selezionare il motore di rendering:

Il punteggio per la categoria di un rendering si basa sui tempi di risposta precedenti, nonché sui precedenti tentativi di connessioni non riusciti e riusciti effettuati da Dispatcher. Per ogni tentativo, viene aggiornato il punteggio per la categoria dell’URI richiesto.

Definizione delle categorie di statistiche defining-statistics-categories

Definire una categoria per ciascun tipo di documento del quale vuoi conservare le statistiche per la selezione del rendering. La sezione /statistics contiene una sezione /categories. Per definire una categoria, aggiungi una riga sotto la sezione /categories con il seguente formato:

/name { /glob "pattern"}

Il nome della categoria (name) deve essere univoco per la farm. La sezione pattern è descritta nella sezione Progettazione di modelli per le proprietà glob.

Per determinare la categoria di un URI, Dispatcher lo confronta con ciascun modello di categoria fino a quando non trova una corrispondenza. Dispatcher inizia con la prima categoria dell’elenco e continua seguendo l’ordine. Quindi, inserisci prima le categorie con i modelli più specifici.

Ad esempio, il file predefinito di Dispatcher dispatcher.any definisce una categoria HTML e anche un’altra categoria. Tuttavia, la categoria HTML è più specifica e quindi viene visualizzata prima:

/statistics
  {
  /categories
    {
      /html { /glob "*.html" }
      /others  { /glob "*" }
    }
  }

L’esempio che segue include anche una categoria per le pagine di ricerca:

/statistics
  {
  /categories
    {
      /search { /glob "*search.html" }
      /html { /glob "*.html" }
      /others  { /glob "*" }
    }
  }

Indisponibilità del server riflessa nelle statistiche di Dispatcher reflecting-server-unavailability-in-dispatcher-statistics

La proprietà /unavailablePenalty imposta il tempo (in decimi di secondo) applicato alle statistiche di rendering quando una connessione al rendering non riesce. Dispatcher aggiunge il tempo alla categoria di statistiche corrispondente all’URI richiesto.

Ad esempio, la penale viene applicata quando non è possibile stabilire la connessione TCP/IP al nome host/porta designato. Il motivo è che AEM non è in esecuzione (e non è in ascolto) o si è verificato un problema relativo alla rete.

La proprietà /unavailablePenalty è un figlio diretto della sezione /farm (un elemento di pari livello della sezione /statistics).

Se non esiste alcuna proprietà /unavailablePenalty, viene utilizzato il valore "1".

/unavailablePenalty "1"

Identificazione di una cartella di connessione permanente:/stickyConnectionsFor identifying-a-sticky-connection-folder-stickyconnectionsfor

La proprietà /stickyConnectionsFor definisce una cartella contenente documenti permanenti. Questa proprietà è accessibile tramite l’URL. Dispatcher invia alla stessa istanza di rendering tutte le richieste provenienti da un singolo utente che sono in questa cartella. Le connessioni permanenti garantiscono la presenza e la coerenza dei dati della sessione per tutti i documenti. Questo meccanismo utilizza il cookie renderid.

L’esempio che segue definisce una connessione fissa alla cartella /products:

/stickyConnectionsFor "/products"

Quando una pagina è composta da contenuto proveniente da più nodi di contenuto, includi la proprietà /paths che elenca i percorsi del contenuto. Ad esempio, una pagina include il contenuto di /content/image, /content/video e /var/files/pdfs. La seguente configurazione abilita connessioni permanenti per tutto il contenuto della pagina:

/stickyConnections {
  /paths {
    "/content/image"
    "/content/video"
    "/var/files/pdfs"
  }
}

httpOnly httponly

Quando le connessioni permanenti sono abilitate, il modulo Dispatcher imposta il cookie renderid. Questo cookie non ha il flag httponly, che però deve essere aggiunto per rafforzare la sicurezza. È possibile aggiungere il flag httponly impostando la proprietà httpOnly nel nodo /stickyConnections di un file di configurazione dispatcher.any. Il valore della proprietà (0 oppure 1) definisce se al cookie renderid viene aggiunto l’attributo HttpOnly. Il valore predefinito è 0, il che significa che l’attributo non viene aggiunto.

Per ulteriori informazioni sul flag httponly, leggi questa pagina.

secure secure

Quando le connessioni permanenti sono abilitate, il modulo Dispatcher imposta il cookie renderid. Questo cookie non ha il flag secure, che deve essere aggiunto per migliorare la sicurezza. Per aggiungere il flag secure, imposta la proprietà secure nel nodo /stickyConnections di un file di configurazione dispatcher.any. Il valore della proprietà (0 oppure 1) definisce se al cookie renderid viene aggiunto l’attributo secure. Il valore predefinito è 0, il che significa che l’attributo viene aggiunto se la richiesta in ingresso è sicura. Se il valore è impostato su 1, il flag secure viene aggiunto indipendentemente dal fatto che la richiesta in ingresso sia sicura o meno.

Gestione degli errori di connessione del rendering handling-render-connection-errors

Configura il comportamento di Dispatcher quando il server di rendering restituisce l’errore 500 o non è disponibile.

Specifica di una pagina di verifica dello stato di integrità specifying-a-health-check-page

Utilizzare la proprietà /health_check per specificare un URL che viene verificato quando viene restituito il codice di stato 500. Se anche questa pagina restituisce il codice di stato 500, l’istanza viene considerata non disponibile e, prima di un nuovo tentativo, al rendering viene applicata una penalità di tempo configurabile ( /unavailablePenalty).

/health_check
  {
  # Page gets contacted when an instance returns a 500
  /url "/health_check.html"
  }

Specifica del ritardo prima di un nuovo tentativo di richiedere una pagina specifying-the-page-retry-delay

La proprietà /retryDelay imposta il tempo (in secondi) che Dispatcher deve attendere prima di ogni successivo turno di tentativi di connessione con i rendering nella farm. Per ogni turno, il numero massimo di tentativi di Dispatcher di connettersi a un motore di rendering è pari al numero di rendering nella farm.

Dispatcher utilizza il valore "1", se /retryDelay non è definito in modo esplicito. Il valore predefinito è solitamente appropriato.

/retryDelay "1"

Configurazione del numero di tentativi configuring-the-number-of-retries

La proprietà /numberOfRetries imposta il numero massimo di turni di tentativi di connessione ai rendering effettuati da Dispatcher. Se Dispatcher non riesce a connettersi a un rendering dopo questo numero di tentativi, restituisce una risposta di esito negativo.

Per ogni turno, il numero massimo di tentativi di Dispatcher di connettersi a un motore di rendering è pari al numero di rendering nella farm. Pertanto, il numero massimo di tentativi di connessione da parte di Dispatcher è (/numberOfRetries) x (il numero di rendering).

Se il valore non è definito in modo esplicito, il valore predefinito è 5.

/numberOfRetries "5"

Utilizzo del meccanismo di failover using-the-failover-mechanism

Per inviare nuovamente le richieste a rendering diversi quando la richiesta originale non riesce, abilita il meccanismo di failover nella farm di Dispatcher. Quando il failover è abilitato, Dispatcher si comporta come segue:

Per abilitare il failover, aggiungi la seguente riga alla farm (o al sito web):

/failover "1"

Ignorare gli errori di interruzione: /ignoreEINTR ignoring-interruption-errors-ignoreeintr

Qualsiasi chiamata di sistema orientata al file system può essere interrotta EINTR se l’oggetto della chiamata di sistema si trova su un sistema remoto accessibile tramite NFS. Se queste chiamate di sistema possono andare in timeout o essere interrotte dipende da come il file system sottostante è stato installato sul computer locale.

Usa il parametro /ignoreEINTR, se la tua istanza ha questa configurazione e il registro contiene il seguente messaggio:

Error while reading response: Interrupted system call

Internamente, Dispatcher legge la risposta dal server remoto (cioè, da AEM) utilizzando un loop che può essere rappresentato come:

while (response not finished) {
read more data
}

Questi messaggi possono essere generati quando EINTR si verifica nella sezione read more data. La causa risiede nella ricezione di un segnale prima della ricezione dei dati.

Per ignorare queste interruzioni, puoi aggiungere il seguente parametro a dispatcher.any (prima di /farms):

/ignoreEINTR "1"

Se si imposta /ignoreEINTR su "1", Dispatcher continua a tentare di leggere i dati fino a quando non viene letta la risposta completa. Il valore predefinito è 0 e disattiva l’opzione.

Progettazione di modelli per le proprietà glob designing-patterns-for-glob-properties

Diverse sezioni nel file di configurazione di Dispatcher utilizzano le proprietà glob come criteri di selezione per le richieste client. I valori delle proprietà glob sono modelli che Dispatcher confronta con un aspetto della richiesta, ad esempio il percorso della risorsa richiesta o l’indirizzo IP del client. Ad esempio, gli elementi nella sezione /filter utilizzano i modelli glob per identificare i percorsi delle pagine su cui Dispatcher agisce o che rifiuta.

I valori glob possono includere caratteri jolly e caratteri alfanumerici per definire il modello.

Registrazione logging

Nella configurazione del server Web, puoi impostare:

Per ulteriori informazioni, vedi la documentazione del server web e il file readme dell’istanza di Dispatcher.

Rotazione o piping dei registri di Apache

Se utilizzi un server web Apache, puoi utilizzare la funzionalità standard per la rotazione e/o il piping dei registri oppure entrambe. Ad esempio, utilizzando piping dei registri:

DispatcherLog "| /usr/apache/bin/rotatelogs logs/dispatcher.log%Y%m%d 604800"

Questa funzionalità ruota automaticamente:

Consulta la documentazione del server web di Apache sulla rotazione e il piping dei registri. Ad esempio: Apache 2.4.

Registrazione della traccia trace-logging

Tra gli altri miglioramenti apportati a Dispatcher, la versione 4.2.0 introduce anche la funzione Registrazione della traccia.

Si tratta di un livello più alto della registrazione di debug, in quanto mostra informazioni aggiuntive nei registri. La registrazione ora include:

Puoi abilitare la funzione di registrazione della traccia impostando il livello di registro su 4 nel server web.

Di seguito è riportato un esempio di registri con tracciamento abilitato:

[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Host] = "localhost:8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[User-Agent] = "curl/7.43.0"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Accept] = "*/*"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Client-Cert] = "(null)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Via] = "1.1 localhost:8443 (dispatcher)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-For] = "::1"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL] = "on"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Cipher] = "DHE-RSA-AES256-SHA"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Session-ID] = "ba931f5e4925c2dde572d766fdd436375e15a0fd24577b91f4a4d51232a934ae"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-Port] = "8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Server-Agent] = "Communique-Dispatcher"

E un evento è registrato quando viene richiesto un file che corrisponde a una regola di blocco:

[Thu Mar 03 14:42:45 2016] [T] [11831] 'GET /content.infinity.json HTTP/1.1' was blocked because of /0082

Verifica del funzionamento di base confirming-basic-operation

Per verificare il funzionamento e l’interazione di base del server web, di Dispatcher e dell’istanza di AEM, procedi come segue:

Utilizzo di più istanze di Dispatcher using-multiple-dispatchers

In configurazioni complesse è possibile utilizzare più istanze di Dispatcher. Ad esempio, puoi utilizzare:

In questo caso, accertati che ogni richiesta venga gestita tramite un’unica istanza di Dispatcher. Un’istanza di Dispatcher non gestisce le richieste provenienti da un’altra istanza di Dispatcher. Accertati pertanto che entrambe le istanze di Dispatcher accedano direttamente al sito web di AEM.

Debugging debugging

Quando si aggiunge l’intestazione X-Dispatcher-Info a una richiesta, Dispatcher risponde indicando se la destinazione è stata memorizzata in cache, restituita dalla cache o non è memorizzabile in cache. L’intestazione di risposta X-Cache-Info contiene queste informazioni in un formato leggibile. Puoi utilizzare queste intestazioni di risposta per eseguire il debug dei problemi relativi alle risposte memorizzate in cache da Dispatcher.

Questa funzionalità non è abilitata per impostazione predefinita, pertanto affinché l’intestazione di risposta X-Cache-Info sia inclusa, la farm deve contenere la seguente voce:

/info "1"

Ad esempio:

/farm
{
    /mywebsite
    {
        # Include X-Cache-Info response header if X-Dispatcher-Info is in request header
        /info "1"
    }
}

Inoltre, l’intestazione X-Dispatcher-Info non ha bisogno di un valore, ma se utilizzi curl per il test devi fornire un valore per poter inviare l’intestazione, ad esempio:

curl -v -H "X-Dispatcher-Info: true" https://localhost/content/wknd/us/en.html

Di seguito è riportato un elenco contenente le intestazioni di risposta che X-Dispatcher-Info restituirà: