Guida pratica al file di configurazione .htaccess

Guida pratica al file di configurazione .htaccess

Qualsiasi sito che funzioni mediante Apache server (quindi ad esempio Joomla! o WordPress) necessiterà della configurazione del file  delle direttive, che è noto come htaccess ed è un file di testo che si può editare, riga per riga, con un editor qualsiasi in locale oppure via FTP oppure SSH per i siti già online.

Come fare queste modifiche? In questa nuova guida ho riassunto tutto quello che bisogna sapere per non farsi cogliere impreparati, e configurare il necessario. In questo modo, in alcuni casi, riuscirete anche a migliorare le prestazioni di velocità del nostro sito in termini di GTMetrix, PingDom Tools e (in alcuni casi) Google Insights. Le prestazioni ovviamente non dipenderanno solo da questo: ci sono tanti altri aspetti che influenzano la velocità, e a quanto pare il nuovo tool per la velocità delle pagine è più condizionato dalla struttura e dalle dimensioni dell’HTML e del CSS / JS che sono generati dalla pagina che da altro, ed in questo il file htaccess non c’entra nulla. Pero’, ovviamente, una buona impostazione di questo file delle direttive riesce a fornire un miglioramento concreto al nostro sito e lo mette nelle condizioni di funzionare al meglio.

Cos’è il file .htaccess

Partiamo dall’inizio e cerchiamo di capire bene cosa sia un file .htaccess, che ha senso e funziona solo se scritto in questo modo e se c’è un server Apache che fa funzionare il sito. Il file .htaccess, nello specifico, è un file di configurazione (di Apache) in formato testo ed organizzato per righe, che permette di definire le “regole” specifiche che il sito dovrà rispettare. Questo tipo di file può essere utilizzato, ad esempio, per impostare un reindirizzamento o redirect, impostare gli URL SEO-friendly o “parlanti”, impostare la durata della cache, proteggere l’accesso a una cartella tramite username e password, e così via.

Si tratta di un file di configurazione del sito o, più precisamente, di direttive di testo; è editabile con un qualsiasi editor e contiene le “indicazioni tecniche” che il server dovrà eseguire. Come detto, quindi, un file .htaccess permette di impostare svariati aspetti sul comportamento del sito web, come ad esempio la definizione di URL SEO friendly, la protezione di directory del sito sensibili, la possibilità di scansionare o meno tutti gli URL da parte di utenti e motori di ricerca, il caching delle pagine e così via.

.htaccess (scritto tutto in minuscolo) è l’acronimo HyperText ACCESS, è un file di configurazione del webserver Apache che una volta “letto” da Apache è in grado di controllarne alcune funzioni. Ogni sito può avere anche più di un file .htaccess, quindi abbiamo quello principale e poi quelli nelle sottodirectory che vengono letti da Apache, uno per uno, ogni volta che proviamo ad aprire un percorso URL (una pagina oppure una directory). Se questo aspetto garantisce di suo massima scalabilità al sistema, è per certi versi anche un limite di Apache – come evidenziato ad esempio dal creatore di NGINX, che è un server alternativo ad Apache – che pone molta importanza sui file .htaccess come indice di potenziale degrado delle prestazioni, in alcuni casi, lato Apache. Ad ogni modo si tratta di uno dei server più usati al mondo, ed è comunque opportuno valutare la possibilità che sia configurato male anche perchè, ad esempio, ci sono molti plugin come quelli di cache del sito che tendono a modificarlo in automatico, e questo porta al problema del bloatware: potreste ritrovarvi nel vostro file varie direttive che sono state inserite da plugin analoghi e che non ricordate di aver inserito a mano.

Pertanto pianificare una “pulizia” periodica del file .htaccess è buona norma se si sa quello che si sta facendo, anche perchè non è difficile immagine che un file .htaccess più grande del necessario possa creare qualche problema di prestazioni ad alcuni siti in termini di TTFB.

Cosa indica il punto (.) davanti al nome del file?

