Mercurial > hg > nginx-site
changeset 1018:19129672444e
Added italian translation.
Grazie a Angelo Papadia <angelo.papadia@gmail.com>!
author | Vladimir Homutov <vl@nginx.com> |
---|---|
date | Wed, 20 Nov 2013 14:36:40 +0400 |
parents | 9f9a427a73eb |
children | 2b6a858c60dc |
files | GNUmakefile xml/i18n.xml xml/it/GNUmakefile xml/it/docs/beginners_guide.xml xml/it/docs/control.xml xml/it/docs/debugging_log.xml xml/it/docs/events.xml xml/it/docs/hash.xml xml/it/docs/http/configuring_https_servers.xml xml/it/docs/http/request_processing.xml xml/it/docs/http/server_names.xml xml/it/docs/index.xml xml/it/docs/install.xml xml/it/docs/syntax.xml xml/it/docs/windows.xml xml/it/index.xml xml/menu.xml |
diffstat | 17 files changed, 3101 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- 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>—arresto rapido +</listitem> +<listitem> +<literal>quit</literal>—arresto controllato +</listitem> +<listitem> +<literal>reload</literal>—ricaricamento della configurazione +</listitem> +<listitem> +<literal>reopen</literal>—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>—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>—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>—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>—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>—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>—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>—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 —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—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&page=1 +/index.php?page=1&user=john +</programlisting> +Inoltre, nella stringa di richiesta e' possibile scrivere qualsiasi cosa: +<programlisting> +/index.php?page=1&something+else&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 /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 ~^(?<user>.+)\.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 "~^(?<name>\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>?<domain></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>?<<value>nome</value>></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<<value>nome</value>></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 (?< in ... +</programlisting> + +significa che la libreria PCRE e' troppo vecchia, per cui e' bene provare +ad usare invece la sintassi: +“<literal>?P<<value>name</value>></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/>>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—10 / i386; FreeBSD 5—10 / amd64; +</listitem> + +<listitem> +Linux 2.2—3 / i386; Linux 2.6—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>