--- a/GNUmakefile	Mon Nov 18 12:48:10 2013 +0400
+++ b/GNUmakefile	Wed Nov 20 14:36:40 2013 +0400
@@ -74,7 +74,7 @@
 		dtd/news.dtd						\
 		xslt/news.xslt						\
 
-LANGS =		en ru cn he ja tr
+LANGS =		en ru cn he ja tr it
 
 YEARS =		2012 2011 2010 2009
 

--- a/xml/i18n.xml	Mon Nov 18 12:48:10 2013 +0400
+++ b/xml/i18n.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -73,4 +73,15 @@
 <item id="translator">çeviren:</item>
 </text>
 
+<text lang="it">
+<item id="and">e</item>
+<item id="author">scritto da</item>
+<item id="editor">pubblicato da</item>
+<item id="translator">tradotto da</item>
+<item id="dirindex">Elenco alfabetico delle direttive</item>
+<item id="outdated">Questa traduzione potrebbe essere obsoleta.
+Verifica la <origin>versione in inglese</origin>
+per gli aggiornamenti piu' recenti.</item>
+</text>
+
 </i18n>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/GNUmakefile	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,13 @@
+DOCS =									\
+		faq							\
+		install							\
+		windows							\
+		events							\
+		syntax							\
+		control							\
+		hash							\
+		http/request_processing					\
+		http/server_names					\
+		http/configuring_https_servers				\
+		debugging_log						\
+		beginners_guide						\

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/beginners_guide.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,454 @@
+<!--
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="Guida per il principiante"
+         link="/it/docs/beginners_guide.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="1">
+
+<section>
+
+<para>
+La presente guida fornisce una introduzione a nginx e descrive alcune
+semplici funzionalità per il quale può essere utilizzato.
+Nel seguito si presuppone che nginx sia gia' stato installato;
+in caso contrario fare riferimento alla pagina
+<link doc="install.xml"/>.
+La presente guida spiega come avviare, come fermare e come ricaricare
+la configurazione di nginx, descrive brevemente la struttura del file
+di configurazione, spiega come configurare nginx per servire contenuti statici,
+come configurarlo per l'uso come proxy server,
+e come configurarlo per l'uso con un'applicazione FastCGI.
+</para>
+
+<para>
+nginx ha un processo master e numerosi processi worker:
+lo scopo principale del processo master e' leggere e interpretare la configurazione,
+e mantenere i processi worker attivi;
+a loro volta, i processi worker si occupano di gestire effettivamente le richieste.
+nginx utilizza un modello event-based e meccanismi dipendenti dal sistema operativo
+per distribuire con efficienza le richieste fra i processi worker.
+Il numero di processi worker e' definito nel file di configurazione,
+e puo' sia essere fisso,
+sia essere regolato automaticamente in base al numero di core CPU disponibili
+(vedere <link doc="ngx_core_module.xml" id="worker_processes"/>).
+</para>
+
+<para>
+La maniera in cui nginx e i suoi moduli lavorano e' determinata nel file di configurazione;
+per default, tale file si chiama
+<path>nginx.conf</path>
+e si trova in una delle directory:
+<path>/usr/local/nginx/conf</path> ,
+<path>/etc/nginx</path> ,
+<path>/usr/local/etc/nginx</path> .
+</para>
+
+</section>
+
+
+<section id="control" name="Avvio, arresto e ricaricamento della configurazione">
+
+<para>
+Per far partire nginx, avviare il file eseguibile.
+Una volta partito, nginx puo' essere controllato invocando l'eseguibile con il parametro
+<literal>-s</literal> .
+Usare la seguente sintassi:
+<programlisting>
+nginx -s <i>signal</i>
+</programlisting>
+Dove <i>signal</i> e' uno dei seguenti:
+<list type="bullet">
+<listitem>
+<literal>stop</literal>&mdash;arresto rapido
+</listitem>
+<listitem>
+<literal>quit</literal>&mdash;arresto controllato
+</listitem>
+<listitem>
+<literal>reload</literal>&mdash;ricaricamento della configurazione
+</listitem>
+<listitem>
+<literal>reopen</literal>&mdash;riapertura del file di log
+</listitem>
+</list>
+Ad esempio, per fermare il processo nginx ma attendendo che finisca di servire
+le richieste correnti, va eseguito il seguente comando:
+<programlisting>
+nginx -s quit
+</programlisting>
+<note>Questo comando dovrebbe essere eseguito dallo stesso utente che ha avviato nginx.</note>
+</para>
+
+<para>
+Le modifiche al file di configurazione non saranno applicate sinche'
+nginx non e' riavviato o non riceve il comando di ricaricamento della configurazione.
+Per ricaricare la configurazione, eseguire:
+<programlisting>
+nginx -s reload
+</programlisting>
+</para>
+
+<para>
+Quando il processo master riceve il segnale di ricaricamento della configurazione,
+verifica la validita' sintattica e tenta di applicare la configurazione riportata nel relativo file.
+Se ha successo, il processo master avvia nuovi processi worker e invia messaggi di chiusura a quelli vecchi,
+che smettono di accettare nuove connessioni ma continuano a servire le richieste correnti sinche' non sono
+state del tutto completate, dopo di che terminano.
+Se la nuova configurazione non risulta corretta, oppure se non e' possibile applicarla,
+il processo master continua a lavorare con la configurazione precedente.
+</para>
+
+<para>
+E' anche possibile inviare un segnale ai processi nginx tramite i normali comandi Unix,
+quale ad esempio <command>kill</command>, che invia un segnale al processo individuato tramite il relativo ID;
+per default, l'ID del processo master di nginx e' scritto nel file <path>nginx.pid</path>
+nella directory
+<path>/usr/local/nginx/logs</path> oppure
+<path>/var/run</path> .
+Ad esempio, se l'ID del processo master e' 1628, per inviare il segnale QUIT,
+che causa l'arresto controllato, bisogna eseguire il comando:
+<programlisting>
+kill -s QUIT 1628
+</programlisting>
+Per ottenere la lista di tutti in processi nginx, e' possibile usare vari comandi,
+fra cui ad esempio <command>ps</command>
+nella maniera seguente:
+<programlisting>
+ps -ax | grep nginx
+</programlisting>
+Per ulteriori informazioni su come inviare segnali a ngnix, fare riferimento a
+<link doc="control.xml"/>.
+</para>
+
+</section>
+
+
+<section id="conf_structure" name="Struttura del file di configurazione">
+
+<para>
+nginx e' costituito da moduli che sono controllati da direttiva specificate
+nel file di configurazione.
+Le direttive possono essere semplici o a blocco.
+Una direttiva semplice e' caratterizzata dal nome seguito da parametri separati da spazi,
+e termina con punto e virgola (<literal>;</literal>).
+Una direttiva a blocco ha la stessa struttura di una direttiva semplice,
+ma, invece che con punto e virgola, termina con un insieme di istruzioni aggiuntive racchiuse
+fra parentesi graffe ( <literal>{</literal> e <literal>}</literal> ).
+Una direttiva che puo' avere altre direttive all'interno delle parentesi graffe e' chiamata
+contesto (ad esempio:
+<link doc="ngx_core_module.xml" id="events"/>,
+<link doc="http/ngx_http_core_module.xml" id="http"/>,
+<link doc="http/ngx_http_core_module.xml" id="server"/>,
+e
+<link doc="http/ngx_http_core_module.xml" id="location"/>).
+Le direttive del file di configurazione che non sono all'interno di alcun
+contesto sono considerate facenti parte del contesto
+<link doc="ngx_core_module.xml">main</link>.
+</para>
+
+<para>
+Le direttive <literal>events</literal> e <literal>http</literal>
+appartengono al contesto <literal>main</literal>, la direttiva <literal>server</literal>
+al contesto <literal>http</literal>,
+la direttiva <literal>location</literal> al contesto <literal>server</literal>.
+</para>
+
+<para>
+Tutto cio' che in una riga segue il simbolo <literal>#</literal> e' considerato un commento.
+</para>
+
+</section>
+
+
+<section id="static" name="Servizio di contenuti statici">
+
+<para>
+Un compito importante di un web server e' costituito dal servizio
+di file, quali immagini o pagine HTML statiche.
+Di seguito si implementa un esempio in cui, a seconda della richiesta,
+i file sono serviti prendendoli da varie directory locali: <path>/data/www</path>
+(che puo' contenere file HTML) e <path>/data/images</path>
+(che contiene immagini).
+Per tale implementazione e' necessaria la modifica del file di configurazione,
+con l'aggiunta,
+all'interno di un blocco <link doc="http/ngx_http_core_module.xml" id="http"/>,
+di un blocco <link doc="http/ngx_http_core_module.xml" id="server"/>
+a sua volta contenente due blocchi <link doc="http/ngx_http_core_module.xml" id="location"/>.
+</para>
+
+<para>
+Anzitutto, creare le directory <path>/data/www</path> e <path>/data/images</path>,
+e aggiungere nella prima un file <path>index.html</path> contenente un testo qualsiasi,
+nella seconda una immagine a caso.
+</para>
+
+<para>
+Quindi, aprire il file di configurazione;
+si puo' notare che contiene gia' diversi esempi di blocchi <literal>server</literal>,
+per la maggior parte inattivati da commenti;
+inattivare con commenti tutto il blocco <literal>http</literal>, e scriverne uno nuovo:
+<programlisting>
+http {
+    server {
+    }
+}
+</programlisting>
+In generale, il file di configurazione puo' includere numerosi blocchi <literal>server</literal>,
+<link doc="http/request_processing.xml">distinti</link> in base alla porta su cui
+sono in <link doc="http/ngx_http_core_module.xml" id="listen">ascolto</link> e al
+<link doc="http/server_names.xml">nome del server</link>.
+Una volta che nginx ha deciso quale <literal>server</literal> deve processare una data richiesta,
+confronta l'URI presente nell'header della stessa con i parametri delle direttive
+<literal>location</literal> definite all'interno del blocco <literal>server</literal>.
+</para>
+
+<para>
+Aggiungere il seguente blocco <literal>location</literal>
+al blocco <literal>server</literal>:
+<programlisting>
+location / {
+    root /data/www;
+}
+</programlisting>
+Questo blocco <literal>location</literal> fa riferimento al prefisso “<literal>/</literal>”,
+da confrontare con l'URI della richiesta:
+se la richiesta corrisponde, l'URI viene aggiunto al path specificato dalla
+direttiva <link doc="http/ngx_http_core_module.xml" id="root"/>,
+in questo caso cioe' a <path>/data/www</path> ,
+per definire sul file system locale il path al file richiesto.
+Se i blocchi <literal>location</literal> che corrispondono sono piu' di uno,
+nginx seleziona quello con il prefisso piu' lungo;
+il blocco <literal>location</literal> dell'esempio riguarda il prefisso
+piu' breve in assoluto, di lunghezza uno, quindi e' effettivamente usato
+solo se tutti gli altri blocchi <literal>location</literal> non corrispondono.
+</para>
+
+<para>
+Tornando all'esempio, aggiungere un secondo blocco <literal>location</literal>:
+<programlisting>
+location /images/ {
+    root /data;
+}
+</programlisting>
+In questo caso ci sara' corrispondenza con
+le richieste che iniziano con <literal>/images/</literal>
+(anche <literal>location /</literal> corrisponde alla richiesta,
+ma ha un prefisso piu' breve e quindi priorita' inferiore).
+La configurazione risultante del blocco <literal>server</literal> risulta quindi:
+<programlisting>
+server {
+    location / {
+        root /data/www;
+    }
+
+    location /images/ {
+        root /data;
+    }
+}
+</programlisting>
+Tale configurazione e' effettivamente funzionante,
+con il server in ascolto sulla porta standard 80 e accessibile
+sulla macchina locale a <literal>http://localhost/</literal> .
+In risposta alle richieste di URI che iniziano con <literal>/images/</literal> ,
+il server inviera' file presi dalla directory <path>/data/images</path> ;
+ad esempio, in risposta ad una richiesta
+<literal>http://localhost/images/example.png</literal>
+nginx inviera' il file <path>/data/images/example.png</path> .
+Se tale file non esiste, nginx inviera' una risposta che indica
+l'errore 404.
+Richieste di URI che non iniziano con <literal>/images/</literal>
+saranno mappate sulla directory <path>/data/www</path> ;
+ad esempio, in risposta ad una richiesta
+<literal>http://localhost/some/example.html</literal>
+nginx inviera' il file <path>/data/www/some/example.html</path> .
+</para>
+
+<para>
+Per applicare la nuova configurazione, avviare nginx se e' spento;
+se e' gia' attivo, inviare il segnale <literal>reload</literal> al processo master,
+eseguendo:
+<programlisting>
+nginx -s reload
+</programlisting>
+</para>
+
+<para>
+<note>
+Nel caso in cui qualcosa non vada come atteso, e' possibile cercare
+di capire cosa e' successo verificandolo nei file <path>access.log</path> e
+<path>error.log</path>, presenti nella directory <path>/usr/local/nginx/logs</path> o
+<path>/var/log/nginx</path> .
+</note>
+</para>
+
+</section>
+
+
+<section id="proxy" name="Configurare un semplice proxy server">
+
+<para>
+Uno degli usi piu' frequenti di nginx prevede la configurazione come proxy server,
+vale a dire un server che riceve le richieste dai client, le passa ai server remoti,
+riceve da essi le risposte, e le reinvia ai client.
+</para>
+
+<para>
+Di seguito si configura un semplice proxy server, il quale serve le richieste
+di immagini con file da una directory locale, e invia invece tutte le altre
+richieste a un ulteriore server web.
+Nell'esempio, entrambi i server saranno definiti su una singola istanza di nginx..
+</para>
+
+<para>
+Per iniziare, definire il server web aggiuntivo inserendo nel file di configurazione di
+nginx un ulteriore blocco <literal>server</literal> con il contenuto seguente:
+<programlisting>
+server {
+    listen 8080;
+    root /data/up1;
+
+    location / {
+    }
+}
+</programlisting>
+Si tratta di un semplice server in ascolto sulla porta 8080
+(in precedenza la direttiva <literal>listen</literal> non e' stata specificata
+in quanto e' stata usata la porta standard 80), che mappa tutte le
+richieste sulla directory <path>/data/up1</path> del file system locale.
+Creare tale directory, e inserire in essa un file <path>index.html</path> .
+Notare che la direttiva <literal>root</literal> e' posta nel
+contesto <literal>server</literal> ; tale direttiva <literal>root</literal> e' usata
+quando il blocco <literal>location</literal> scelto per servire una richiesta
+non include una direttiva <literal>root</literal> propria.
+</para>
+
+<para>
+Procedere usando la configurazione del server della sezione precedente e
+modificandola per farne un proxy server.
+Nel primo blocco <literal>location</literal>, inserire la direttiva
+<link doc="http/ngx_http_proxy_module.xml" id="proxy_pass"/>
+specificando come parametro il protocollo, il nome e la porta del server
+web aggiuntivo (in questo caso <literal>http://localhost:8080</literal> ):
+<programlisting>
+server {
+    location / {
+        proxy_pass http://localhost:8080;
+    }
+
+    location /images/ {
+        root /data;
+    }
+}
+</programlisting>
+</para>
+
+<para>
+A questo punto modificare il secondo blocco <literal>location</literal>, che al momento
+mappa le richieste con il prefisso <literal>/images/</literal> sui file nella directory
+<path>/data/images</path> , per fare in modo che risponda alle richieste con le
+tipiche estensioni file delle immagini.
+Il blocco <literal>location</literal> sara' il seguente:
+<programlisting>
+location ~ \.(gif|jpg|png)$ {
+    root /data/images;
+}
+</programlisting>
+Il parametro e' una espressione regolare che corrisponde a tutti gli URI
+che terminano con <path>.gif</path>, <path>.jpg</path>, o <path>.png</path>
+(in ngnix le espressioni regolari normalmente iniziano con <literal>~</literal> ).
+La richiesta corrispondente sara' mappata sulla directory <path>/data/images</path> .
+</para>
+
+<para>
+Per decidere quale blocco <literal>location</literal> debba servire una richiesta,
+nginx per prima cosa verifica le direttive
+<link doc="http/ngx_http_core_module.xml" id="location"/>
+che riportano la specifica di un prefisso, registrando quella con il piu' lungo
+prefisso che corrisponde, quindi verifica quelle con una espressione regolare;
+se c'e' corrispondenza con una espressione regolare, nginx sceglie tale
+<literal>location</literal>, altrimenti sceglie quella registrata in precedenza.
+</para>
+
+<para>
+Alla fine la configurazione risultante di un proxy server e' la seguente:
+<programlisting>
+server {
+    location / {
+        proxy_pass http://localhost:8080/;
+    }
+
+    location ~ \.(gif|jpg|png)$ {
+        root /data/images;
+    }
+}
+</programlisting>
+Tale server selezionera' le richieste che terminano in <path>.gif</path>,
+<path>.jpg</path> o <path>.png</path> e le mappera' sulla directory
+<path>/data/images</path> (aggiungendo l'URI al parametro della direttiva
+<literal>root</literal>), mentre invece passera' tutte le altre richieste al web
+server configurato in precedenza.
+</para>
+
+<para>
+Per applicare la nuova configurazione, inviare il segnale <literal>reload</literal>
+ad nginx, come descritto nella sezione precedente.
+</para>
+
+<para>
+Ci sono molte <link doc="http/ngx_http_proxy_module.xml">more</link>
+direttive che possono essere usate nella configurazione di un proxy.
+</para>
+
+</section>
+
+
+<section id="fastcgi" name="Configurare il proxying FastCGI">
+
+<para>
+nginx puo' essere usato per dirigere le richieste ad uno o piu' server
+FastCGI che eseguono applicazioni scritte con vari framework e linguaggi di
+programmazione, ad esempio PHP.
+</para>
+
+<para>
+La configurazione piu' semplice di nginx che consente di lavorare con un server
+FastCGI, richiede l'uso della direttiva
+<link doc="http/ngx_http_fastcgi_module.xml" id="fastcgi_pass"/>
+al posto della direttiva <literal>proxy_pass</literal>,
+e della direttiva <link doc="http/ngx_http_fastcgi_module.xml" id="fastcgi_param"/>
+per impostare i parametri passati al server FastCGI.
+Nel seguito si suppone che il server FastCGI sia accessibile a <literal>localhost:9000</literal> .
+Prendendo la configurazione di un proxy nella sezione precedente come base,
+sostituire la direttiva <literal>proxy_pass</literal> con la direttiva <literal>fastcgi_pass</literal>
+e cambiare il relativo parametro in <literal>localhost:9000</literal> .
+Nel caso del PHP, il parametro <literal>SCRIPT_FILENAME</literal> e' usato per determinare
+il nome dello script, ed il parametro <literal>QUERY_STRING</literal> e' usato per
+passare i parametri della richiesta.
+La configurazione risulta quindi:
+<programlisting>
+server {
+    location / {
+        fastcgi_pass  localhost:9000;
+        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
+        fastcgi_param QUERY_STRING    $query_string;
+    }
+
+    location ~ \.(gif|jpg|png)$ {
+        root /data/images;
+    }
+}
+</programlisting>
+Tale configurazione realizza un server che inoltra tutte le richieste
+(a parte quelle per immagini statiche) tramite il protocollo FastCGI
+ad un server esterno che opera su
+<literal>localhost:9000</literal> .
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/control.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,282 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="Controllo di nginx"
+         link="/it/docs/control.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="5">
+
+<section>
+
+<para>
+nginx puo' essere controllato tramite segnali.
+L'ID del processo master e' scritto per default nel file
+<path>/usr/local/nginx/logs/nginx.pid</path>.
+E' possibile utilizzare un altro file utilizzando la direttiva
+<link doc="ngx_core_module.xml" id="pid"/>, definendola all'avvio
+oppure in <path>nginx.conf</path> .
+Il processo master riconosce i seguenti segnali:
+<note>
+<table>
+
+<tr><td width="20%">TERM, INT</td><td>arresto rapido</td></tr>
+<tr><td width="20%">QUIT</td><td>arresto controllato</td></tr>
+<tr><td width="20%">HUP</td><td>ricaricamento della configurazione,
+allineamento ad una diversa zona oraria (solo per FreeBSD e Linux),
+riavvio di nuovi processi worker con una nuova configurazione,
+spegnimento controllato dei vecchi processi worker</td></tr>
+<tr><td width="20%">USR1</td><td>riapertura dei file di log</td></tr>
+<tr><td width="20%">USR2</td><td>aggiornamento del file eseguibile</td></tr>
+<tr><td width="20%">WINCH</td><td>arresto controllato dei processi worker</td></tr>
+
+</table>
+</note>
+</para>
+
+<para>
+E' anche possibile controllare ciascun processo worker,
+per quanto cio' non sia richiesto.
+I segnali riconosciuti sono:
+<note>
+<table>
+
+<tr><td width="20%">TERM, INT</td><td>arresto rapido</td></tr>
+<tr><td width="20%">QUIT</td><td>arresto controllato</td></tr>
+<tr><td width="20%">USR1</td><td>riapertura dei file di log</td></tr>
+<tr><td width="20%">WINCH</td><td>chiusura anomala per debugging
+(richiede <link doc="ngx_core_module.xml" id="debug_points"/> )
+</td></tr>
+
+</table>
+</note>
+</para>
+
+</section>
+
+
+<section id="reconfiguration" name="Cambio della configurazione">
+
+<para>
+Per far rileggere la configurazione a nginx, bisogna inviare
+un segnale HUP al processo master.
+Tale processo per prima cosa verifica la validita' sintattica
+della nuova configurazione, quindi tenta di applicarla, vale a dire
+di aprire i file di log e i nuovi socket di ascolto.
+In caso di fallimento, annulla i cambiamenti e continua a lavorare
+con la vecchia configurazione.
+Invece, in caso di successo, avvia nuovi processi worker e invia a
+quelli vecchi appositi segnali per chiederne l'arresto controllato.
+I vecchi processi chiudono i socket di ascolto, ma continuano il
+servizio per i vecchi client.
+Quanto tutti i vecchi client sono stati servizi, i vecchi
+processi worker terminano.
+</para>
+
+<para>
+Di seguito si illustra con un esempio.
+Si immagini che nginx sia in esecuzione su FreeBSD 4.x
+e che il comando
+<programlisting>
+ps axw -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'
+</programlisting>
+produca il seguente risultato:
+<programlisting>
+  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
+33126     1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
+33127 33126 nobody   0.0  1380 kqread nginx: worker process (nginx)
+33128 33126 nobody   0.0  1364 kqread nginx: worker process (nginx)
+33129 33126 nobody   0.0  1364 kqread nginx: worker process (nginx)
+</programlisting>
+</para>
+
+<para>
+Se al processo master si invia il segnale HUP, si ottiene:
+<programlisting>
+  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
+33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
+33129 33126 nobody   0.0  1380 kqread nginx: worker process is shutting down (nginx)
+33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
+33135 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
+33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
+</programlisting>
+</para>
+
+<para>
+Uno dei vecchi processi worker con PID 33129 continua ad essere attivo;
+dopo un po', esce:
+<programlisting>
+  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
+33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
+33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
+33135 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
+33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="logs" name="Rotazione dei file di log">
+
+<para>
+Per poter ruotare i file di log, e' prima necessario cambiare loro il nome,
+quindi bisogna inviare il segnale USR1 al processo master,
+il quale provvede a riaprire tutti i file di log correnti e ad
+assegnarli all'utente non privilegiato sotto i quali sono in
+esecuzione i processi worker.
+Dopo aver riaperto con successo i file, il processo master chiude tutti
+i file aperti, ed invia un messaggio ai processi worker per chiedere loro
+di riaprire i file; i processi worker provvedono quindi immediatamente
+ad aprire i nuovi file ed a chiudere i vecchi.
+Come risultato, i vecchi file sono quasi immediatamente disponibili per
+eventuali attivita' successive, ad esempio per la compressione.
+</para>
+
+</section>
+
+
+<section id="upgrade" name="Aggiornamento al volo del file eseguibile">
+
+<para>
+Per poter aggiornare l'eseguibile del server, prima e' necessario
+porre il nuovo file al posto del vecchio; dopo, bisogna inviare al
+processo master il segnale USR2.
+Il processo master provvede a rinominare il file contenente il proprio
+ID di processo, aggiungendo il suffisso <path>.oldbin</path>, ad
+esempio <path>/usr/local/nginx/logs/nginx.pid.oldbin</path>,
+quindi avvia un nuovo file eseguibile, che a sua volta fa partire i
+propri processi worker:
+<programlisting>
+  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
+33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
+33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
+33135 33126 nobody   0.0  1380 kqread nginx: worker process (nginx)
+33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
+36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
+36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+</programlisting>
+</para>
+
+<!--
+
+<para>
+Il processo 36264 relativo ad un nuovo file eseguibile crea il proprio file
+con l'ID di processo, aggiungendo il suffisso <path>.newbin</path>,
+ad esempio <path>/usr/local/nginx/logs/nginx.pid.newbin</path>.
+</para>
+
+-->
+
+<para>
+A questo punto, sia i processi worker relativi al vecchio eseguibile, sia quelli
+relativi al nuovo, accettano richieste.
+Se al processo master e' inviato il segnale WINCH, tutti i relativi processi
+worker ricevono a loro volta un segnale che chiede loro l'arresto controllato,
+e quindi iniziano a spegnersi:
+<programlisting>
+  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
+33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
+33135 33126 nobody   0.0  1380 kqread nginx: worker process is shutting down (nginx)
+36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
+36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+</programlisting>
+</para>
+
+<para>
+<note>
+Quando su Linux si usa il metodo "rtsig", i nuovi processi potrebbero non
+accettare connessioni anche dopo che al processo master vecchio e' stato
+inviato il segnale WINCH.
+In tal caso, bisogna continuare ad inviare il segnale USR1 al nuovo processo
+master, sinche' i nuovi processi iniziano ad accettare connessioni.
+</note>
+</para>
+
+<para>
+In breve, i soli processi worker a processare le richieste saranno quelli nuovi:
+<programlisting>
+  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
+33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
+36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
+36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+</programlisting>
+</para>
+
+<para>
+Si noti che il vecchio processo master non chiude i suoi socket di ascolto,
+e che se necessario e' possibile chiedergli di riavviare i propri
+processi worker.
+Se per qualche ragione il nuovo file eseguibile non lavora correttamente,
+e' possibile procedere in due modi:
+<list type="bullet">
+
+<listitem>
+<para>
+inviare il segnale HUP al vecchio processo master.
+Il vecchio processo master provvedera' ad avviare
+nuovi processi worker, senza rileggere la configurazione.
+A questo punto, tutti i nuovi processi possono essere fermati
+in maniera controllata, inviando il segnale QUIT al nuovo
+processo master.
+</para>
+</listitem>
+
+<listitem>
+<para>
+inviare il segnale TERM al nuovo processo master.
+Tale processo inviare a sua volta un messaggio ai suoi processi
+worker che causera' la loro chiusura immediata.
+(Se per qualche ragione i nuovi processi non terminano, e'
+possibile inviare loro il segnale KILL per forzarne la chiusura.)
+Quando il nuovo processo master si e' chiuso, il vecchio processo
+master provvedera' immediatamente ad avviare nuovi processi worker.
+</para>
+</listitem>
+
+</list>
+
+</para>
+
+<para>
+Se il nuovo processo master termina, allora in vecchio processo master
+provvede a cancellare il suffisso <path>.oldbin</path> dal nome del file
+contenente l'ID del processo.
+</para>
+
+<para>
+Se l'aggiornamento ha successo, al vecchio processo master dovrebbe
+essere inviato il segnale QUIT, in maniera che rimangano solo i
+processi nuovi:
+<programlisting>
+  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
+36264     1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
+36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
+</programlisting>
+</para>
+
+<!--
+
+<para>
+Per completare il processo di aggiornamento, il file
+<path>/usr/local/nginx/logs/nginx.pid.newbin</path> dovrebbe essere rinominato
+<path>/usr/local/nginx/logs/nginx.pid</path>.
+</para>
+
+-->
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/debugging_log.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,84 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="Il log di debug"
+         link="/it/docs/debugging_log.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="1">
+
+
+<section>
+
+<para>
+Per poter abilitare il log di <literal>debug</literal>,
+nginx deve essere stato configurato appositamente in
+fase di compilazione:
+
+<programlisting>
+./configure --with-debug ...
+</programlisting>
+
+Dopo di cio', e' possibile configurare il livello di
+<literal>debug</literal> tramite la direttiva
+<link doc="ngx_core_module.xml" id="error_log"/>:
+
+<programlisting>
+error_log /path/to/log debug;
+</programlisting>
+
+La versione binaria di nginx per Windows e' sempre compilata
+con tale supporto, per cui in questo caso e' sufficiente
+configurare il livello di <literal>debug</literal>.
+</para>
+
+<para>
+Si tenga presente che ridefinire il log senza anche
+specificare il livello di <literal>debug</literal>
+causa la disabilitazione del log.
+Nell'esempio che segue, la ridefinizione del log nel livello
+<link doc="http/ngx_http_core_module.xml" id="server"/>
+disabilita il log di <literal>debug</literal> per tale server:
+<programlisting>
+error_log /path/to/log debug;
+
+http {
+    server {
+        error_log /path/to/log;
+        ...
+</programlisting>
+Se ridefinire il log risulta necessario, per non
+incorrere in questo problema bisogna indicare
+esplicitamente il livello di <literal>debug</literal>:
+<programlisting>
+error_log /path/to/log debug;
+
+http {
+    server {
+        error_log /path/to/log debug;
+        ...
+</programlisting>
+</para>
+
+<para>
+E' pure possibile abilitare il <literal>debug</literal> solo
+per <link doc="ngx_core_module.xml" id="debug_connection">
+indirizzi client specifici</link>:
+
+<programlisting>
+error_log /path/to/log;
+
+events {
+    debug_connection 192.168.1.1;
+    debug_connection 192.168.10.0/24;
+}
+</programlisting>
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/events.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,114 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="Metodi di processo delle connessioni"
+         link="/it/docs/events.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="2">
+
+<section>
+
+<para>
+nginx supporta diversi metodi di processo delle connessioni.
+La disponibilita' di un particolare metodo dipende dalla piattaforma usata;
+su piattaforme che supportano piu' di un metodo, nginx in genere
+e' in grado di selezionare automaticamente il metodo piu' efficiente.
+Comunque, se necessario, e' possibile scegliere esplicitamente il metodo
+di processo delle connessioni tramite la direttiva
+<link doc="ngx_core_module.xml" id="use"/>.
+</para>
+
+<para>
+I metodi di processo delle connessioni sono i seguenti:
+<list type="bullet">
+
+<listitem id="select">
+<para>
+<literal>select</literal>&mdash;metodo standard.
+Il relativo modulo e' compilato automaticamente se la piattaforma non
+rende possibile l'uso di metodi piu' efficienti.
+E' possibile usare i parametri di configurazione
+<literal>--with-select_module</literal> e
+<literal>--without-select_module</literal>
+per abilitare o disabilitare esplicitamente la compilazione di tale modulo.
+</para>
+</listitem>
+
+<listitem id="poll">
+<para>
+<literal>poll</literal>&mdash;metodo standard.
+Il relativo modulo e' compilato automaticamente se la piattaforma non
+rende possibile l'uso di metodi piu' efficienti.
+E' possibile usare i parametri di configurazione
+<literal>--with-poll_module</literal> e
+<literal>--without-poll_module</literal>
+per abilitare o disabilitare esplicitamente la compilazione di tale modulo.
+</para>
+</listitem>
+
+<listitem id="kqueue">
+<para>
+<literal>kqueue</literal>&mdash;metodo efficiente usato su
+FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0, e Mac OS X.
+</para>
+</listitem>
+
+<listitem id="epoll">
+<para>
+<literal>epoll</literal>&mdash;metodo efficiente usato su
+Linux 2.6+.
+<note>
+Alcune distribuzioni piu' vecchie, ad esempio SuSE 8.2, forniscono
+patch che rendono possibile l'uso di questo modulo su kernel 2.4.
+</note>
+</para>
+</listitem>
+
+<listitem id="rtsig">
+<para>
+<literal>rtsig</literal>&mdash;real time signals, metodo efficiente usato su
+Linux 2.2.19+.
+Per default, la coda di eventi del sistema e' limitata a 1024 segnali;
+su server particolarmente carichi puo' risultare necessario incrementare
+tale limite, intervenendo sul parametro del kernel
+<path>/proc/sys/kernel/rtsig-max</path> .
+Comunque, a partire da Linux 2.6.6-mm2 tale parametro non e' piu' disponibile
+e ciascun processo dispone della propria coda di eventi.
+La dimensione di ciascuna coda e' definita da <literal>RLIMIT_SIGPENDING</literal>
+e puo' essere modificata tramite il parametro
+<link doc="ngx_core_module.xml" id="worker_rlimit_sigpending"/>.
+</para>
+
+<para>
+In caso di overflow, nginx scarta del tutto la coda e passa all'uso del
+metodo di processo <literal>poll</literal> sinche' la situazione non
+torna normale.
+</para>
+</listitem>
+
+<listitem id="devpoll">
+<para>
+<literal>/dev/poll</literal>&mdash;metodo efficiente usato su
+Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+,
+e Tru64 UNIX 5.1A+.
+</para>
+</listitem>
+
+<listitem id="eventport">
+<para>
+<literal>eventport</literal>&mdash;event ports, metodo efficiente usato su
+Solaris 10.
+</para>
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/hash.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,54 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="Messa a punto degli hash"
+         link="/it/docs/hash.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="1">
+
+<section>
+
+<para>
+Per processare rapidamente insiemi di dati, quali ad esempio
+nomi di server, valori relativi alla direttiva
+<link doc="http/ngx_http_map_module.xml" id="map"/>,
+MIME type, stringhe di nomi di header di richiesta,
+ngnix usa tabelle di hash.
+Durante l'avvio ed in seguito ad ogni rilettura della configurazione,
+nginx seleziona la minore dimensione possibile delle tabelle
+di hash, tale che la dimensione del bucket che memorizza le chiavi
+con identico valore hash non superi il relativo parametro configurato
+(hash bucket size).
+La dimensione di una tabella e' espressa in bucket; tale dimensione
+viene regolata continuamente, sinche' la dimensione non eccede il
+valore configurato (hash max size).
+Molti hash dispongono di specifiche direttive che consentono la modifica
+di tali parametri; ad esempio, per l'hash dei nomi dei server esistono
+<link doc="http/ngx_http_core_module.xml" id="server_names_hash_bucket_size"/>
+e <link doc="http/ngx_http_core_module.xml" id="server_names_hash_max_size"/>.
+</para>
+
+<para>
+Il parametro hash bucket size e' allineato ad una dimensione
+multipla di quella di una linea di cache del processore utilizzato;
+nei moderni processori cio' riduce il numero di accessi alla memoria
+e quindi il tempo necessario a ricercare la chiave di un hash.
+Se la dimensione del bucket hash e' pari a quella di una linea di
+cache, allora il numero di accessi alla memoria durante la ricerca di
+una chiave sara' nel peggiore dei casi pari a due &mdash;uno per l'indirizzo
+del bucket, l'altro durante la ricerca della chiave nel bucket.
+Per tale ragione, se nginx mostra un messaggio che suggerisce
+l'incremento o della dimensione massima dell'hash oppure della
+dimensione del bucket hash, e' preferibile intervenire anzitutto
+sul primo dei due parametri e non modificare per quanto possibile
+il secondo.
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/http/configuring_https_servers.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,521 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="Configurazione di server HTTPS"
+         link="/it/docs/http/configuring_https_servers.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="6"
+         author="Igor Sysoev"
+         editor="Brian Mercer">
+
+<section>
+
+<para>
+Per configurare un server HTTPS, bisogna configurare il parametro
+<literal>ssl</literal> nel
+<link doc="ngx_http_core_module.xml" id="listen">socket in ascolto</link>
+del blocco <link doc="ngx_http_core_module.xml" id="server"/>,
+e specificare dove sono i file del certificato del server e della relativa
+chiave private:
+
+<programlisting>
+server {
+    listen              443 <b>ssl</b>;
+    server_name         www.example.com;
+    ssl_certificate     <b>www.example.com.crt</b>;
+    ssl_certificate_key <b>www.example.com.key</b>;
+    ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
+    ssl_ciphers         HIGH:!aNULL:!MD5;
+    ...
+}
+</programlisting>
+
+Il certificato del server e' pubblico: e' inviato a tutti i client che
+si connettono al server; la chiave privata al contrario non e' pubblica,
+e dovrebbe essere salvata in un file con restrizioni d'accesso, e
+comunque non leggibile dal processo master di nginx.
+In alternativa, la chiave privata puo' essere salvata nel medesimo file
+del certificato:
+
+<programlisting>
+    ssl_certificate     www.example.com.cert;
+    ssl_certificate_key www.example.com.cert;
+</programlisting>
+
+pure in questo caso i diritti d'accesso al file dovrebbero essere ristretti.
+Anche quando certificato e chiave privata sono salvati entrambi
+in un unico file, solo il certificato e' inviato al client.
+</para>
+
+<para>
+Le direttive <link doc="ngx_http_ssl_module.xml" id="ssl_protocols"/> e
+<link doc="ngx_http_ssl_module.xml" id="ssl_ciphers"/> possono essere usate
+per limitare l'uso alle sole versioni e cifrature forti di SSL/TLS nelle
+connessioni.
+nginx usa per default “<literal>ssl_protocols SSLv3 TLSv1</literal>” e
+“<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>” sin dalla versione 1.0.5,
+per cui una configurazione esplicita ha senso solo per le versioni di ngnix
+piu' vecchie. Dalle versioni 1.1.13 e 1.0.12 nginx usa per default
+“<literal>ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2</literal>”.
+</para>
+
+<para>
+La modalita' di cifratura CBC e' potenzialmente vulnerabile ad una serie
+di attacchi, in particolare ad un attacco BEST (vedi
+<link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>).
+La configurazione della cifratura puo' essere modificata in maniera da
+utilizzare RC4-SHA:
+
+<programlisting>
+    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
+    ssl_prefer_server_ciphers on;
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="optimization" name="Ottimizzazione di server HTTPS">
+
+<para>
+Le operazioni SSL utilizzano pesantemente la CPU. Su sistemi
+multiprocessore e' bene avviare processi worker in numero almeno pari a
+quello dei core.
+L'operazione piu' gravosa per la CPU e' l'handshake SSL.
+Ci sono due modi per minimizzare il numero di tali operazioni per client:
+il primo consiste nell'abilitare connessioni keepalive per inviare diverse
+richieste tramite un'unica connessione; il secondo prevede di riutilizzare
+i parametri della sessione SSL in maniera tale da evitare l'handshake SSL
+per connessioni parallele e susseguenti.
+Le sessioni sono salvate in una cache di sessione SSL, condivisa fra i
+worker e configurata dalla direttiva
+<link doc="ngx_http_ssl_module.xml" id="ssl_session_cache"/>.
+
+Un megabyte di cache contiene circa 4000 sessioni. Il timeout di default della
+cache e' di 5 minuti; puo' essere aumentato intervenendo sulla direttiva
+<link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>.
+Segue una configurazione di esempio ottimizzata per un sistema multicore con
+10 megabyte di cache di sessione condivisa:
+
+<programlisting>
+<b>worker_processes auto</b>;
+
+http {
+    <b>ssl_session_cache   shared:SSL:10m</b>;
+    <b>ssl_session_timeout 10m</b>;
+
+    server {
+        listen              443 ssl;
+        server_name         www.example.com;
+        <b>keepalive_timeout   70</b>;
+
+        ssl_certificate     www.example.com.crt;
+        ssl_certificate_key www.example.com.key;
+        ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
+        ssl_ciphers         HIGH:!aNULL:!MD5;
+        ...
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="chains" name="Catene di certificati SSL">
+
+<para>
+Capita talvolta che alcuni certificati server firmati da autorita' di
+certificazione ben note siano tranquillamente accettati da alcuni browser,
+ma mostrino invece problemi con altri. Cio' succede quando' l'autorita'
+emittente ha firmato il certificato usandone uno intermedio che non e'
+presente nell'elenco delle autorita' di certificazione distribuito con
+uno specifico browser.
+In tal caso l'autorita' fornisce un gruppo di certificati che dovrebbero
+essere concatenati al certificato server firmato.
+Il certificato server deve comparire prima dei certificati concatenati
+nel file risultante:
+
+<programlisting>
+$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
+</programlisting>
+
+Il file che ne deriva va usato con la  direttiva
+<link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>:
+
+<programlisting>
+server {
+    listen              443 ssl;
+    server_name         www.example.com;
+    ssl_certificate     www.example.com.chained.crt;
+    ssl_certificate_key www.example.com.key;
+    ...
+}
+</programlisting>
+
+Se il certificato server ed il gruppo di certificati sono stati concatenati
+nell'ordine sbagliato, nginx non riuscira' a partire e mostrera' il
+seguente messaggio di errore:
+
+<programlisting>
+SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
+   (SSL: error:0B080074:x509 certificate routines:
+    X509_check_private_key:key values mismatch)
+</programlisting>
+
+dato che nginx ha tentato di usare la chiave privata non con il certificato
+server ma con il primo certificato del gruppo.
+</para>
+
+<para>
+Di solito i browser salvano i certificati intermedi che ricevono se sono
+firmati da autorita' di certificazione riconosciute, per cui browser molto
+usati potrebbero gia' avere i certificati intermedi richiesti, e quindi
+non avere problemi anche quando ricevono un certificato privo della
+relativa concatenazione di certificati.
+Comunque, per assicurare che il server invii la concatenazione di certificati
+completa, e' possibile usare da linea di comando il programma
+<command>openssl</command>, ad esempio:
+
+<programlisting>
+$ openssl s_client -connect www.godaddy.com:443
+...
+Certificate chain
+ 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
+     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
+     /OU=MIS Department/<b>CN=www.GoDaddy.com</b>
+     /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
+   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
+     /OU=http://certificates.godaddy.com/repository
+     /CN=Go Daddy Secure Certification Authority
+     /serialNumber=07969287
+ 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
+     /OU=http://certificates.godaddy.com/repository
+     /CN=Go Daddy Secure Certification Authority
+     /serialNumber=07969287
+   i:/C=US/O=The Go Daddy Group, Inc.
+     /OU=Go Daddy Class 2 Certification Authority
+ 2 s:/C=US/O=The Go Daddy Group, Inc.
+     /OU=Go Daddy Class 2 Certification Authority
+   i:/L=ValiCert Validation Network/O=<b>ValiCert, Inc.</b>
+     /OU=ValiCert Class 2 Policy Validation Authority
+     /CN=http://www.valicert.com//emailAddress=info@valicert.com
+...
+</programlisting>
+
+In questo esempio, il soggetto (“<i>s</i>”, vale a dire "<i>subject</i>")
+del certificato server #0 <literal>www.GoDaddy.com</literal> e' firmato da
+un emittente (“<i>i</i>”, vale a dire "<i>issuer</i>") che a sua volta e'
+il soggetto del certificato #1, il quale e' firmato da un emittente che e'
+il soggetto del certificato #2, che e' finalmente firmato dalla autorita'
+di certificazione ben nota <i>ValiCert, Inc.</i>, il cui certificato e'
+presente nella base dati precaricata del browser
+("che al mercato mio padre compro'").
+</para>
+
+<para>
+Se il gruppo di certificati non fosse stato aggiunto, sarebbe stato
+visualizzato il solo certificato #0.
+</para>
+
+</section>
+
+
+<section id="single_http_https_server" name="Un server unico per HTTP e HTTPS">
+
+<para>
+E' possibile configurare un singolo server che tratti sia richieste HTTP,
+sia richieste HTTPS:
+
+<programlisting>
+server {
+    listen              80;
+    listen              443 ssl;
+    server_name         www.example.com;
+    ssl_certificate     www.example.com.crt;
+    ssl_certificate_key www.example.com.key;
+    ...
+}
+</programlisting>
+
+<note>
+Prima della versione 0.7.14, SSL non poteva essere abilitato
+selettivamente per singoli socket in ascolto, come nell'esempio
+precedente: SSL poteva solo essere abilitato per l'intero server,
+usando la direttiva <link doc="ngx_http_ssl_module.xml" id="ssl"/>,
+e rendendo quindi impossibile la configurazione di un server
+unico per HTTP e HTTPS.
+Il parametro <literal>ssl</literal> della direttiva
+<link doc="ngx_http_core_module.xml" id="listen"/> e' stato aggiunto
+per risolvere questo problema. L'uso della direttiva
+<link doc="ngx_http_ssl_module.xml" id="ssl"/>
+e' pertanto sconsigliato nelle versioni recenti.
+</note>
+</para>
+
+</section>
+
+
+<section id="name_based_https_servers" name="Server HTTPS name-based">
+
+<para>
+Quando si configurano due o piu' server HTTPS in ascolto su un singolo
+indirizzo IP, sorge spesso un problema:
+
+<programlisting>
+server {
+    listen          443 ssl;
+    server_name     www.example.com;
+    ssl_certificate www.example.com.crt;
+    ...
+}
+
+server {
+    listen          443 ssl;
+    server_name     www.example.org;
+    ssl_certificate www.example.org.crt;
+    ...
+}
+</programlisting>
+
+Con questa configurazione un browser riceve il certificato del server di default,
+vale a dire <literal>www.example.com</literal>, indipendentemente da quale sia
+il nome del server richiesto. Cio' e' causato dal comportamento del protocollo
+SSL: la connessione SSL si stabilisce prima che il browser invii una richiesta
+HTTP, percio' quando nginx ancora non sa quale sara' il nome del server richiesto;
+per tale ragione, non puo' fare altro che offrire il certificato del server di default.
+</para>
+
+<para>
+Il metodo classico per risolvere questo problema consiste nell'assegnare
+un indirizzo IP distinto a ciascun server HTTPS:
+
+<programlisting>
+server {
+    listen          192.168.1.1:443 ssl;
+    server_name     www.example.com;
+    ssl_certificate www.example.com.crt;
+    ...
+}
+
+server {
+    listen          192.168.1.2:443 ssl;
+    server_name     www.example.org;
+    ssl_certificate www.example.org.crt;
+    ...
+}
+</programlisting>
+</para>
+
+
+<section id="certificate_with_several_names"
+         name="Un certificato SSL con molti nomi">
+
+<para>
+Ci sono altre maniere tramite cui condividere un singolo indirizzo IP
+fra molti server HTTPS, tutte comunque non prive di problemi.
+Ad esempio, e' possibile usare un certificato con diversi nomi di server
+nel campo SubjectAltName, per esempio
+<literal>www.example.com</literal> and <literal>www.example.org</literal>,
+tuttavia la lunghezza del campo SubjectAltName e' limitata.
+</para>
+
+<para>
+Un'altra tecnica prevede l'uso di un certificato il cui nome e' definito con
+caratteri jolly, per esempio <literal>*.example.org</literal>.
+Un certificato con caratteri jolly va bene per tutti i sottodomini del
+dominio specificato, ma per un solo livello: in questo caso ad esempio
+verra' riconosciuta corrispondenza con <literal>www.example.org</literal>,
+ma non con <literal>example.org</literal> e <literal>www.sub.example.org</literal>.
+I due metodi mostrati possono essere combinati: nel campo SubjectAltName
+un certificato puo' contenere sia nomi esatti sia nomi con caratteri jolly,
+ad esempio <literal>example.org</literal> e <literal>*.example.org</literal>.
+</para>
+
+<para>
+Nel caso in cui si usi un certificato con nomi multipli, e' bene
+indicare la posizione del relativo file e della chiave nel livello
+<i>http</i> della configurazione, in maniera da avere una singola
+copia in memoria da far ereditare a tutti i server:
+
+<programlisting>
+ssl_certificate     common.crt;
+ssl_certificate_key common.key;
+
+server {
+    listen          443 ssl;
+    server_name     www.example.com;
+    ...
+}
+
+server {
+    listen          443 ssl;
+    server_name     www.example.org;
+    ...
+}
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="sni" name="Server Name Indication">
+
+<para>
+Una soluzione piu' generale per l'uso di server HTTPS multipli su un singolo
+indirizzo IP e' data dalla
+<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">estensione
+TLS Server Name Indication</link> (SNI, RFC 6066), che consente ad un
+browser di indicare il nome del server richiesto durante l'handshake SSL e,
+percio', permette al server di sapere quale certificato dovrebbe essere
+usato durante la connessione. Purtroppo, SNI ha un supporto piuttosto
+limitato nei browser; al momento e' supportato a partire dalle seguenti
+versioni:
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+Opera 8.0;
+</listitem>
+
+<listitem>
+MSIE 7.0 (ma solo su Windows Vista o superiore);
+</listitem>
+
+<listitem>
+Firefox 2.0 e altri browser che usano Mozilla Platform rv:1.8.1;
+</listitem>
+
+<listitem>
+Safari 3.2.1 (la versione per Windows supporta SNI su Vista o superiore);
+</listitem>
+
+<listitem>
+Chrome (la versione per Windows supporta SNI su Vista o superiore).
+</listitem>
+
+</list>
+<note>
+Con SNI e' possibile passare solo nomi di dominio, tuttavia alcuni browser
+potrebbero erroneamente consentire di passare come nome anche l'indirizzo
+IP del server.
+E' bene comunque non fare affidamento su questo comportamento.
+</note>
+</para>
+
+<para>
+Per poter usare SNI in nginx, e' necessario che sia supportato sia nella
+libreria OpenSSL con cui il binario e' stato compilato, sia nella
+libreria a cui e' linkato dinamicamente in esecuzione.
+OpenSSL supporta SNI sin dalla versione 0.9.8f, a patto che sia stata
+compilata con l'opzione di configurazione <nobr>“--enable-tlsext”</nobr>;
+dalla versione 0.9.8j tale opzione e' abilitata per default.
+Se nginx e' compilato con il supporto a SNI, allora l'esecuzione con
+il parametro “-V” mostra:
+
+<programlisting>
+$ nginx -V
+...
+TLS SNI support enabled
+...
+</programlisting>
+
+Di contro, se nginx e' stato compilato con il supporto a SNI, ma la libreria
+OpenSSL a cui e' linkato dinamicamente ne e' priva, viene mostrato:
+
+<programlisting>
+nginx was built with SNI support, however, now it is linked
+dynamically to an OpenSSL library which has no tlsext support,
+therefore SNI is not available
+</programlisting>
+</para>
+
+</section>
+
+</section>
+
+
+<section id="compatibility" name="Compatibilita'">
+
+<para>
+<list type="bullet">
+
+<listitem>
+Il parametro “-V” mostra lo stato del supporto a SNI
+dalla versione 0.8.21 e 0.7.62 in poi.
+</listitem>
+
+<listitem>
+Il parametro <literal>ssl</literal> della direttiva
+<link doc="ngx_http_core_module.xml" id="listen"/>
+e' supportato
+dalla versione 0.7.14 in poi;
+prima della versione 0.8.21 poteva essere specificato solo
+insieme al parametro <literal>default</literal>.
+</listitem>
+
+<listitem>
+SNI e' supportato
+dalla versione 0.5.32 in poi.
+</listitem>
+
+<listitem>
+La cache condivisa di sessione SSL e' supportata
+dalla versione 0.5.6 in poi.
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+Versioni 0.7.65, 0.8.19 e successive: i protocolli SSL default sono SSLv2, TLSv1,
+e TLSv1.2 (se supportati dalla libreria OpenSSL).
+</listitem>
+
+<listitem>
+Versioni 0.7.64, 0.8.18 e precedenti: i protocolli SSL default sono SSLv2,
+SSLv3, e TLSv1.
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+Versioni 1.0.5 e successive: i sistemi di cifratura SSL default sono
+“<literal>HIGH:!aNULL:!MD5</literal>”.
+</listitem>
+
+<listitem>
+Versioni 0.7.65, 0.8.20 e successive: i sistemi di cifratura SSL default sono
+“<literal>HIGH:!ADH:!MD5</literal>”.
+</listitem>
+
+<listitem>
+Versione 0.8.19: i sistemi di cifratura SSL default sono
+“<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</literal>”.
+</listitem>
+
+<listitem>
+Versioni 0.7.64, 0.8.18 e precedenti: i sistemi di cifratura SSL default sono<br/>
+“<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</literal>”.
+</listitem>
+
+</list>
+</para>
+
+
+</section>
+
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/http/request_processing.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,302 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="Come nginx processa una richiesta"
+         link="/it/docs/http/request_processing.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="1"
+         author="Igor Sysoev"
+         editor="Brian Mercer">
+
+<section name="Server virtuali name-based">
+
+<para>
+La prima cosa che nginx fa e' decidere quale <i>server</i> deve
+processare la richiesta. Si consideri una semplice configurazione
+in cui tutti i tre server virtuali sono in ascolto sulla porta *:80 :
+<programlisting>
+server {
+    listen      80;
+    server_name example.org www.example.org;
+    ...
+}
+
+server {
+    listen      80;
+    server_name example.net www.example.net;
+    ...
+}
+
+server {
+    listen      80;
+    server_name example.com www.example.com;
+    ...
+}
+</programlisting>
+
+</para>
+
+<para>
+In questa configurazione nginx verifica solo il campo <header>Host</header>
+dell'header di richiesta, per determinare a quale server la richiesta debba
+essere assegnata.
+Se il suo valore non corrisponde con quello di alcun nome di server,
+oppure se la richiesta semplicemente non contiene tale campo dell'header,
+allora nginx assegna la richiesta al server di default per la relativa porta.
+Nella configurazione precedente, il server di default e' il primo&mdash;si
+tratta del comportamento standard di nginx.
+E' anche possibile indicare esplicitamente il server di default, tramite il
+parametro <literal>default_server</literal> nella direttiva
+<link doc="ngx_http_core_module.xml" id="listen"/> :
+<programlisting>
+server {
+    listen      80 <b>default_server</b>;
+    server_name example.net www.example.net;
+    ...
+}
+</programlisting>
+
+<note>
+Il parametro <literal>default_server</literal> e' disponibile a partire dalla
+versione 0.8.21 di nginx.
+Nelle versioni precedenti bisogna usare invece il parametro
+<literal>default</literal>.
+</note>
+Si noti che il server di default e' una proprieta' della porta in ascolto,
+e non del nome del server; l'argomento sara' ripreso in seguito.
+</para>
+
+</section>
+
+
+<section id="how_to_prevent_undefined_server_names"
+         name="Come evitare di processare richieste in cui il nome del server non e' definito">
+
+<para>
+Se si desidera che le richieste prive dell'header <header>Host</header>
+non siano processate, e' possibile definire un server che si limita a scartarle:
+<programlisting>
+server {
+    listen      80;
+    server_name "";
+    return      444;
+}
+</programlisting>
+In questo caso il nome del server e' definito con una stringa vuota,
+la quale corrispondera' a tutte le richieste prive del campo
+<header>Host</header> dell'header; per chiudere la connessione nginx
+restituisce il codice 444 (non standard).
+<note>
+A partire dalla versione 0.8.48 quella descritta e' la configurazione
+default per i nomi di server, per cui e' possibile omettere
+<literal>server_name ""</literal>.
+Nelle versioni precedenti, come nome del server di default si utilizzava
+l'<i>hostname</i> della macchina.
+</note>
+</para>
+
+</section>
+
+
+<section id="mixed_name_ip_based_servers"
+         name="Configurazione mista di server virtuali name-based e IP-based">
+
+<para>
+Una configurazione piu' complessa prevede vari server virtuali
+in ascolto su indirizzi differenti:
+<programlisting>
+server {
+    listen      192.168.1.1:80;
+    server_name example.org www.example.org;
+    ...
+}
+
+server {
+    listen      192.168.1.1:80;
+    server_name example.net www.example.net;
+    ...
+}
+
+server {
+    listen      192.168.1.2:80;
+    server_name example.com www.example.com;
+    ...
+}
+</programlisting>
+In tale configurazione nginx dapprima confronta l'indirizzo IP
+e la porta della richiesta con le direttive
+<link doc="ngx_http_core_module.xml" id="listen"/> dei blocchi
+<link doc="ngx_http_core_module.xml" id="server"/>;
+quindi, per ciascun blocco per cui c'e' corrispondenza, nginx confronta
+il campo <header>Host</header> dell'header della richiesta con i
+valori <link doc="ngx_http_core_module.xml" id="server_name"/> del blocco.
+Se il nome del server non e' presente in alcun blocco, la richiesta
+viene processata dal server di default.
+Ad esempio, una richiesta per <literal>www.example.com</literal>
+ricevuta sulla porta 192.168.1.1:80, sara' processata dal server di
+default di 192.168.1.1:80, vale a dire dal primo server, in quanto non
+c'e' alcun nome <literal>www.example.com</literal> definito per tale
+combinazione di indirizzo e porta.
+</para>
+
+<para>
+Si precisa nuovamente che il server di default e' una proprieta' di
+indirizzo e porta in ascolto, e che e' possibile definire server di
+default differenti per combinazioni differenti di indirizzo e porta:
+<programlisting>
+server {
+    listen      192.168.1.1:80;
+    server_name example.org www.example.org;
+    ...
+}
+
+server {
+    listen      192.168.1.1:80 <b>default_server</b>;
+    server_name example.net www.example.net;
+    ...
+}
+
+server {
+    listen      192.168.1.2:80 <b>default_server</b>;
+    server_name example.com www.example.com;
+    ...
+}
+</programlisting>
+
+</para>
+
+</section>
+
+
+<section id="simple_php_site_configuration"
+         name="Configurazione per un semplice sito PHP">
+
+<para>
+Nel seguito si analizza come nginx scelga la <i>location</i> per
+processare una richiesta nel caso di un tipico, semplice sito PHP:
+<programlisting>
+server {
+    listen      80;
+    server_name example.org www.example.org;
+    root        /data/www;
+
+    location / {
+        index   index.html index.php;
+    }
+
+    location ~* \.(gif|jpg|png)$ {
+        expires 30d;
+    }
+
+    location ~ \.php$ {
+        fastcgi_pass  localhost:9000;
+        fastcgi_param SCRIPT_FILENAME
+                      $document_root$fastcgi_script_name;
+        include       fastcgi_params;
+    }
+}
+</programlisting>
+
+</para>
+
+<para>
+Per prima cosa nginx individua fra tutte le location definite da una
+stringa quella con il prefisso specifico piu' lungo (l'ordine con cui
+sono elencate non e' rilevante); nella configurazione precedente il
+solo prefisso definito e' “<literal>/</literal>”, che trova
+corrispondenza in qualsiasi richiesta e che quindi verra' comunque
+preso in considerazione, come ultima risorsa.
+Successivamente, nginx analizza le location definite tramite una
+espressione regolare, fermandosi appena ne individua una che
+corrisponde (in questo caso l'ordine in cui sono inserite nel file
+di configurazione e' rilevante in quanto nginx parte dalla prima e le
+analizza una dopo l'altra). La prima location individuata fra quelle
+definite come espressione regolare e' quella prescelta; se non ce n'e'
+nessuna, nginx ripiega su quella individuata al passo precedente tramite
+il prefisso.
+
+</para>
+
+<para>
+Notare che tutti i tipi di location sono confrontati con il solo URI
+della linea di richiesta, senza argomenti;
+cio' e' dovuto al fatto che gli argomenti nella stringa di richiesta
+possono essere inviati in vari modi, ad esempio:
+<programlisting>
+/index.php?user=john&amp;page=1
+/index.php?page=1&amp;user=john
+</programlisting>
+Inoltre, nella stringa di richiesta e' possibile scrivere qualsiasi cosa:
+<programlisting>
+/index.php?page=1&amp;something+else&amp;user=john
+</programlisting>
+
+</para>
+
+<para>
+Seguono alcuni esempi di processo di richieste in base alla
+configurazione precedente:
+<list type="bullet" compact="no">
+
+<listitem>
+Una richiesta “<literal>/logo.gif</literal>” corrisponde al prefisso
+di location “<literal>/</literal>”, ma anche all'espressione regolare
+“<literal>\.(gif|jpg|png)$</literal>”, per cui si utilizzera' quest'ultima
+corrispondenza in quanto, come spiegato in precedenza, le espressioni
+regolari hanno sempre priorita' sulle stringhe fisse.
+Usando la direttiva “<literal>root&nbsp;/data/www</literal>” la richiesta
+e' mappata sul file <path>/data/www/logo.gif</path> , che quindi e' inviato
+al client.
+</listitem>
+
+<listitem>
+Una richiesta “<literal>/index.php</literal>” corrisponde sia al prefisso
+“<literal>/</literal>” sia all'espressione regolare
+“<literal>\.(php)$</literal>”, per cui sara' processata da quest'ultima
+sezione della configurazione, e la richiesta sara' inoltrata al server
+FastCGI in ascolto su localhost:9000.
+La direttiva
+<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_param"/>
+imposta il parametro FastCGI
+<literal>SCRIPT_FILENAME</literal> a “<literal>/data/www/index.php</literal>”,
+ed il server FastCGI esegue il file.
+La variabile <var>$document_root</var> contiene il valore della direttiva
+<link doc="ngx_http_core_module.xml" id="root"/>, e la variabile
+<var>$fastcgi_script_name</var> il valore della richiesta URI, vale a dire
+“<literal>/index.php</literal>”.
+</listitem>
+
+<listitem>
+Una richiesta “<literal>/about.html</literal>” corrisponde al solo prefisso
+“<literal>/</literal>”, per cui sara' processata da questa sezione.
+La direttiva “<literal>root /data/www</literal>” mappa la richiesta sul file
+<path>/data/www/about.html</path>, che e' inviato al client.
+</listitem>
+
+<listitem>
+Una richiesta “<literal>/</literal>” e' processata in maniera piuttosto
+complessa. Corrisponde al solo prefisso “<literal>/</literal>”, per cui e'
+processata dalla relativa sezione; la direttiva
+<link doc="ngx_http_index_module.xml" id="index"/>,
+in accordo ai propri parametri e alla direttiva
+“<literal>root /data/www</literal>”, verifica la presenza di eventuali file index.
+Se il file <path>/data/www/index.html</path> non esiste, ma esiste invece il
+file <path>/data/www/index.php</path> , allora la direttiva esegue una
+redirezione interna su “<literal>/index.php</literal>”, e nginx ricerca
+nuovamente le location, come se si trattasse di una richiesta del client.
+Come visto in precedenza, alla fine la richiesta rediretta e' processata
+dal server FastCGI.
+</listitem>
+
+</list>
+
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/http/server_names.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,513 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="I nomi dei server"
+         link="/it/docs/http/server_names.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="2"
+         author="Igor Sysoev"
+         editor="Brian Mercer">
+
+
+<section>
+
+<para>
+I nomi dei server, definiti usando la direttiva
+<link doc="ngx_http_core_module.xml" id="server_name"/>,
+determinano quale blocco
+<link doc="ngx_http_core_module.xml" id="server"/>
+viene usato per una data richiesta (per approfondire vedi
+"<link doc="request_processing.xml"/>”).
+
+I nomi possono essere definiti tramite una stringa determinata,
+oppure con caratteri jolly, oppure ancora tramite espressioni regolari:
+
+<programlisting>
+server {
+    listen       80;
+    server_name  example.org  www.example.org;
+    ...
+}
+
+server {
+    listen       80;
+    server_name  *.example.org;
+    ...
+}
+
+server {
+    listen       80;
+    server_name  mail.*;
+    ...
+}
+
+server {
+    listen       80;
+    server_name  ~^(?&lt;user&gt;.+)\.example\.net$;
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+Nel corso della ricerca di un server virtuale name-based, se il nome corrisponde
+a piu' di una delle definizioni, ad esempio sia a nomi definiti tramite
+caratteri jolly che a nomi definiti tramite espressioni regolari, verra' scelta
+la prima variante individuata, secondo il seguente ordine di precedenza decrescente:
+<list type="enum">
+
+<listitem>
+nome esatto
+</listitem>
+
+<listitem>
+fra quelli definiti con caratteri jolly, il piu' lungo nome che comincia per
+asterisco, ad esempio “<literal>*.example.org</literal>”
+</listitem>
+
+<listitem>
+fra quelli definiti con caratteri jolly, il piu' lungo nome che termina per
+asterisco, ad esempio “<literal>mail.*</literal>”
+</listitem>
+
+<listitem>
+fra quelli definiti come espressioni regolare, il primo corrispondente
+(in base all'ordine con cui compaiono nel file di configurazione)
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="wildcard_names"
+        name="Nomi con caratteri jolly">
+
+<para>
+Un nome con caratteri jolly puo' contenere un asterisco solo all'inizio
+o alla fine del nome, e solo accanto ad un punto; ad esempio, i nomi
+“<literal>www.*.example.org</literal>”
+e “<literal>w*.example.org</literal>” non sono validi (pero' e'
+possibile definirli tramite espressioni regolari, per esempio in questo
+caso “<literal>~^www\..+\.example\.org$</literal>” e
+“<literal>~^w.*\.example\.org$</literal>”).
+Un asterisco puo' corrispondere a piu' parti di un nome:
+“<literal>*.example.org</literal>” corrisponde non solo a
+<literal>www.example.org</literal> ma anche a
+<literal>www.sub.example.org</literal>.
+</para>
+
+<para>
+E' possibile definire un nome speciale nella forma
+“<literal>.example.org</literal>”, che corrisponde sia al nome esatto
+“<literal>example.org</literal>” sia al nome con caratteri jolly
+“<literal>*.example.org</literal>”.
+</para>
+
+</section>
+
+
+<section id="regex_names"
+        name="Nomi con espressioni regolari">
+
+<para>
+Le espressioni regolari usate da nginx sono compatibili con quelle usate
+dal linguaggio di programmazione Perl (PCRE).
+Per usare una espressione regolare, il nome del server deve iniziare con
+il carattere tilde:
+
+<programlisting>
+server_name  ~^www\d+\.example\.net$;
+</programlisting>
+
+altrimenti viene considerato e trattato come un nome esatto, oppure,
+se l'espressione contiene un asterisco, come un nome con caratteri jolly
+(e molto probabilmente come uno non valido).
+E' importante non dimenticare i caratteri ancora “<literal>^</literal>” e
+“<literal>$</literal>”: non sono necessari dal punto di vista sintattico,
+ma lo sono da quello logico.
+Si noti inoltre che i caratteri punto nei nomi di dominio sono definiti
+facendoli precedere da “<literal>\</literal>”.
+Una espressione regolare contenente i caratteri “<literal>{</literal>” e
+“<literal>}</literal>”, deve essere racchiusa fra doppi apici:
+
+<programlisting>
+server_name  "~^(?&lt;name&gt;\w\d<b>{</b>1,3<b>}</b>+)\.example\.net$";
+</programlisting>
+
+altrimenti nginx non sara' in grado di avviarsi e mostrera' l'errore:
+
+<programlisting>
+directive "server_name" is not terminated by ";" in ...
+</programlisting>
+
+La sezione catturata di una espressione regolare che definisce un nome
+puo' essere usata in seguito come una variabile:
+
+<programlisting>
+server {
+    server_name   ~^(www\.)?(<b>?&lt;domain&gt;</b>.+)$;
+
+    location / {
+        root   /sites/<b>$domain</b>;
+    }
+}
+</programlisting>
+
+La libreria PCRE supporta sezioni catturate di nomi tramite la seguente sintassi:
+
+<table note="yes">
+
+<tr>
+<td><literal>?&lt;<value>nome</value>&gt;</literal></td>
+<td>Sintassi compatibile con Perl 5.10, supportata da PCRE-7.0 in poi</td>
+</tr>
+
+<tr>
+<td><literal>?'<value>nome</value>'</literal></td>
+<td>Sintassi compatibile con Perl 5.10, supportata da PCRE-7.0 in poi</td>
+</tr>
+
+<tr>
+<td><literal>?P&lt;<value>nome</value>&gt;</literal></td>
+<td>Sintassi compatibile con Python, supportata da PCRE-4.0 in poi</td>
+</tr>
+
+</table>
+
+Quando nginx non riesce ad avviarsi e mostra il seguente messaggio d'errore:
+
+<programlisting>
+pcre_compile() failed: unrecognized character after (?&lt; in ...
+</programlisting>
+
+significa che la libreria PCRE e' troppo vecchia, per cui e' bene provare
+ad usare invece la sintassi:
+“<literal>?P&lt;<value>name</value>&gt;</literal>”.
+E' possibile riferirsi a sezioni catturate anche usando cifre:
+
+<programlisting>
+server {
+    server_name   ~^(www\.)?(.+)$;
+
+    location / {
+        root   /sites/<b>$2</b>;
+    }
+}
+</programlisting>
+
+Comunque, tale uso dovrebbe essere limitato ai casi piu' semplici (come
+ad esempio quello appena mostrato), dato che i riferimenti con cifra
+possono essere sovrascritti facilmente.
+</para>
+
+
+</section>
+
+
+<section id="miscellaneous_names"
+        name="Nomi vari">
+
+<para>
+Alcuni nomi di server sono trattati in maniera speciale.
+</para>
+
+<para>
+Se si desidera che le richieste prive del campo <header>Host</header>
+dell'header siano processato in un blocco
+<link doc="ngx_http_core_module.xml" id="server"/>
+che non e' quello di default, e' necessario specificare un nome vuoto:
+
+<programlisting>
+server {
+    listen       80;
+    server_name  example.org  www.example.org  "";
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+
+Se in un blocco <link doc="ngx_http_core_module.xml" id="server"/>
+non e' specificato alcun <link doc="ngx_http_core_module.xml" id="server_name"/>,
+allora nginx usa il nome vuoto come nome del server.
+<note>
+sino alla versione 0.8.48, in questi casi nginx usava l'hostname della
+macchina come nome del server.
+</note>
+</para>
+
+<para>
+Se il nome del server e' definito come “<literal>$hostname</literal>” (0.9.4),
+il nome del server effettivamente usato e' l'hostname della macchina.
+</para>
+
+<para>
+Se viene fatta una richiesta usando l'indirizzo IP invece di un nome di server,
+il campo <header>Host</header> dell'header di richiesta conterra' l'indirizzo IP,
+e la richiesta potra' essere processata usando l'indirizzo IP come nome del server:
+
+<programlisting>
+server {
+    listen       80;
+    server_name  example.org
+                 www.example.org
+                 ""
+                 <b>192.168.1.1</b>
+                 ;
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+In molti esempi di configurazione di un server catch-all e' spesso possibile
+notare l'uso di uno strano nome
+“<literal>_</literal>”:
+
+<programlisting>
+server {
+    listen       80  default_server;
+    server_name  _;
+    return       444;
+}
+</programlisting>
+
+Tale nome non ha niente di speciale, si tratta di un nome qualsiasi,
+scelto piu' o meno a caso fra quelli non validi come nome di dominio.
+Altri esempi di nomi non validi che sono talvolta pure usati sono
+“<literal>--</literal>” e “<literal>!@#</literal>”.
+</para>
+
+<para>
+Sino alla versione 0.6.25 nginx supportava il nome speciale
+“<literal>*</literal>”, che e' stato spesso interpretato erroneamente
+come un nome, non valido, per un server catch-all.
+In effetti, non si e' mai trattato di un nome per un server catch-all o
+di un nome con caratteri jolly: piuttosto, serviva a fornire la funzionalita'
+attualmente affidata alla direttiva
+<link doc="ngx_http_core_module.xml" id="server_name_in_redirect"/>.
+Il nome speciale “<literal>*</literal>” e' attualmente sconsigliato,
+ed e' considerato preferibile l'uso della direttiva
+<link doc="ngx_http_core_module.xml" id="server_name_in_redirect"/>.
+Si noti che non c'e' alcun modo di specificare un nome catch-all o un
+server di default usando la direttiva
+<link doc="ngx_http_core_module.xml" id="server_name"/>:
+si tratta di una proprieta' della direttiva
+<link doc="ngx_http_core_module.xml" id="listen"/>
+e non della direttiva
+<link doc="ngx_http_core_module.xml" id="server_name"/>
+Si faccia riferimento anche a
+“<link doc="request_processing.xml"/>”.
+E' possibile definire server in ascolto sulle porte *:80 e *:8080,
+e specificare che uno e' quello di default per la porta *:8080,
+mentre l'altro e' quello di default per la porta *:80:
+
+<programlisting>
+server {
+    listen       80;
+    listen       8080  default_server;
+    server_name  example.net;
+    ...
+}
+
+server {
+    listen       80  default_server;
+    listen       8080;
+    server_name  example.org;
+    ...
+}
+</programlisting>
+</para>
+
+
+</section>
+
+
+<section id="optimization"
+        name="Ottimizzazione">
+
+<para>
+I nomi esatti, i nomi con caratteri jolly che iniziano per asterisco,
+ed i nomi con caratteri jolly che terminano per asterisco,
+sono registrati in tre tabelle di hash collegate alle porte in ascolto.
+Le dimensioni delle tabelle sono ottimizzate in fase di configurazione,
+in maniera tale che i nomi possano essere recuperati con il minimo numero
+di miss alla cache della CPU.
+Dettagli su come configurare le tabelle di hash sono forniti in un
+<link doc="../hash.xml">documento</link> apposito.
+</para>
+
+<para>
+La prima tabella di hash consultata e' quella dei nomi esatti;
+se non si trova il nome ricercato, si prosegue nella tabella di hash
+dei nomi con caratteri jolly che iniziano per asterisco;
+in caso di ulteriore riscontro negativo, si passa alla tabella di hash
+dei nomi con caratteri jolly che finiscono per asterisco.
+</para>
+
+<para>
+La ricerca in una tabella di hash per nomi con caratteri jolly e' piu' lenta
+della ricerca nella tabella relativa ai nomi esatti, dato che i nomi sono ricercati
+per parti del dominio.
+Si noti che il formato speciale “<literal>.example.org</literal>” e' salvato in una
+tabella di hash di nomi con caratteri jolly, e non in quella dei nomi esatti.
+</para>
+
+<para>
+Le espressioni regolari sono testate in sequenza, per cui sono il metodo piu'
+lento e sono non scalabili.
+</para>
+
+<para>
+Per queste ragioni, se possibile e' sempre meglio usare nomi esatti.
+Ad esempio, se i nomi di server richiesti piu' di frequente sono
+<literal>example.org</literal> e <literal>www.example.org</literal>,
+e' piu' efficiente definirli in maniera esplicita:
+
+<programlisting>
+server {
+    listen       80;
+    server_name  example.org  www.example.org  *.example.org;
+    ...
+}
+</programlisting>
+
+che usare il formato piu' semplice:
+
+<programlisting>
+server {
+    listen       80;
+    server_name  .example.org;
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+Se il numero di nomi di server definiti e' molto grande,
+oppure se sono stati definiti nomi di server decisamente lunghi,
+per la messa a punto e' possibile che sia necessario utilizzare
+le direttive del livello <i>http</i>
+<link doc="ngx_http_core_module.xml" id="server_names_hash_max_size"/>
+e <link doc="ngx_http_core_module.xml" id="server_names_hash_bucket_size"/>.
+Il valore di default della direttiva
+<link doc="ngx_http_core_module.xml" id="server_names_hash_bucket_size"/>
+puo' essere pari a 32 o 64, oppure ad un altro valore, in base alla
+dimensione della linea di cache della CPU.
+Se il valore di default e' 32 ed il nome del server e' definito come
+“<literal>too.long.server.name.example.org</literal>”, allora nginx non potra'
+partire e sara' mostrato il seguente messaggio d'errore:
+
+<programlisting>
+could not build the server_names_hash,
+you should increase server_names_hash_bucket_size: 32
+</programlisting>
+
+In tal caso, il valore della direttiva dovrebbe essere aumentata sino alla
+successiva potenza di due:
+
+<programlisting>
+http {
+    server_names_hash_bucket_size  64;
+    ...
+</programlisting>
+
+Se sono stati definiti molti nomi di server, potrebbe comparire un altro
+messaggio di errore:
+
+<programlisting>
+could not build the server_names_hash,
+you should increase either server_names_hash_max_size: 512
+or server_names_hash_bucket_size: 32
+</programlisting>
+
+In tal caso, si provi prima a impostare
+<link doc="ngx_http_core_module.xml" id="server_names_hash_max_size"/>
+ad un numero prossimo al numero dei nomi di server.
+Solo nel caso in cui cio' non risultasse sufficiente, oppure se il tempo di avvio
+di nginx fosse inaccetabilmente alto, si provi ad incrementare
+<link doc="ngx_http_core_module.xml" id="server_names_hash_bucket_size"/>.
+</para>
+
+<para>
+Se su una data porta in ascolto c'e' un unico server, allora nginx saltera' del tutto
+la verifica dei nomi dei server (e non costituira' le tabelle di hash per la porta
+in questione).
+C'e' una eccezione: se un nome di server e' una espressione regolare con
+sezioni catturate, allora nginx dovra' svolgere l'espressione regolare per recuperare
+le sezioni catturate.
+</para>
+
+</section>
+
+
+<section id="compatibility"
+        name="Compatibilita'">
+
+<para>
+<list type="bullet">
+
+<listitem>
+Il nome di server speciale “<literal>$hostname</literal>” e' supportato
+dalla versione 0.9.4 in poi.
+</listitem>
+
+<listitem>
+Il nome vuoto “” e' il valore di default per il nome dei server
+dalla versione 0.8.48 in poi.
+</listitem>
+
+<listitem>
+Il riferimento tramite nome a sezioni catturate in un nome di server definito
+tramite espressione regolare e' supportato dalla versione 0.8.25 in poi.
+</listitem>
+
+<listitem>
+Le sezioni catturate in un nome di server definito tramite espressione regolare
+sono supportate dalla versione 0.7.40 in poi.
+</listitem>
+
+<listitem>
+Il nome di server vuoto  “” e' supportato
+dalla versione 0.7.12 in poi.
+</listitem>
+
+<listitem>
+La definizione di nomi di server e di espressioni regolari tramite caratteri jolly
+e' supportata dalla versione 0.6.25 in poi.
+</listitem>
+
+<listitem>
+La definizione di nomi di server tramite espressioni regolari e' supportata
+dalla versione 0.6.7 in poi.
+</listitem>
+
+<listitem>
+Il formato con caratteri jolly <literal>example.*</literal> e' supportato
+dalla versione 0.6.0 in poi.
+</listitem>
+
+<listitem>
+Il formato speciale <literal>.example.org</literal> e' supportato
+dalla versione 0.3.18 in poi.
+</listitem>
+
+<listitem>
+Il formato con caratteri jolly <literal>*.example.org</literal> e' supportato
+dalla versione 0.1.13 in poi.
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/index.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,74 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="Documentazione di nginx"
+         link="/it/docs/"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="9"
+         toc="no">
+
+
+<section id="introduction" name="Introduzione">
+
+<para>
+<list type="bullet">
+
+<listitem>
+<link doc="install.xml"/>
+</listitem>
+
+<listitem>
+<link doc="beginners_guide.xml"/>
+</listitem>
+
+<listitem>
+<link doc="control.xml"/>
+</listitem>
+
+<listitem>
+<link doc="events.xml"/>
+</listitem>
+
+<listitem>
+<link doc="hash.xml"/>
+</listitem>
+
+<listitem>
+<link doc="debugging_log.xml"/>
+</listitem>
+
+<listitem>
+<link doc="syntax.xml"/>
+</listitem>
+
+<listitem>
+<link doc="windows.xml"/>
+</listitem>
+
+</list>
+
+<list type="bullet">
+
+<listitem>
+<link doc="http/request_processing.xml"/>
+</listitem>
+
+<listitem>
+<link doc="http/server_names.xml"/>
+</listitem>
+
+<listitem>
+<link doc="http/configuring_https_servers.xml"/>
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/install.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,57 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="Installare nginx"
+         link="/it/docs/install.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="1"
+         toc="no">
+
+<section>
+
+<para>
+nginx puo' essere installato in varie maniere, a seconda del sistema operativo.
+</para>
+
+</section>
+
+
+<section id="linux" name="Installazione su Linux">
+
+<para>
+Con Linux, e' possibile usare i <link doc="../linux_packages.xml">pacchetti</link> nginx binari, scaricabili da nginx.org.
+</para>
+
+</section>
+
+
+<section id="freebsd" name="Installazione su FreeBSD">
+
+<para>
+Con FreeBSD, e' possibile installare nginx o tramite
+<link url="http://www.freebsd.org/doc/handbook/packages-using.html">pacchetti</link>
+binari oppure tramite <link url="http://www.freebsd.org/doc/handbook/ports-using.html">ports</link>.
+Ports consente maggiore flessibilita', e permette di scegliere fra un gran numero di opzioni:
+ports provvedera' a compilare nginx con le opzioni specificate, e ad installarlo.
+</para>
+
+</section>
+
+
+<section id="source_install" name="Compilazione dai sorgenti">
+
+<para>
+Se e' richiesta qualche funzionalita' particolare e non disponibile con i pacchetti binari o con ports,
+e' possibile compilare nginx a partire dai sorgenti. Per quanto maggiormente flessibile,
+questo approccio per un principiante puo' risultare piu' complesso.
+Per maggiori informazioni, fare riferimento a <link doc="configure.xml"/>.
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/syntax.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,54 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="Unita' di misura del file di configurazione"
+         link="/it/docs/syntax.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="3">
+
+<section>
+
+<para>
+Le dimensioni possono essere indicate in byte, kilobyte
+(suffissi <literal>k</literal> e <literal>K</literal>), e megabyte
+(suffissi <literal>m</literal> e <literal>M</literal>), ad esempio
+“<literal>1024</literal>”, “<literal>8k</literal>”, “<literal>1m</literal>”.
+</para>
+
+<para>
+Gli intervalli di tempo possono essere specificati in millisecondi,
+secondi, minuti, ore, giorni, e cosi' via, utilizzando i suffissi seguenti:
+<table width="30%">
+<tr><td width="20%">ms</td><td>millisecondi</td></tr>
+<tr><td width="20%">s</td><td>secondi</td></tr>
+<tr><td width="20%">m</td><td>minuti</td></tr>
+<tr><td width="20%">h</td><td>ore</td></tr>
+<tr><td width="20%">d</td><td>giorni</td></tr>
+<tr><td width="20%">w</td><td>settimane</td></tr>
+<tr><td width="20%">M</td><td>mesi, 30 giorni</td></tr>
+<tr><td width="20%">y</td><td>anni, 365 giorni</td></tr>
+</table>
+</para>
+
+<para>
+E' possibile combinare in un singolo valore piu' unita', specificandole
+dalla piu' significativa alla meno significativa ed eventualmente
+separandole con spazi. Ad esempio, “<literal>1h 30m</literal>” indica
+lo stesso tempo di “<literal>90m</literal>” o “<literal>5400s</literal>”.
+Un valore senza suffisso indica secondi, comunque e' sempre raccomandato
+specificare un suffisso.
+</para>
+
+<para>
+Alcuni intervalli temporali possono essere specificati solo
+con una risoluzione di secondi.
+</para>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/docs/windows.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,158 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="nginx per Windows"
+         link="/it/docs/windows.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="2">
+
+<section>
+
+<para>
+La versione di nginx per Windows usa le API native Win32, e non il layer di
+emulazione Cygwin.
+Attualmente e' usato solo il metodo di connessione <c-func>select</c-func>,
+per cui non e' possibile attendersi prestazioni e scalabilita' eccellenti;
+per tale ragione, e anche per altre, quella per Windows e'
+considerata una versione <i>beta</i>.
+Al momento risultano implementate piu' o meno le stesse funzionalita' della
+versione di nginx per UNIX, con l'eccezione del filtro XSLT, del filtro immagini,
+del modulo GeoIP, e del linguaggio Perl embedded.
+</para>
+
+<para>
+Per installare nginx/Windows, e' bene <link doc="../download.xml">scaricare</link>
+l'ultima distribuzione disponibile della versione mainline (<mainline_version/>),
+che contiene le correzioni piu' recenti.
+Bisogna scompattare la distribuzione, spostarsi nella directory
+nginx-<mainline_version/> e lanciare <command>nginx</command>.
+Segue un esempio in cui la directory e' sul drive C: :
+
+<programlisting>
+cd c:\
+unzip nginx-<mainline_version/>.zip
+cd nginx-<mainline_version/>
+start nginx
+</programlisting>
+
+Avviare l'utility a linea di comando <command>tasklist</command>
+per vedere i processi nginx:
+
+<programlisting>
+C:\nginx-<mainline_version/>&gt;tasklist /fi "imagename eq nginx.exe"
+
+Image Name           PID Session Name     Session#    Mem Usage
+=============== ======== ============== ========== ============
+nginx.exe            652 Console                 0      2 780 K
+nginx.exe           1332 Console                 0      3 112 K
+</programlisting>
+
+Uno dei due e' il processo master, l'altro il processo worker.
+Se nginx non si avvia, verificarne la ragione nel file di log
+degli errori <path>logs\error.log</path> ;
+se tale file non e' stato creato, la ragione dovrebbe essere riportata
+nel Windows Event Log.
+Se viene mostrata una pagina di errore invece della pagina attesa,
+verificarne la ragione nel solito file <path>logs\error.log</path> .
+</para>
+
+<para>
+nginx/Windows utilizza la directory in cui e' stato avviato come prefisso
+per i path relativi della configurazione.
+Nell'esempio precedente, il prefisso e'
+<path>C:\nginx-<mainline_version/>\</path> .
+I path nei file di configurazione devono essere specificati usando gli
+slash del formato UNIX:
+
+<programlisting>
+access_log   logs/site.log;
+root         C:/web/html;
+</programlisting>
+</para>
+
+<para>
+nginx/Windows e' eseguito come una normale applicazione di console e
+non come un servizio, e puo' essere gestito con i comandi seguenti:
+
+<table note="yes">
+
+<tr>
+<td width="20%">nginx -s stop</td>
+<td>arresto rapido</td>
+</tr>
+
+<tr>
+<td>nginx -s quit</td>
+<td>arresto controllato</td>
+</tr>
+
+<tr>
+<td>nginx -s reload</td>
+<td>
+ricaricamento della configurazione,
+con avvio di un nuovo processo worker con la nuova configurazione,
+ed arresto controllato del vecchio processo worker.
+</td>
+</tr>
+
+<tr>
+<td>nginx -s reopen</td>
+<td>riapertura dei file di log</td>
+</tr>
+
+</table>
+</para>
+
+</section>
+
+<section id="known_issues"
+        name="Problemi noti">
+
+<list type="bullet">
+
+<listitem>
+Nonostante sia possibile avviare diversi worker, in effetti
+solo uno di essi esegue tutto il lavoro.
+</listitem>
+
+<listitem>
+Un worker puo' gestire non piu' di 1024 connessioni simultanee.
+</listitem>
+
+<listitem>
+La cache, ed altri moduli che richiedono il supporto alla memoria condivisa,
+non funzionano su Windows Vista e versioni successive, in quanto su tali
+versioni e' in uso la address space layout randomization.
+</listitem>
+
+</list>
+
+</section>
+
+<section id="possible_future_enhancements"
+        name="Possibili sviluppi futuri">
+
+<list type="bullet">
+
+<listitem>
+L'esecuzione come servizio.
+</listitem>
+
+<listitem>
+L'uso di I/O completion port come metodo di processo delle connessioni.
+</listitem>
+
+<listitem>
+L'uso di piu' thread worker all'interno di un singolo processo worker.
+</listitem>
+
+</list>
+
+</section>
+
+</article>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/it/index.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -0,0 +1,357 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../dtd/article.dtd">
+
+<article name="nginx"
+         link="/it/"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="11">
+
+
+<section>
+
+<para>
+nginx [engine x] e' un server HTTP e reverse proxy,
+nonche' un server mail proxy, scritto da
+<link url="http://sysoev.ru/en/">Igor Sysoev</link>.
+Per molto tempo e' stato usato principalmente per alcuni
+siti russi ad alto carico, ad esempio
+<link url="http://www.yandex.ru">Yandex</link>,
+<link url="http://www.mail.ru">Mail.Ru</link>,
+<link url="http://vkontakte.ru">VKontakte</link> e
+<link url="http://www.rambler.ru">Rambler</link>;
+in base ai dati di Netcraft, nell'ottobre 2013 nginx
+e' il server HTTP o reverse proxy del
+<link url="http://news.netcraft.com/archives/2013/10/02/october-2013-web-server-survey.html">15.08%
+dei siti a maggiore carico</link>.
+Alcuni casi di successo sono:
+<link url="https://signup.netflix.com/openconnect/software">Netflix</link>,
+<link url="http://nginx.com/cs/nginx-automattic.html">Wordpress.com</link>,
+<link url="http://blog.fastmail.fm/2007/01/04/webimappop-frontend-proxies-changed-to-nginx/">FastMail.FM</link>.
+</para>
+
+<para>
+La documentazione ed i sorgenti sono distribuiti in base alla
+<link url="../LICENSE">licenza BSD con 2 clausole</link>.
+</para>
+
+</section>
+
+
+<section id="basic_http_features"
+        name="Caratteristiche principali del server HTTP">
+
+<para>
+<list type="bullet">
+
+<listitem>
+Servizio di file statici e
+<link doc="docs/http/ngx_http_index_module.xml">index</link>,
+<link doc="docs/http/ngx_http_autoindex_module.xml">autoindexing</link>;
+<link doc="docs/http/ngx_http_core_module.xml"
+       id="open_file_cache">cache dei descrittori dei file aperti</link>;
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_proxy_module.xml">Reverse proxy accelerato
+con cache</link>;
+<link doc="docs/http/ngx_http_upstream_module.xml">semplice bilanciamento
+di carico e load balancing</link>;
+</listitem>
+
+<listitem>
+Supporto accelerato con cache di server
+<link doc="docs/http/ngx_http_fastcgi_module.xml">FastCGI</link>,
+uwsgi, SCGI, e
+<link doc="docs/http/ngx_http_memcached_module.xml">memcached</link>;
+<link doc="docs/http/ngx_http_upstream_module.xml">semplice bilanciamento
+di carico e load balancing</link>;
+</listitem>
+
+<listitem>
+Architettura modulare.
+Filtri per
+<link doc="docs/http/ngx_http_gzip_module.xml">gzip</link>,
+intervalli di byte, risposte a blocchi,
+<link doc="docs/http/ngx_http_xslt_module.xml">XSLT</link>,
+<link doc="docs/http/ngx_http_ssi_module.xml">SSI</link>,
+e filtro per la <link doc="docs/http/ngx_http_image_filter_module.xml">
+trasformazione d'immagini</link>.
+Inclusioni multiple di SSI in una stessa pagina possono essere
+processate in parallelo se sono gestite da server proxy o FastCGI;
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_ssl_module.xml">Supporto a SSL e TLS SNI
+</link>.
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="other_http_features"
+        name="Caratteristiche ulteriori del server HTTP">
+
+<para>
+<list type="bullet">
+
+<listitem>
+<link doc="docs/http/request_processing.xml">server virtuali</link>
+name-based e IP-based;
+</listitem>
+
+<listitem>
+Supporto a connessioni
+<link doc="docs/http/ngx_http_core_module.xml"
+       id="keepalive_timeout">keep-alive</link>
+e pipelined;
+</listitem>
+
+<listitem>
+Configurazione flessibile;
+</listitem>
+
+<listitem>
+<link doc="docs/control.xml" id="reconfiguration">Caricamento di una nuova
+configurazione </link> e <link doc="docs/control.xml" id="upgrade">
+aggiornamento dell'eseguibile</link> senza interruzione di servizio ai client;
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_log_module.xml" id="log_format">Access log in vari
+formati</link>, <link doc="docs/http/ngx_http_log_module.xml" id="access_log">log con buffer
+</link>, e <link doc="docs/control.xml" id="logs">veloce rotazione dei log</link>;
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_core_module.xml" id="error_page">Redirezione</link>
+dei codici d'errore 3xx-5xx;
+</listitem>
+
+<listitem>
+Modulo di rewrite:
+<link doc="docs/http/ngx_http_rewrite_module.xml">trasformazione delle URI
+con uso di espressioni regolari</link>;
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_rewrite_module.xml" id="if">Esecuzione di funzioni differenti
+</link> a seconda dell'
+<link doc="docs/http/ngx_http_geo_module.xml">indirizzo del client</link>;
+</listitem>
+
+<listitem>
+Controllo d'accesso in base a
+<link doc="docs/http/ngx_http_access_module.xml">indirizzo IP del client</link>, a
+<link doc="docs/http/ngx_http_auth_basic_module.xml">
+password (HTTP Basic authentication)</link>, e al
+<link doc="docs/http/ngx_http_auth_request_module.html">risultato di una sottorichiesta</link>;
+</listitem>
+
+<listitem>
+Validazione del
+<link doc="docs/http/ngx_http_referer_module.xml">referer HTTP</link>;
+</listitem>
+
+<listitem>
+Metodi <link doc="docs/http/ngx_http_dav_module.xml">PUT, DELETE, MKCOL, COPY,
+e MOVE</link>;
+</listitem>
+
+<listitem>
+Streaming
+<link doc="docs/http/ngx_http_flv_module.xml">FLV</link> e
+<link doc="docs/http/ngx_http_mp4_module.xml">MP4</link>;
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_core_module.xml" id="limit_rate">
+Limitazione della velocita' del flusso di risposta</link>;
+</listitem>
+
+<listitem>
+Limitazione del numero di
+<link doc="docs/http/ngx_http_limit_conn_module.xml">connessioni</link> o
+<link doc="docs/http/ngx_http_limit_req_module.xml">richieste</link>
+simultanee da un dato indirizzo;
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_perl_module.xml">Perl embedded</link>.
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="mail_proxy_server_features"
+        name="Caratteristiche del server mail proxy">
+
+<para>
+<list type="bullet">
+
+<listitem>
+Redirezione dell'utente verso server
+<link doc="docs/mail/ngx_mail_imap_module.xml">IMAP</link>
+o
+<link doc="docs/mail/ngx_mail_pop3_module.xml">POP3</link>
+tramite un server esterno di
+<link doc="docs/mail/ngx_mail_auth_http_module.xml">autenticazione</link>
+HTTP;
+</listitem>
+
+<listitem>
+Autenticazione dell'utente tramite un server esterno di
+<link doc="docs/mail/ngx_mail_auth_http_module.xml">autenticazione</link>
+e redirezione della connessione verso un server
+<link doc="docs/mail/ngx_mail_smtp_module.xml">SMTP</link>;
+</listitem>
+
+<listitem>
+Metodi di autenticazione:
+
+<list type="bullet">
+
+<listitem>
+<link doc="docs/mail/ngx_mail_pop3_module.xml" id="pop3_auth">POP3</link>:
+USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
+</listitem>
+
+<listitem>
+<link doc="docs/mail/ngx_mail_imap_module.xml" id="imap_auth">IMAP</link>:
+LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
+</listitem>
+
+<listitem>
+<link doc="docs/mail/ngx_mail_smtp_module.xml" id="smtp_auth">SMTP</link>:
+AUTH LOGIN/PLAIN/CRAM-MD5;
+</listitem>
+
+</list>
+</listitem>
+
+<listitem>
+supporto a
+<link doc="docs/mail/ngx_mail_ssl_module.xml">SSL</link>;
+</listitem>
+
+<listitem>
+supporto a
+<link doc="docs/mail/ngx_mail_ssl_module.xml" id="starttls">STARTTLS
+e STLS</link>.
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="architecture_and_scalability"
+        name="Architettura e scalabilita'">
+
+<para>
+<list type="bullet">
+
+<listitem>
+Un processo master e numerosi processi worker;
+i processi worker girano con un utente non privilegiato;
+</listitem>
+
+<listitem>
+<link doc="docs/events.xml">Supporto</link> a
+kqueue (FreeBSD 4.1+),
+epoll (Linux 2.6+), segnali rt (Linux 2.2.19+),
+/dev/poll (Solaris 7 11/99+), event ports (Solaris 10),
+select, e poll;
+</listitem>
+
+<listitem>
+Supporto alle differenti funzionalita' di kqueue, fra cui EV_CLEAR, EV_DISABLE
+(per disabilitare temporaneamente eventi), NOTE_LOWAT, EV_EOF,
+numero di dati disponibili, codici d'errore;
+</listitem>
+
+<listitem>
+supporto a sendfile (FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+),
+e sendfilev (Solaris 8 7/01+);
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_core_module.xml" id="aio">File AIO</link>
+(FreeBSD 4.3+, Linux 2.6.22+);
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_core_module.xml" id="directio">DIRECTIO</link>
+(FreeBSD 4.4+, Linux 2.4+, Solaris 2.6+, Mac OS X);
+</listitem>
+
+<listitem>
+<link doc="docs/http/ngx_http_core_module.xml" id="listen">supporto</link> a
+Accept-filters (FreeBSD 4.1+, NetBSD 5.0+) e TCP_DEFER_ACCEPT (Linux 2.4+);
+</listitem>
+
+<listitem>
+10000 connessioni HTTP keep-alive inattive richiedono circa 2.5M di memoria;
+</listitem>
+
+<listitem>
+Le operazioni di copia di dati risultano minime.
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="tested_os_and_platforms"
+        name="Piattaforme e sistemi operativi testati">
+
+<para>
+<list type="bullet">
+
+<listitem>
+FreeBSD 3&mdash;10 / i386; FreeBSD 5&mdash;10 / amd64;
+</listitem>
+
+<listitem>
+Linux 2.2&mdash;3 / i386; Linux 2.6&mdash;3 / amd64;
+</listitem>
+
+<listitem>
+Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
+</listitem>
+
+<listitem>
+AIX 7.1 / powerpc;
+</listitem>
+
+<listitem>
+HP-UX 11.31 / ia64;
+</listitem>
+
+<listitem>
+Mac OS X / ppc, i386;
+</listitem>
+
+<listitem>
+Windows XP, Windows Server 2003.
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>

--- a/xml/menu.xml	Mon Nov 18 12:48:10 2013 +0400
+++ b/xml/menu.xml	Wed Nov 20 14:36:40 2013 +0400
@@ -17,6 +17,7 @@
 <item href="/he/" switchlang="he"> עברית </item>
 <item href="/ja/" switchlang="ja"> 日本語 </item>
 <item href="/tr/" switchlang="tr"> türkçe </item>
+<item href="/it/" switchlang="it"> italiano </item>
 <item />
 
 <item href="/" lang="en"> 新闻 </item>
@@ -49,6 +50,7 @@
 <item href="/he/" switchlang="he"> עברית </item>
 <item href="/ja/" switchlang="ja"> 日本語 </item>
 <item href="/tr/" switchlang="tr"> türkçe </item>
+<item href="/it/" switchlang="it"> italiano </item>
 <item />
 
 <item href="/"> news </item>
@@ -94,6 +96,7 @@
 <item> עברית </item>
 <item href="/ja/" switchlang="ja"> 日本語 </item>
 <item href="/tr/" switchlang="tr"> türkçe </item>
+<item href="/it/" switchlang="it"> italiano </item>
 <item />
 
 <item href="/" lang="אנגלית"> חדשות </item>
@@ -124,6 +127,7 @@
 <item href="/he/" switchlang="he"> עברית </item>
 <item> 日本語 </item>
 <item href="/tr/" switchlang="tr"> türkçe </item>
+<item href="/it/" switchlang="it"> italiano </item>
 <item />
 
 <item href="/" lang="en"> ニュース </item>
@@ -155,6 +159,7 @@
 <item href="/he/" switchlang="he"> עברית </item>
 <item href="/ja/" switchlang="ja"> 日本語 </item>
 <item href="/tr/" switchlang="tr"> türkçe </item>
+<item href="/it/" switchlang="it"> italiano </item>
 <item />
 
 <item href="/" lang="en"> новости </item>
@@ -188,6 +193,7 @@
 <item href="/he/" switchlang="he"> עברית </item>
 <item href="/ja/" switchlang="ja"> 日本語 </item>
 <item> türkçe </item>
+<item href="/it/" switchlang="it"> italiano </item>
 <item />
 
 <item href="/" lang="ing"> haberler </item>
@@ -209,4 +215,50 @@
 
 </menu>
 
+
+<menu lang="it">
+
+<item href="/en/" switchlang="en"> english </item>
+<item href="/ru/" switchlang="ru"> русский </item>
+<item />
+
+<item href="/cn/" switchlang="cn"> 简体中文 </item>
+<item href="/he/" switchlang="he"> עברית </item>
+<item href="/ja/" switchlang="ja"> 日本語 </item>
+<item href="/tr/" switchlang="tr"> türkçe </item>
+<item> italiano </item>
+<item />
+
+<item href="/" lang="ing"> news </item>
+<item href="2012.html" year="2012" />
+<item href="2011.html" year="2011" />
+<item href="2010.html" year="2010" />
+<item href="2009.html" year="2009" />
+<item year="" />
+
+<item href="/it/"> informazioni generali </item>
+<item href="/en/download.html" lang="ing"> download </item>
+<!--
+<item href="/en/getting_started.html" lang="ing"> per iniziare </item>
+-->
+<item href="/en/security_advisories.html" lang="ing"> avvisi di sicurezza </item>
+<item href="/it/docs/"> documentazione </item>
+<item href="/en/pgp_keys.html" lang="ing"> chiavi pgp </item>
+<!--
+<item href="/en/docs/reference.html" lang="ing"> riferimenti </item>
+-->
+<item href="/en/docs/faq.html" lang="ing"> faq </item>
+<item href="/en/links.html" lang="ing"> collegamenti </item>
+<item href="/en/books.html" lang="ing"> libri </item>
+<item href="/en/support.html" lang="ing"> supporto </item>
+<item href="/en/donation.html" lang="ing"> donazioni </item>
+<item />
+
+<item href="http://trac.nginx.org/nginx"> trac </item>
+<item href="http://wiki.nginx.org/"> wiki </item>
+<item href="http://twitter.com/nginxorg"> twitter </item>
+<item href="http://nginx.com/"> nginx.com </item>
+
+</menu>
+
 </menus>