Il fatto che ci sia un punto davanti indica che si tratta di un file nascosto, per cui non sarà visibile pubblicamente. Per accedervi è solitamente necessario un client FTP gratuito come ad es. FileZilla. I file nascosti mediante punto prefisso potrebbero non essere visibili da Windows o Mac, ma sono in genere visibili come tutti gli altri mediante FileZilla e simili.

Quali permessi CHMOD deve avere il .HTACCESS?

Visto che si tratta di un file che il sistema deve leggere, dobbiamo impostare i permessi di lettura come si deve, altrimenti il server finirà per generare un errore di tipo 500, e renderà impossibile operare e vedere correttamente il sito. Il file .htaccess dovrà avere permessi di tipo 644, ovvero permesso di lettura per tutti e di scrittura solo per l’utente Linux proprietario.

Chiarito questo, procediamo nel vedere un po’ di esempi utili, visto che il modo migliore per capire come funziona non è tanto leggersi la documentazione ufficiale quanto ragionare per casi reali pratici.

htaccess e WordPress

Chi lavora con i siti web e con i vari CMS come WordPress, si sarà sicuramente trovato di fronte ad un file di questo tipo, solitamente scontrandosi con la difficoltà oggettiva della sua sintassi. Anche se può risultare all’apparenza un semplice file di testo, in realtà può rivelarsi fondamentale per attivare o disattivare alcune funzioni. Se ci sono degli errori di digitazione o sintassi nel file .htaccess, il sito restituirà un errore 500 (o altri di classe 5xx, tutti gli errori server che iniziano con il numero 5) su tutte le pagine del sito, che quindi smetterà di funzionare. Facciamo quindi sempre molta attenzione alle modifiche che andiamo ad effettuare.

Inoltre bisogna considerare che viene letto nell’ordine in cui è stato scritto, quindi la posizione e l’ordine delle direttive ha importanza e se sbagliate anche solo l’ordine in cui inserite le nuove o togliete le vecchie potreste generare:

  • errori 500 nel sito;
  • loop di reindirizzamento;
  • problemi con la gestione dei cookie che non verranno accettati.

Quello di .htaccess non è, poi, codice vero e proprio, bensì direttive rivolte al server. Questo significa che, prima ancora di eseguire qualsiasi comando nel codice del sito, il server sarà obbligato a rispettare le indicazioni contenute in questo tipo di file.

Come disattivare il file .htaccess

Per disattivare il file .htaccess il modo più semplice è quello di rinominarlo, quindi ad esempio htaccess.txt. Facendo così le direttive saranno completamente ignorate, il che è utile per sbloccare siti con errori ed in generale in fase di manutenzione o debug del sito.

.htaccess a livello operativo

Per intervenire su un file .htaccess è necessario:

  1. creare un file di testo .htaccess (se già non esiste) nella cartella root del sito (vedi punto 4), facendo attenzione ad inserire il punto davanti all’estensione (in modo che venga interpretato dal sistema come file nascosto; un file htaccess senza punto davanti verrebbe ignorato da Apache);
  2. inserire le righe che desiderate testare.
  3. Alla fine, salvate i cambiamenti sul file .htaccess.
  4. Caricate le modifiche del file nel path della root, che a seconda dei servizi di hosting può essere: /home/nomeaccount/ oppure /home/nomeaccount/public_html oppure, ancora, /www/ o /public_html/)

Schermata 2013-06-17 alle 17.42.58

Esempi base di configurazione .htaccess

Vediamo alcuni esempi delle configurazioni più comuni di questo file di direttive.

Redirect 301 di un’intera cartella su una alternativa, sempre sullo stesso sito.

Options +FollowSymLinks %% solo se avete attivato il mod_rewrite
RewriteEngine On
RewriteRule ^uno.*$ http://nomesito.com/due/ [R=301,L]

Redirect 301 di tutti i file nella cartella uno verso la cartella due.

