Sommario
- Introduzione
- Mappare una URL su di una directory
- Creare un nuovo URL per un contenuto preesistente
- Dare ad ogni utente un proprio URL
- Creare più Alias con una singola direttiva
- Creare una cartella CGI per ogni utente
- Reindirizzamento(Redirecting) vero un altro indirizzo
- Reindirizzare più URL verso lo stesso indirizzo
- Permittere gli URL Case-Insensitive
- Sostituire una stringa nella richiesta URL
- Rewriting Path Information to CGI Arguments
- Vietare l'accesso a richieste non riferiti direttamente al sito
- Riscrittura URI basandosi sulle query
- Reindirizzare tutto o parte del vostro server verso SSL
Introduzione
Quando il web server Apache riceve una richiesta, solitamente il file di contenuto che viene fornito al client proviene da una directory predefinita (DocumentRoot). A volte però potrebbe capitare che i file di contenuto siano in una cartella diversa, per esempio, se si volesse mettere a disposizione degli utenti del sito alcuni documenti presenti nel server, sarebbe più conveniente non spostarli dalla loro posizione, piuttosto lasciarli dove stanno e fare in modo che il web server se li vada a prendere. Per fare questo tipo di cose abbiamo a disposizione tre tecniche:
- Aliasing che "mappa" un determinato URL su una particolare directory.
- Redirecting che "mappa" un URL su di un altro URL
- Rewriting che usando il modulo using mod_rewrite altera in qualche modo l' URL.
Dove per mappare si intende collegare la richiesta di un URL ad un particolare contenuto.
Mappare una URL su di una directory
Problema
Vogliamo fornire dei contenuti presenti in una directoy che sta fuori dal DocumentRoot.
Soluzione
Alias /mio-prefisso /percorso/altra/directory
Spiegazione
In questo caso se un utente digita /mio-prefisso come URL gli verranno forniti i files che stanno nella directory /percorso/altra/directory.
Per esempio una richiesta come http://esempio.com/mio-prefisso/prova.html verrà fornito il file /path/to/other/directory/prova.html.
Questo stesso effetto lo potevamo ottenere creando un semplice link simbolico dalla main document directory alla cartella voluta e attivando le direttive Options +FollowSymLinks1
Comunque usando la funzione Alias si riesce più facilmente a tenere traccia delle directories e dei contenuti.
E' probabile che ci sia la necessità di configurare i permessi necessari per poter accedere alle directory tramite il web server, raccomandiamo quindi di consultare la documentazione relativa (http://httpd.apache.org/docs/misc/security_tips.html#protectserverfiles) per configurare Apache a vietare l'accesso a tutti di default, al di fuori della DocumentRoot directory. Dopo di che per sovrascrivere questa direttiva con i giusti permessi per la cartella in questione inserire il seguente blocco nel file di configurazione:
<Directory /percorso/altra/directory>
Order allow,deny
Allow from all
</Directory>
Questo consentirà l'accesso alla directory specificata.
Notare che il comando Alias prende in considerazione i simboli "/", infatti, se impostassimo la direttiva
Alias /prova/ /www/documenti/prova/
Gli indirizzi URL che iniziano con /prova/ verrebbero correttamente indirizzati, mentre quelli con la stringa /puppies no. Questo è un problema perché se l'utente digita http://esempio.com/prova avrebbe u errore del tipo 404, se invece digita http://esempio.com/prova/ con lo slash "/" finale invece verrebbe indirizzato all directory esatta.
Per evitare ciò basta creare un Aliases senza slash finali su entrambi gli argomenti.
Infine, assicurarsi che, se il primo argomento ha uno slash finale, allora lo deve avere anche il secondo. Per esempio:
Alias /icons/ /usr/local/apache/icons
Una richiesta per http://esempio.com/icons/test.gif implica che Apache fornisca come contenuto il file /usr/local/apache/iconstest.gif piuttosto che quello che volevamo, cioè /usr/local/apache/icons/test.gif.
Note
[1] Vedi documentazione per le direttive opzionali http://httpd.apache.org/docs/mod/core.html#options.
Vedi anche
http://httpd.apache.org/docs/mod/mod_alias.html
Creare un nuovo URL per un contenuto preesistente
Problema
Vogliamo accedere tramite web server ad una directory preesistente usando un nome diverso.
Soluzione
Usare una direttiva Alias nel file di configurazione httpd.conf:
Alias /nuovourl /www/htdocs/vecchiourl
Spiegazione
Anche se la funzione Alias è usata solitamente per mappare un URL su una directory esterna alla DocumentRoot, questo non è affatto obbligatorio. Infatti ci sono molti casi in cui potremo volere accedere ad un contenuto ma con un nome diverso.
Come esempio potremo prendere il caso in cui il nome di una cartella del sito è stata modificato, ma io voglio che i miei utenti dall'esterno ci possano accedere usando sempre lo stesso nome. Quindi aggiungo un Alias che per una richiesta con il vecchio nome vada a reindirizzare al richiesta sulla nuova cartella.
bisogna ricordare che un Alias ha effetto solo sulla parte locale dell'URL (la parte /casa/mia.txt dell'intero indirizzo http://esempio.com/casa/mia.txt) e non ha effetto sulla parte hostname dell'URL (la parte http://esempio.com/ ). Per modificare o lavorare con questa dell'indirizzo URL, è necessario ricorrere alle altre funzioni Redirect o Rewrite.
Dare ad ogni utente un proprio URL
Problema
Vogliamo dare ad ogni utente del sistema un proprio spazio web.
Soluzione
Se vogliamo che i siti web degli utenti siano sotto la loro home directory, dobbiamo aggiungere questo la file di configurazione httpd.conf :
UserDir public_html
Oppure inserisci tutte le directory dei siti web degli utenti sotto una cartella principale:
UserDir /www/users/*/htdocs
Oppure se avete installato il modulo mod_perl potete anche fare qualcosa di più complicato, come il seguente script da aggiungere sempre al file httpd.conf:
<Perl>
my %forbid = map { $_ => 1 } qw(root postgres bob);
opendir H, '/home/';
my @dir = readdir(H);
closedir H;
foreach my $u (@dir) {
next if $u =~ m/^\./;
next if $forbid{$u};
if (-e "/home/$u/public_html") {
push @Alias, "/$u/", "/home/$u/public_html/";
}
}
</Perl>
Spiegazione
La prima soluzione è la più semplice e la più utilizzata. Con questa direttiva tutti gli utenti sul vostro sistema sono in grado di creare una cartella chiamata public_html nella loro home directory e metterci del contenuto web. Il loro spazio web sarà accessibile tramite URL iniziando la stringa con una tilde (~), seguita dal loro username.
Così, un utente chiamato pippo accederebbe al suo sito web personale con l'indirizzo http://www.esempio.com/~pippo/
Se Apache è stato installato da una distribuzione standard, il file di configurazione di default includerà degli esempio riguardanti questo argomento. Contiene anche una sezione <Directory> riguardante la cartella /home/*/public_html, con le varie opzioni e permessi abilitati. Se cene fosse il bisogno basta eliminare il segno di commento in modo da limitare l'accesso ai siti web. Un esempio di questa sezione potrebbe essere:
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
Cercate di essere sicuri di qualsiasi direttiva abilitiate prima di procedere.
La seconda soluzione differisce nell'argomento della direttiva UserDir, perché gli viene passato come un percorso completo e non viene interpretato come come home directory dell'utente, ma come un particolare percorso.
Il simbolo * nel percorso è rimpiazzato dal nome utente. Per esempio, http://esempio.com/~rossi/ è tradotto come /www/users/rossi/htdocs. Questa struttura di cartelle ha bisogno comunque di essere configurata in maniera simile al precedente esempio.
La terza soluzione richiede il modulo mod_perl e fornisce un "mappaggio" alias per tutte le cartelle superiori sotto la gerarchia / home (solitamente le cartelle degli utenti). Differisce dalle altre soluzioni perché non include il simbolo tilde; quindi l'utente rossi avrebbe accesso al suo spazio web con http://esempio.com/rossi/ invece che con http://esempio.com/~rossi/ ma la posizione sul server del contenuto rimarrebe sempre /home/smith/public_html.
In ogni caso le cartelle in questione e il loro percorso devono poter essere leggibili da Apache (solitamente l'utente apache è identificato come nobody o www o httpd), così come i file in esse contenuti devono avere il permesso di essere eseguiti.
Ha bisogno del permesso di esecuzione anche l'elencazione dei file nella directory.
quindi per l'utente pippo, le cartelle "/","/home","/home/pippo" e "/home/pippo/public_html" hanno bisogno del permesso di esecuzione e l'ultima anche quello di lettura.
Per un sistema Unix, dovremo usare i seguenti comandi:
chmod o+x / /home /home/pippo
chmod o+rx /home/pippo/public_html
Per i permessi di lettura:
chmod 644 /home/pippo/public_html/*
Se usate la prima soluzione si dovrebbero impostare i permessi per molti utenti e solitamente si finisce sempre per consentire a tutti gli stessi permessi. Per questo motivo bisognerebbe informare i vari utenti di non mettere dei file personali in una cartella che chiunque dall'esterno potrebbe leggere, se le lo facessero che impostassero in maniera diversa i permessi di lettura
Il vantaggio di usare la seconda soluzione sta proprio nel fatto che i file dello spazio web starebbero in una cartella fuori dalla loro "home", con una sicurezza maggiore per i file personali.
L'ultima soluzione è completamente diversa e avendo installato il modulo mod_perl, consente di configurare Apache dinamicamente. Infatti, usando il contenitore <Perl> all'interno del file di configurazione http.conf è possibile aggiungere le direttive in modo dinamico all'avvio del server.
All'avvio del server Apache, il codice riportato di sopra controlla la cartella /home/ e per tutti gli utenti che hanno una directory public_html crea un Alias specifico.
Il vantaggio rispetto alle precedenti è di non dover scrivere il simbolo "~" prima del nome utente, così che l'utente pippo per accedere al suo spazio web deve scrivere solo http://www.esempio.com/pippo/.
La lista %forbid in cima al codice fornito ci da un elenco di utenti per i quali è bene non creare l'alias, per motivi di sicurezza o altro.
Come negli esempi precedenti il codice dovrebbe anche essere accompagnato da una sezione <Directory> che abilita all'accesso in lettura le cartelle /home/*/public_html.
Creare più Alias con una singola direttiva
Problema
Vogliamo mappare più URL su di una directory usando una sola direttiva.
Soluzione
Usare la funzione AliasMatch nel file di configurazione http.conf per avere una corrispondenza con una espressione regolare:
AliasMatch ^/pupp(y|ies) /www/docs/small_dogs
Spiegazione
La direttiva AliasMatch consente l'uso delle espressioni regolari per creare una corrispondenza tra URL e cartelle, permettendo una maggiore flessibilità.
Nell'esempio precedente l'indirizzo che inizia con /puppy (es.www.esempio.com/puppy), oppure con /puppies, verrà diretto sul contenuto nella directory /www/docs/small_dogs.
Per avere informazioni riguardo l'uso delle espressioni regolari in Apache leggere il relativo articolo presente in questo sito.
In modo analogo funziona la direttiva ScriptAliasMatch al posto della classica AliasMatch, infatti con la direttiva:
ScriptAliasMatch ^/([sS]cripts?|cgi(-bin)?)/ /www/cgi-bin/
si riesce a mappare nella stessa cartella /www/cgi-bin/ tutte le richieste che iniziano con /script/, /scripts/, /Script/, /Scripts/, /cgi/, e /cgi-bin/, inoltre fa si che tutti i file presenti in questa cartella sia trattati come programmi CGI.
Creare una cartella CGI per ogni utente
Problema
Vorremo che ogni utente avesse la propria directory CGI nella quale mettere i propri script piuttosto che dare a tutti accesso alla stessa cartella.
Soluzione
Inserire il seguente codice nel file di configurazione httpd.conf:
<Directory /home/*/public_html/cgi-bin/>
Options ExecCGI
SetHandler cgi-script
</Directory>
Spiegazione
Non si potrebbe usare la direttiva ScriptAlias perché per ogni utente il primo argomento da passare alla funzione sarebbe diverso per ogni utente. Anche usando ScriptAliasMatch sarebbe impossibile, dato che il secondo argomento deve essere uan stringa costante.
La soluzione proposta fa si che per ogni utente inserisca i propri scripts CGI nella proprio spazio web.
I file accessibili con indirizzo URL tipo:
http://www.example.com/~username/cgi-bin/
saranno trattati come scripts CGI.
Se avete abilitato suexec , i programmi CGI verranno eseguita dalla cartella target usando come utente quello specificato nell'URL. Per esempio se un utente accedesse al sito con http://www.esempio.com/~pippo/cgi-bin/esempio.cgi verrebbe eseguito come utente pippo.
Reindirizzamento(Redirecting) vero un altro indirizzo
Problema
Vogliamo che una particolare richiesta URL venga reindirizzata verso un altro server.
Soluzione
Usare la direttiva Redirect nel file di configurazione httpd.conf, e fornire un percorso assoluto(URL) come secondo argomento:
Redirect /esempio http://www.altro.server/nuova/posizione
Spiegazione
Mentre con la direttiva Alias viene mappato un indirizzo URL verso una cartella nel filesystem locale, con la direttiva Redirect viene mappato un URL verso un altro URL, solitamente su di un altro server.
Il secondo argomento è un URL completo e viene restituito al client (browser), il quale ne tiene conto facendo una seconda richiesta questa volta verso il nuovo indirizzo URL.
E' anche importante sapere che questa direttiva conserva le informazione del percorso iniziale. Infatti, per una richiesta del tipo http://primo.server/esempio/test.html si verrebbe rediretti alla pagina http://www.secondo.server/nuovo/posizione/test.html.
I reindirizzamenti possono essere anche selettivi, infatti inserendo alcune parole chiave, tra la direttiva e il suo primo argomento, si può selezionare un particolare tipo di redirect.
Tutti i reindirizzamenti hanno la funzione di informare il client della nuova posizione di un determinato contenuto; i tipi differenti di reindirizzamento però hanno la capacità di informare sulla posizione futura del contenuto.
- temp
Il reindirizzamento con temp è usato quando il documento non è al momento disponibile in quella posizione, ma è previsto che lo si possa trovare li in futuro. Così il client ricorda che l'URL usando nella richiesta originale e la riusa per una richiesta futura. - permanent
Un reindirizzamento permanente indica che non solo non è più possibile trovare il documento nella posizione originale, ma il client non dovrebbe più cercarla li in futuro. - gone
Questa parola chiave indica che un documento non più nella posizione originale e non dovrebbe più essere richiesto. Differisce da un errore del tipo 404 Not Found nel fatto che si ammette che un tempo il documento era in quella posizione e ora non più, e questo non è considerato un errore, diversamente dallo stato 404. - seeother
questo tipo di redirect dice al client che il documento non esiste più nella posizione originale, ma che ora è possibile trovarlo modificato in una posizione diversa.
Per esempio se io facessi una richiesta come http://esempio.com/capitolo2.html e il server mi rispondesse col redirect seeother verso un nuovo link http://miolibro.com/edizione-2/capitolo2.html questo significherebbe non solo che il contenuto richiesto ha cambiato posizione ma che il capitolo 2 cercato è stato rimpiazzato dalla sua seconda edizione.
Di default, se non è specificata nessuna parola chiave, il reindirizzamento viene inteso come temp.
Qui sotto potete trovare qualche esempio dei vari formati della direttiva, incluso il codice dello stato HTTP in caso voleste usare un documento di errore (ErrorDocument) per personalizzare la risposta del server:
# questo equivale ad una risposta con codice 302.
#
Redirect /foo.html http://esempio.com/under-construction/foo.html
Redirect temp /foo.html http://esempio.com/under-construction/foo.html
RedirectTemp /foo.html http://esempio.com/under-construction/foo.html
#
#questo equivale ad una risposta con codice 301
#
Redirect permanent /foo.html http://esempio.com/relocated/foo.html
RedirectPermanent /foo.html http://esempio.com/relocated/foo.html
#
# Questo dice all client che il vecchio URL non c'è più, ma
# è stato rimpiazzato con uno nuovo. Restituisce il codice 303
#
Redirect seeother /foo.html http://esempio.com/relocated/bar.html
#
# Restituisce il codice 410, dicendo al client che il documento è stato
# intenzionalmente rimosso e non sarà ripristinato.
# Notare che questo non è un absoluteURL.
#
Redirect gone /foo.html
Reindirizzare più URL verso lo stesso indirizzo
Problema
Vogliamo reindirizzare un certo tipo di richieste verso un unico indirizzo URL. Per esempio che le richieste per /pesca o /pesce siano reindirizzate verso http://pesca.esempio.com/.
Soluzione
Usare la funzione RedirectMatch nel file di configurazione httpd.conf per creare una corrispondenza con le espressioni regolari:
RedirectMatch ^/pesc[ae] http://pesce.esempio.com
Spiegazione
Questa soluzione permette al server di reindirizzare tutte le richieste che iniziano con /pesc seguite da una a o da una e verso l'indirizzo http://pesce.esempio.com. In questo modo le informazioni riguardanti il percorso verranno preservate, per cui se fosse richiesta la pagina http://vecchio.server/pesca/cernia.html il server reindirizzarebbe verso http://pesce.esempio.com/cernia.html.
Per avere informazioni riguardo l'uso delle espressioni regolari in Apache leggere il relativo articolo presente in questo sito.
Permittere gli URL Case-Insensitive
Problema
Vogliano che le richieste URL siano valide sia con le lettere maiuscole che con le lettere minuscole.
Soluzione
Usare il modulo mod_speling per far diventare gli URL case-insensitive:
CheckSpelling On
Spiegazione
Il modulo mod_speling fa parte della distribuzione standard di Apache ma non è abilitato di default, così è necessario abilitarlo esplicitamente.
Come vantaggi avremo anche che il server, grazie a questo modulo, aiuterà l'utente a trovare un indirizzo simile a quello richiesto, nel caso quest'ultimo non fosse disponibile ("not found" error).
Una volta che il modulo mod_speling è stato installato possiamo attivarlo su una singola directory oppure su un virtual host oppure sull'intero web server usando al direttiva CheckSpelling ON.
Sostituire una stringa nella richiesta URL
Problem
Vogliamo sostituire la stringa1 con la stringa2 in tutte le richieste URI.
Soluzione
RewriteCond %{REQUEST_URI} "stringa1"
RewriteRule "(.*)stringa1(.*)" "$1stringa2$2" [N,PT]
Spiegazione
L'opzione [N] significa che Apache deve riprocessare l'URL riscritto. Questo verrà ripetuto fino a che la condizione di rewrite (RewriteCond) non è più vera. In questo caso, quindi, finchè l'indirizzo conterrà la "stringa1" che voglio sostituire.
L'opzione [PT] fa si che il risultato della sostituzione venga ripreso da Apache per le successive elaborazioni della richiesta una volta che la riscrittura è terminata.
Rewriting Path Information to CGI Arguments
Problema
Vogliamo inviare dei parametri per uno script CGI (CGI QUERY_STRING) come se fossero un indirizzo URL.
Soluzione
Per esempio potremo usare una regola di riscrittura in questa maniera:
RewriteEngine on
RewriteRule ^/libro/([^/]*)/([^/]*) /cgi-bin/libro.cgi?autore=$1&titolo=$2 [PT]
naturalmente questo è solo un esempio, ognuno dovrebbe personalizzarla per le proprie esigenze.
Spiegazione
Uno dei motivi per volere una cosa del genere è ad esempio avere un modo più semplice di inserire dei parametri nelle richieste URL. Infatti per un utente è molto più facile scrivere e ricordare un indirizzo così riscritto. Infatti, la regola di riscrittura dellìesempio di sopra permette di trasformare una richiesta del tipo http://www.esempio.com/libro/animali/pippo in http://www.esempio.com/cgi-bin/libro.cgi?titolo=animali&autore=pippo
L'opzione [PT] nella direttiva indica ad Apache di continuare a processare la richiesta anche dopo averla modificata; senza questa opzione il web server tratterebbe l'URL richiesto come il nome di un file e non lo riconoscerebbe come uno script CGI che viene richiamato con i sui parametri. Permette inoltre a successive direttive RewriteRule di continuare eventuali modifiche al URL.
Se l' URL da riscrivere è stato già modificato come "query string", allora è necessario cambiare l'opzione [PT] con [QSA,PT], dove QSA sta per "query string add" e che implicherà l'aggiunta della stringa di query dell'URL originale anche nel risultato finale.
Per maggiori informazioni leggere i seguenti documenti:
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
http://httpd.apache.org/docs/1.3/misc/rewriteguide.html
http://httpd.apache.org/docs/2.2/rewrite/
Vietare l'accesso a richieste non riferiti direttamente al sito
Problema
Vogliamo evitare che altri siti web usino nelle loro pagine le immagini (o altri tipi di documenti) presenti nel nostro sito.
Quindi le nostre immagini dovranno essere accessibili solo per le richieste dirette al nostro sito.
Soluzione
Inserire nel file di configurazione httpd.conf le seguenti direttive:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !=""
RewriteCond %{HTTP_REFERER} "!^http://miosito.com/.*$" [NC]
RewriteCond %{REQUEST_URI} "\.(jpg|gif|png)$"
RewriteRule .* - [F]
Spiegazione
Questa soluzione consiste in una serie di direttive RewriteCond, che controllano se il documento è una immagine (naturalmente potete specificare i tipi file che vi interessa proteggere) e se l'immagine è richiesta da un documento all'interno del vostro sito oppure se è incluso dentro la pagina residente.
Se tutto questo viene accertato allora un altro sito sta rubando le vostre immagini e va fermato.
La prima condizione verifica che il mittente sia specificato. Alcuni client non mandano informazioni sul mittente e alcuni browser possono essere configurati per non mandarlo.
Se noi negassimo tutti le richieste senza un mittente specificato, finiremo per negare un bel po di richieste valide; per questo motivo le lasciamo passare.
Per quelle che invece il mittente ce l'hanno dovremo controllare se il mittente arriva dal nostro sito o meno. Se vengono da un sito esterno continuo a controllare se il tipo di file richiesto è un file immagine.
Se il file non è un immagine, come per esempio un file HTML, allora permettiamo l'accesso da un sito esterno, ma se invece risultasse una immagine (nell'esempio di sopra sono considerate immagini solo i file .jpg, .gif e .png) allora tutte le condizioni sarebbero rispettate e la risposta alla richiesta sarebbe un Forbidden (proibito) da parte del nostro server, usando l'opzione [F].
Riscrittura URI basandosi sulle query
Problema
vogliamo tradurre un URI in un altro basandosi sulla stringa di query del primo.
Soluzione
Inserire nel file di configurazione httpd.conf le seguenti direttive:
RewriteCond "%{QUERY_STRING}" "^user=([^=]*)"
RewriteRule "/utenti" "http://%1.utenti.esempio.com/" [R]
Spiegazione
La direttiva mod_rewrite non considera la stringa di query come parte del URI (Uniform Resource Identifiers) ai fini del matching e della riscrittura, per questo motivo abbiamo la necessità di occuparcene separatamente.
Nel esempio di sopra la richiesta http://esempio.com/utenti?user=pippo verrebbe tradotta in http://pippo.users.esempio.com/
L'opzione [R] fa in modo che il modulo mod_rewrite mandi il browser all URL costruito dalla direttiva RewriteRule.
Reindirizzare tutto o parte del vostro server verso SSL
Problema
Vogliamo che alcune parti del sito non-SSL sia reindirizzate verso l'area sicura.
Soluzione
Possiamo reindirizzare qualsiasi richiesta sulla porta 80 con la seguente direttiva:
RewriteCond "%{SERVER_PORT}" "^80$"
RewriteRule "^(.*)$" "https://%{SERVER_NAME}$1" [R,L]
Possiamo reindirizzare alcuni particolari URL verso l'area sicura:
RewriteRule "^/normale/sicuro(/.*)" "https://%{HTTP_HOST}$1" [R,L]
Possiamo controllare che la variabile HTTPS sia impostata:
RewriteCond %{HTTPS} !=on
RewriteRule "^(/sicuro/.*)" "https://%{HTTP_HOST}$1" [R,L]
Oppure, possiamo semplicemente usare la direttiva Redirect nella sezione http del file di configurazione httpd.conf affinchè la richiesta URL venga trattata come HTTPS:
Redirect / https://sicuro.esempio.com/
Siate sicuri che questa direttiva sia inclusa nella sezione http e non in quella https , altrimenti le richieste https avrebbero dei loop.
Spiegazione
La prima soluzione fa si che tutte le richieste sulla porta 80 (normalmente è la porta per le connessioni HTTP non criptate) siano reindirizzate verso lo stesso indirizzo sul server, ma con accesso SSL. Notare l'uso del SERVER_NAME; perché si tratta si un reindirizzamento completo.
La seconda soluzione fa si che tutte le parti del sito sotto l'indirizzo http://miohost/normale/sicuro devono essere reindirizzati verso l'area SSL all'indirizzo https://myhost/.
Notare che i percorsi SSL e quelli non-SSL sono diversi, per mantenerli modificandone solo l'http con https allora usate la terza soluzione.
