NGINX: pagine d'errore e codici di stato HTTP

Vediamo come gestire in NGINX le pagine d'errore e come utilizzare i codici di stato HTTP per fornire risposte personalizzate a richieste particolari

Pagine d'errore

Quando mettiamo online un portale, o anche un semplice sito in HTML statico, è buona norma gestire correttamente le pagine d'errore, in modo da non visualizzare quelle standard di NGINX o del CMS in uso.

Nella configurazione del virtual host, aggiungiamo la direttiva error_page con l'errore da gestire e la location a cui far riferimento. Di seguito uno snippet:

 

location ^~ / {
error_page 404 = /404.html;
error_page 500 502 503 = @50x;
index index.html;
root /path/to/web/site;
}

Come è possibile notare, nel file di configurazione ci sono due direttive diverse per gestire l'errore 404 file not found e gli errori 50x e le relative location richiamate in modo diverso.

La pagina 404.html è, per come è riportato nell'esempio, normalmente accessibile se nella barra degli indirizzi del browser andiamo su www.nomedominio.tld/404.html .

Invece, le location che hanno come prefisso una @ sono chiamate named location e non vengono invocate nella normale risoluzione di una richiesta, ma solamente se ci sono dei redirect interni.

Vediamo le location delle pagine d'errore come sono strutturate:

location ^~ /404.html {
root /path/to/error/page;
}

location @50x {
rewrite ^ http://500.nomedominio.tld break;
}

Con questa configurazione, in caso di errore 404 verrà visualizzata la pagina 404.html, mentre in caso di errore 500, 502 e 503 avremo un reindirizzamento ad un sottodominio che andrà correttamente configurato.

Per quanto riguarda i portali Plone, è utile configurare esclusivamente gli errori 50x perché il CMS è in grado di gestire correttamente gli altri tipi di errore; in questo caso, effettuando nella location / un reindirizzamento di tipo proxy_pass, è necessario abilitare anche la direttiva proxy_intercept_errors nel contesto server, come visualizzato di seguito:

server {
...
server_name www.nomedominio.tld;
...
proxy_intercept_errors on;

location ^~ /{

Le pagine di errore 404, invece, vengono configurate per quelle risorse da esporre staticamente o nel caso in cui il CMS (o l'applicazione dedicata) non sia in grado di gestire correttamente questo tipo di errori.

Codici di stato HTTP

In alcuni casi può essere molto utile fare in modo che a determinate richieste vengano fornite risposte con uno status code particolare.

Questo tipo di configurazione è indicata quando è necessario effettuare un redirect di un dominio verso un altro istruendo i motori di ricerca, oppure per bloccare richieste verso risorse che sicuramente non esistono.

Per effettuare questa configurazione, viene utilizzata la direttiva return associata al codice HTTP relativo, come nel seguente stralcio di codice:

server {
...
server_name www.dominiosecondario.tld;
...
return 301 http://www.dominioprincipale.tld;
}

Lo snippet appena mostrato pemette di dare ai client che richiedono www.dominiosecondario.tld una risposta HTTP di tipo 301 Moved permanently effettuando un redirect verso la URL www.dominioprincipale.tld, indicando ai motori di ricerca di indicizzare i contenuti sul nuovo dominio.

Per bloccare alcuni tipi di richieste particolari, invece, si utilizza un altro tipo di configurazione, come riportato di seguito:

location ^~ \.(aspx|php|jsp)$ {
return 410;
}

In questo modo, ai client che richiedono URL con estensioni .aspx, .php, .jsp si risponde con un codice 410 Gone che indica una risorsa che intenzionalmente non è più disponibile e, nel caso dei motori di ricerca, di non effettuare nuovamente la stessa richiesta.

Link

NGINX: location

NGINX: direttiva error_page

NGINX: direttiva return

Google WebmasterTools: Reindirizzamenti 301

Google WebmasterTools: codici di stato HTTP

Share this on

Share |

On same topics

Commenti

comments powered by Disqus