Options +FollowSymLinks %%richiesto dal mod_rewrite
RewriteEngine On
RewriteRule ^uno/(.*)$ http://nomesito.com/due/$1 [R=301,L]

Redirect di file.php verso due/file.php

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} nomesito.com$ [NC]
RewriteCond %{HTTP_HOST} !due
RewriteRule ^(.*)$ http://nomesito.com/due/$1 [R=301,L]

Redirect 301 della root (miosito.it) su una sottocartella (miosito.it/cartella)

 RewriteEngine On
 RewriteCond %{HTTP_HOST} ^(www.)?miosito.it$
 RewriteRule ^(/)?$ cartella [L]

Redirect di tutti i file e le cartelle da versione www.nomesito.com verso nomesito.com

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^nomesito.com [NC]
RewriteRule ^(.*)$ http://www.nomesito.com/$1 [R=301,L]

Redirect da http://nomesito.com a https://nomesito.com (utile per le pagine di acquisto degli e-commerce e tutte quelle che utilizzino SSL)

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.nomesito.com/$1 [R,L]

Canonicalizzazione del dominio via .htaccess

Questo intervento serve a canonicalizzare il dominio del vostro sito, ed evitare che gli alias dello stesso vengano visti come siti differenti, il che creerebbe un problema di dispersione del traffico dai motori di ricerca ed indurrebbe una certa confusione negli utenti. Per fare in modo che le versioni alternative del vostro dominio sia viste come una cosa unica, ad esempio:

  1. http://www.nomesito.com
  2. http://nomesito.com>
  3. http://www.nomesito.com/index.html
  4. http://nomesito.com/index.html

sarà sufficente inserire le seguenti righe nelle direttive:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^nomesito.com
RewriteRule (.*) http://www.nomesito.com/$1 [R=301,L]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.html
RewriteRule ^index.html$ http://www.nomesito.com/ [R=301,L]

Impostare una pagina di errore 404 specifica

ErrorDocument 404 http://www.nomesito.com/404.php

Redirect 301 di singole pagine

redirect 301 /old-page.php http://www.nomesito.com/new-page.php

Supporto ad URL dinamici

Versione URL senza ?, quindi ad esempio

abc.php?id=76 -> abc/76 (utile ad es. per i cataloghi prodotti di alcuni e-commerce)

RewriteEngine on
RewriteRule ^abc/([^/.]+)/?$ abc.php?id=$1 [L]

Redirect 301 globale dominio vecchio.it -> nuovo.it

Da inserire nel file .htaccess del dominio vecchio.it:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !nuovo.it$ [NC]
RewriteRule ^(.*)$ http://www.nuovo.it/$1 [L,R=301]

Da caricare sulla root FTP di vecchio.it, non serve indicare il nome del dominio origine.

htaccess di default per WordPress: il modulo mod_rewrite

Una delle funzionalità più utilizzate è quella per gli URL di WordPress SEO-friendly, cioè la possibilità che gli URL di pagine del tipo:

tuosito.com/?p=676

siano “traducibili” in URL più significativi ed utili come:

tuosito.com/pagina_esempio

Ovviamente l’aver impostato gli URL SEO-friendly non garantisce nulla in termini di posizionamento, ma è comunque una cosa che è opportuno e comodo attivare sul vostro sito.

Il file .htaccess standard di WP è questo:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Per gestire in modo sicuro il file .htaccess del vostro sito, effettuare backup automatico ed avere una funzionalità di disaster recovery in caso di errori potete sfruttare un plugin gratuito come Htaccess Editor.

.htaccess standard per WordPress multi-sito

Su un WordPress multisite, la forma generica del file htaccess è invece un po’ più complessa.

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Come specificare le opzioni nel file .htaccess di WP

Le opzioni si scrivono così, come una riga (direttiva) in questo modo:

Options None

ovvero una direttiva Options seguita da un valore di parametro, che nello specifico è None e che significa “Disabilita tutte le opzioni“. In generale, potrebbe essere additivo o sottrattivo; rispettivamente, nel primo caso avremo un segno + oppure un segno – rispettivamente per aggiungere o togliere un’opzione.

Possibili valori delle Options sono i seguenti:

None
Tutte le opzioni disabilitate
All
Tutte le opzioni abilitate (valore di default)
ExecCGI
Abilita script CGI (normalmente non serve)
FollowSymLinks
Segui i link simbolici (serve su alcuni hosting)
Includes
Consenti inclusioni lato server di moduli aggiuntivi
IncludesNOEXEC
Consenti inclusioni lato server di moduli aggiuntivi in modo più restrittivo / sicuro
Indexes
Specifica mappa degli URL visibili

Ad esempio, di seguito disabilitiamo le opzioni principali ma ci limitiamo ad aggiungere la possibilità di seguire i link simbolici.

Options None
Options FollowSymLinks

Come specificare il file standard da aprire: DirectoryIndex

In linea di massima, questa direttiva è importante perchè specifica quale file verrà richiamato nel caso in cui un client vada ad aprire una directory: se in una directory ci sono due file, uno index.html e l’altro index.php ad esempio, mediante tale direttiva sarà possibile specificare la priorità nell’apertura (e “mascherare” l’estensione effettiva del file nella directory, per ragioni di sicurezza)

DirectoryIndex index.php index.html /index.php

Come abilitare la compressione HTTP delle pagine

Per ragioni di efficenza e velocità del sito web, si può pensare di abilitare la compressione HTTP; in questo caso basta utilizzare queste direttive.

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Caso ancora più comune, si può abilitare la compressione solo su alcuni tipi di file (per saperne di più sull’argomento trovate in questo portale, nella sezione Guide WordPress, una buona quantità di tutorial sull’ottimizzazione delle prestazioni di un sito in generale).

<FilesMatch “\.(js|css|txt|xml)$”> SetOutputFilter DEFLATE </FilesMatch>

Su alcuni server può anche funzionare una cosa del genere:

<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application$
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml applica$
AddOutputFilterByType DEFLATE text/javascript application/javascript applicat$
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
AddOutputFilterByType DEFLATE font/truetype font/opentype
</ifModule>

Come impostare SSL via .htaccess su WordPress

Per ragioni di sicurezza, ed avendo un certificato SSL acquistato e configurato, possiamo imporlo a WordPress. In questo caso è decisamente consigliato inserire un file .htaccess del genere NON nella root principale (molti siti, sbagliando a mio avviso, l’hanno fatto e continuano a farlo) bensì nella cartella wp-admin del vostro sito: in questo modo andrete a proteggere il login del vostro sito con HTTPS.

Attenzione: questa direttiva esegue un redirect automatico da HTTP a HTTPS, per cui presuppone che il certificato sia attivo, funzionante e correttamente rinnovato (cioè non sia scaduto).

RewriteEngine On
RewriteBase /

# abilita HTTPS
RewriteCond %{ENV:HTTPS} !=on
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

# BEGIN WordPress
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Mandare offline per manutenzione un sito via .htaccess

Il file di direttive di Apache htaccess può essere utilizzato per avviare una manutenzione controllata del vostro sito web, ed evitare che i vostri visitatori vedano eventuali pagine di errore mentre ci state lavorando. In questo caso si fa così:

# sito in manutenzione
<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REMOTE_ADDR} !^123\.456\.789\.000
 RewriteCond %{REQUEST_URI} !/maintenance.html$ [NC]
 RewriteCond %{REQUEST_URI} !\.(jpe?g?|png|gif) [NC]
 RewriteRule .* /maintenance.html [R=302,L]
</IfModule>

L’IP indicato nel formato regex 123\.456\.789\.000 potrebbe essere ad esempio il vostro IP, in modo tale che possiate operare sul sito vedendolo come se fosse online e nascondendolo a tutti gli altri utenti.

Notate inoltre che abbiamo impostato un redirect 302, quindi soltanto per gli utenti e non per i motori (in modo da non perdere l’indicizzazione ed il posizionamento regressi, almeno per qualche tempo). RIcordatevi di caricare nella root del sito anche il file HTML maintenance.html, che potete trovare qui, ad esempio.

Nel file .htaccess di manutenzione è possibile indicare un indirizzo IP da cui vedere il sito normalmente, mentre tutti gli altri non lo vedranno; questo IP potrebbe essere il vostro, ad esempio, in modo da permettervi di lavorare al sito mentre tutti gli altri visitatori vedranno “lavori in corso”; l’IP deve essere specificato come !^123\.456\.789\.123, quindi con i punti . classici sostituiti da \., e con i caratteri !^ all’inizio.

Nuovo hosting per il tuo sito?

Vuoi cambiare hosting e sfruttarne uno più performante?


Siteground è la scelta ideale: veloce, sicuro, semplice da gestire, assistenza 24/7!

Provalo adesso

Expires Headers in .htaccess: il modulo mod_expires

Questa sezione del tutorial cercherà di spiegare come si impostano gli header di scadenza (cosiddetti Expires headers) sfruttando apposite direttive nel file .htaccess, sulla base dei suggerimenti per migliorare le prestazioni del sito fornite usualmente dallo strumento Google PageSpeed Insights. Cercheremo quindi di capire cosa sia la cache del browser di una pagina web, come testare le performance del nostro sito e come aggiungere gli expires headers. Abbiamo discusso queste problematiche, in modo ancora più generale, in due post approfonditi qualche tempo fa (prima e seconda parte), per cui vi suggerisco di leggerli per avere una visione ancora più generale del problema.

Questo tipo di operazioni sono concesse esclusivamente su server Apache, con supporto al modulo mod_expires.

A questo punto bisogna dare qualche specifica indicazione su quello che andremo a fare, cercando di non complicare troppo il discorso. Quando visualizziamo una pagina del nostro sito le operazioni effettuate a livello più basso, per così dire, sono numerose: anche se bisognerebbe essere più tecnici, possiamo dire che – in prima istanza – gli header di scadenza servono a specificare la “data di scadenza” del contenuto della pagina, in termini di file HTML, CSS, Javascript e così via. La data di scadenza serve ad una cosa molto semplice, per inciso: se oggi 30 novembre 2019 creo una pagina, se indico che scade tra un mese tutte le volte che un utente, oppure il bot-crawler di Google, ci passerà, saprà che non deve ri-scaricarla, facendoci risparmiare tempo, guadagnandone in velocità e ottimizzando il crawl-budget di Google.

Farne uso permetterà inoltre di ridurre il numero di chiamate HTTP, velocizzando così il processo di caricamento della pagina, cosa particolarmente utile nel caso di picchi di visite. Per avere il sito più veloce, la cache del browser è uno dei metodi più usati (anche se non è certamente l’unico).

Gli Expires headers servono a dire ad Apache che quel file (oppure tutti i file di un certo tipo) non subiranno modifica nel breve periodo, per cui – ad esempio da oggi al prossimo mese – è inutile sovraccaricare di richieste l’hosting: basterà invece fornire un file statico..

Come impostare la memorizzazione della cache del browser? Quando si lavora sulla cache via htaccess sarà possibile impostare anni, mesi, settimane, giorni, ore, minuti e secondi di scadenza di ogni singolo tipo di file. Tali tempistiche si indicano in inglese (month per mese, year per anno, day per giorno e così via); ad esempio, possiamo decidere di attivare la cache per le immagini del sito: di solito, anche se bisognerebbe valutare caso per caso, si possono impostare tempi di scadenza piuttosto lunghi.

Se impostiamo un anno, ad esempio, significa che la risorsa immagine sarà messa in cache finchè 1) non sarà trascorso un anno 2) il visitatore non avrà svuotato la cache.

Per attivare una cosa del genere, andremo ad inserire qualcosa di questo tipo nel file .htaccess (il . iniziale indica che si tratta di un file nascosto):

ExpiresByType image/png “access plus 1 month”
ExpiresByType image/gif “access plus 1 month”
ExpiresByType image/jpeg “access plus 1 month”
ExpiresByType image/jpg “access plus 1 month”

Analogamente, possiamo impostare la durata di un mese per tutti i file di stile (CSS):

ExpiresByType text/css “access plus 1 month”

Per i file javascript, ammesso che il sito non sia in fase di sviluppo o in corso di modifiche, possiamo impostare anche un anno di durata:

ExpiresByType application/javascript “access plus 1 year”

È chiaro che tempi di scadenza troppo lunghi sono in genere poco adatti a qualsiasi sito web attivo e costantemente aggiornato: fate inoltre attenzione che le impostazioni che andate a settare potrebbero non essere adatte al vostro sito oppure, più specificatamente, andare in conflitto con le precedenti impostazioni del vostro sito (ad esempio plugin). Se un sito non “prende” gli aggiornamenti che fate e continuate a vedere vecchie pagine anche dopo aver svuotato la cache e la cronologia del browser, potrebbe essere indice del fatto che la durata della cache non sia impostata in modo corretto rispetto a quello che state facendo.

Dal punto di vista tecnico, le direttiva sopra indicate andranno anche qui inserite in un blocco del file .htaccess che abiliti il modulo apposito per la cache del browser: in altri termini, dovremo prima introdurre un blocco del tipo

# Abilitiamo le direttive per ExpiresActive On

e poi all’interno inseriremo, una riga alla volta, le direttive necessarie. Prima di farlo, andiamo anzitutto ad abilitare il modulo in modo generale:

# abilita il servizio di cache del browser
ExpiresActive On

# abilita una durata di default di un mese

ExpiresDefault “access plus 1 month”

In questo caso abbiamo indicato un mese come durata di default, senza specificare il tipo di file, cosa che usualmente si fa ed è indicata per la maggioranza dei siti. Nello specifico, possiamo aggiungere in coda, all’interno del blocco, tutte le direttive che ci servono: quello che si fa di solito è effettuare dei test di performance incrociati per capire quali direttive siano utili a snellire le chiamate HTTP caso per caso. La soluzione del problema, nonostante venga presentata in maniera semplicistica in moltissime guide analoghe, è di soluzione tutt’altro che scontata perchè dipende dal theme utilizzato, senza contare che molte chiamate (specie in presenza di plugin di WP che introducono file JS o CSS) non possono essere ottimizzate con questo metodo.

Di seguito c’è un esempio di mod_expires con le direttive appena viste.

# Enable expirations
ExpiresActive On

# Default directive
ExpiresDefault “access plus 1 month”

# Images
ExpiresByType image/gif “access plus 1 month”
ExpiresByType image/png “access plus 1 month”
ExpiresByType image/jpg “access plus 1 month”
ExpiresByType image/jpeg “access plus 1 month”

# CSS
ExpiresByType text/css “access 1 month”

# Javascript
ExpiresByType application/javascript “access plus 1 year”

A livello tecnico è possibile, su alcuni tipi di server Apache, visualizzare informazioni sulla cache del browser di un sito mediante un curl (su Mac e Linux, via terminale di comando testuale):

curl -I nomesito.prova

che restituirà qualcosa del genere (se la cache non è attiva, oppure se l’informazione non è disponibile via CURL):

HTTP/1.1 200 OK
Date: Mon, 23 Oct 2019 08:06:08 GMT
Server: Apache
Vary: Cookie,Accept-Encoding
X-UA-Compatible: IE=edge,chrome=1
X-Powered-By: PleskLin
Content-Type: text/html; charset=UTF-8

e qualcosa del genere se invece è impostata:

HTTP/1.1 200 OK
Date: Thu, 04 Oct 2019 10:14:35 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=741dreb25456514f:FF=0:TM=13154488957:LM=15526957:S=kmFi3jKGDujg; expires=Sat, 06-Jul-2013 22:15:57 GMT; path=/; domain=[…]
Set-Cookie: NID=48=8jFij8f8Lej115z89237iaa8sdoA8akjaj8DybmLHXMC6aNGyxM8DnyNv-
iYjF09QhiCq2MdM3PKJDSFlkJalkaPHAU4JQy7M76MKDQKEFLPqzoTSBPLKJLKMmdILlkdjel; expires=Fri, 06-Jan-2012 22:15:57 GMT; path=/; domain=[…]; HttpOnly
Server: gws
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked

Si tenga conto, comunque, che per ragioni di configurazione o di sicurezza curl potrebbe non fornire tutte le informazioni, che potrebbero a questo livello essere incomplete o parziali.

File HTACCESS: come funziona?

Gestire un’area riservata del sito via .htaccess

AuthName “Area utenti registrati”
AuthUserFile /path/to/password/file/.htpasswd
AuthType Basic
require valid-user
ErrorDocument 401 /error_pages/401.html

In poche parole stiamo dicendo al webserver Apache che la directory è un’area riservata con tanto di accesso tramite password. L’area si chiama “Area utenti registrati” e il nome utente e la password sono riportati nel file .htpasswd e qualora il login non sia corretto, la pagina di errore deve mostrare la 401.html.

Redirect 301 singola pagina con .htaccess

Con il file HTACCESS si possono impostare anche i redirect 301, basta inserire la seguente stringa

Redirect 301 http://www.sito.com/about http://www.sito.com/chisiamo

Redirect WWW con .htaccess

Si può configurare il redirect WWW, per gli utenti che digitano la URL senza il www

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^.sito.com$
RewriteRule ^(.*)http://www.sito.com/$1 [QSA,L,R=301]

Bloccare un IP con .htaccess

Si può addirittura bloccare le visite di un preciso IP o dominio

Deny from 192.168.1.2
Deny from 192.168
Deny from .wormhole.com

Redirect HTTPS con .htaccess

Si può reindirizzare il traffico verso la versione HTTPS del sito senza usare nessun altro plugin, ovviamente solo se sul sito c’è già un certificato SSL attivo.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Attenzione quando facciamo queste modifiche, perchè vanno tutte integrate con l’esistente e non copia-incollate come capita. Ad esempio la direttiva RewriteEngine On deve essere presente, in genere, soltanto una volta.

Insomma attraverso questo file riusciamo ad aumentare o limitare le funzioni del nostro sito senza bisogno di dover installare pesanti plugin.

Cosa fare se il sito non funziona più dopo una modifica del file .htaccess?

Salvatevi il file originario in copia, e ripristinate quest’ultimo; se non lo avete, dovrebbe bastare cancellare il file .htaccess o svuotarlo completamente. In questo articolo andremo a vedere, di seguito, i più comuni utilizzi del file .htaccess che possono capitare ad un webmaster.

Durante la manutenzione di un sito, ad esempio per aggiornamenti consistenti e soprattutto nel caso in cui siano da definire redirect di vario tipo, può essere importante mettere il sito rapidamente “in manutenzione” in modo che nessuno possa visionare pagine parziali, obsolete o del tutto errate. Dopo aver spiegato come mettere WordPress in manutenzione, in questo caso mi concentro su una circostanza molto più generale.

(fonte: apache.org)

Photo by ell brown


Informazioni sull'autore

Salvatore Capolupo

Consulente SEO, ingegnere informatico e fondatore di Trovalost.it, Pagare.online, Lipercubo.it e tanti altri. Di solito passo inosservato e non ne approfitto.
Ti piace questo articolo?

2 voti

Su Trovalost.it puntiamo sulla qualità dei contenuti da quando siamo nati: la tua sincera valutazione può aiutarci a migliorare ogni giorno.

Guida pratica al file di configurazione .htaccess

Votato 10 / 10, da 2 utenti