Parte 3 Modulo 1: Server HTTP Apache: A patchy server 1994: public domain HTTP daemon (NCSA) sviluppato da Rob McCool al National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign Necessità di modifiche (patches) Feb. 1995: un gruppo di Webmaster si coordinano creando l Apache Group Brian Behlendorf Roy T. Fielding Rob Hartill David Robinson Cliff Skolnick Randy Terbush Robert S. Thau Andrew Wilson with additional contributions Eric Hagberg Frank Peters Nicolas Pioch Sistemi e Servizi di Rete - LS 2005/2006 Server Web 3.2
Software per server Web 1995-2001 1995- oggi Fonte: Netcraft Web Server Survey (http://www.netcraft.com/survey/) Server Web più diffusi: Apache,, Microsoft Internet Information Server, altri Sistemi (SunONE, e Servizi di Rete Zeus, - LS iplanet 2004/2005 Web Server Server, Web ) 3.3 Apache: caratteristiche APACHE = A Patchy Server (http://www.apache.org) Sviluppato a partire dal server NCSA nel 1994 Disponibilità del codice sorgente (progetto open-source) Portabilità: supporto dei SO Linux, Unix, Windows NT/9x, OS/2, Efficienza, flessibilità Supporto dei più recenti protocolli (compatibilità HTTP/1.1) Stabilità ed affidabilità Processo di sviluppo open Modularità Nucleo (core) molto piccolo che realizza le funzionalità di base Possibilità di estendere le funzionalità mediante moduli (scritti usando l Apache module API) compilati staticamente nel nucleo oppure caricati dinamicamente a tempo di esecuzione Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.4
Apache: caratteristiche (2) Apache rende disponibili anche le seguenti funzionalità: autenticazione personalizzazione dei messaggi di errore possibilità illimitata di URL rewriting e Aliasing negoziazione dei contenuti virtual hosting (multi-homed servers ovvero più siti Web sullo stesso server) personalizzazione dei logfile Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.5 Uso dei socket Due processi comunicano inviando dati in un socket e leggendo dati da un socket Paradigma client/server Due tipi di servizio di trasporto possibili UDP: datagram non affidabile e non orientato alla connessione TCP: stream (flusso) di byte orientato alla connessione ed affidabile Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.6
Interfaccia di socket Socket - astrazione del sistema operativo (non hardware) - creato dinamicamente - persiste soltanto durante l esecuzione dell applicazione - identificato tramite un descrittore (concetti di UNIX I/O) Descrittore - un intero - uno per ogni socket attivo - significativo soltanto per l applicazione che possiede il socket Funzionalità di socket - struttura socket è completamente generale, che può essere usato: - dal client - dal server - con un protocollo di trasporto orientato alla connessione (TCP) - con un protocollo di trasporto privo di connessione (UDP) - per inviare, ricevere dati Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.7 Fasi di una comunicazione Dichiarazione al sistema operativo che si intende instaurare una connessione con specifica delle caratteristiche Apertura della connessione (differente dal lato server rispetto al lato client): il server assume di definire la connessione prima del client, e rimane in attesa che il client si connetta alla porta specificata il client assume che il server sia già attivo e prova a connettersi specificando indirizzo e porta del server Scambio di dati bidirezionale (trasmissione e ricezione) Chiusura della connessione Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.8
Operazioni con socket - creazione descriptor = socket(protofamily, type, protocol) descriptor: è un intero protofamily: PF_INET per Internet type: SOCK_STREAM o SOCK_DGRAM - chiusura close (socket) descriptor - binding (usata dal server per fornire un numero di porta) bind(socket, localaddr, addrlen) descriptor indirizzo su cui ascoltare address len Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.9 Operazioni con socket (2) - ascolto descriptor listen(socket, queuesize) backlog usata dal server per preparare il socket a ricevere una connessione il SO costruisce una coda di richieste per ciascun socket - accettazione di una nuova richiesta di connessione newsock = accept(socket, caddress, caddresslen) descriptor client address (output param) address len usata dal server: attende nuova connessione (anche in coda) e crea un nuovo socket chiamata successivamente a socket() e bind() da un server che un usa un protocollo di trasporto orientato al servizio la struttura caddress e caddresslen sono riempite da accept() newsock: descrittore del nuovo socket Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.10
Operazioni con socket (3) - instaurazione di una connessione connect(socket, saddress, saddresslen) descriptor server address addr len è la procedura usata dal client per contattare un server che ha chiamato accept() protocollo orientato alla connessione: connect() inizia la connessione protocollo privo di connessione: connect() segna il socket come connessa e registra l indirizzo del server - invio di un messaggio: options send(socket, data, length, flags) descriptor data ptr data len Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.11 Programmazione con socket TCP Il client deve contattare il server il processo server deve essere in esecuzione il server deve aver creato il socket su cui accettare il contatto del client Il client contatta il server creando un socket TCP locale al client specificando l indirizzo IP e il numero di porta del processo server Quando il client crea il socket: il client instaura la connessione al server TCP Quando è contattato dal client, il server TCP crea un nuova istanza di socket per far comunicare il processo server con il client Punto di vista dell applicazione TCP fornisce un trasferimento di byte (pipe) affidabile, in sequenza, tra client e server Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.12
Programmazione con socket TCP (2) Per l applicazione: - la connessione TCP è un collegamento diretto tra il socket del client ed il socket di connessione del server - il client può inviare i byte nel suo socket: TCP garantisce che il server riceverà (tramite il socket di connessione) ogni byte nello stesso ordine in cui è inviato creato a partire da welcoming socket tramite accept Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.13 Esempio client/server Esempio client/server di programmazione con socket - il server conta il numero di client che accedono al suo servizio - il client contatta il server per conoscere tale numero - messaggio ASCII stampabile - esecuzione sequenziale (non concorrente) Client - apre la connessione con il server - ripete finché end-of-file: ricevi testo stampa caratteri ricevuti - chiude la connessione -esce Server - crea il socket e si pone in attesa - ripete forever: accetta nuova connessione, prende un nuovo socket incrementa il contatore ed invia il messaggio chiude il socket per la connessione Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.14
Uso dei socket nell esempio: Esempio client/server (2) - Il client chiude il socket dopo l uso - Il server non chiude mai il socket originale Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.15 Server HTTP (es., richiesta oggetto statico) Client (browser) DNS Server HTTP DNS lookup Coda SYN-RCVD Coda ACCEPT TCP SYN TCP ACK richiesta HTTP (GET) TCP SYN-ACK Listen Socket ACCEPT dati dalla memoria risposta HTTP dati dal disco CPU memoria disco Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.16
Richiesta HTTP GET / HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-us; rv:1.7.6) Gecko/20050324 Epiphany/1.6.2 (Debian) Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: it-it,it;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive RIGA VUOTA MARCA LA FINE DELL'HEADER DELLA RICHIESTA Risposta HTTP HTTP/1.1 200 OK Date: Mon, 18 Apr 2005 20:20:46 GMT Server: Apache/2.0.53 (Debian GNU/Linux) DAV/2 PHP/4.3.10-12 mod_ssl/2.0.53 OpenSSL/0.9.7e mod_perl/1.999.21 Perl/v5.8.4 Last-Modified: Mon, 02 Aug 2004 12:28:56 GMT ETag: "2a446d-102e-f1cdf200" Accept-Ranges: bytes Content-Length: 4142 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html RIGA VUOTA MARCA LA FINE DELL'HEADER DELLA RISPOSTA SEGUONO DATI
Tre modalità di gestione richieste HTTP Process o (2) server for Process k o figlio Richiest a htt (1p Rispost ) a htt p (4 ) (b ) Browse r Richiest a htt p (a ) Piattaform a client Richiest a htt p (i Rispost ) a htt p (c ) thread 1 thread 2 thread 3 thread 4 process olistenerdispatcher(ii helper ) (iii ) Rispost a htt p 1 helper 2 helper 3 (iv ) Metodo fork (3 ) Metodo multithread Piattaforma server Metodo helper Apache 1.3.x Apache 2.x Sistemi e Servizi di Rete - LS 2005/2006 Server Web 3.19 Metodo fork Per ogni nuova richiesta che arriva il server: crea una nuova copia di se stesso (processo child) alla quale affida la gestione della richiesta (tramite la system call fork()) si mette subito in attesa di nuove richieste la copia clonata (il processo child) si occupa di soddisfare la richiesta e poi termina Vantaggi Il codice del server rimane semplice, poiché la clonazione è demandata in toto al sistema operativo Svantaggi Il tempo di generazione del clone può non essere trascurabile rispetto al tempo di gestione della richiesta, introducendo così un overhead che può penalizzare l'efficienza del sistema Sistemi e Servizi di Rete - LS 2005/2006 Server Web 3.20
Metodo helper Esistono alcuni processi per il servizio delle richieste (processi helper) ed un processo dispatcher: il processo dispatcher rimane sempre in ascolto delle richieste quando arriva una richiesta, la assegna ad un processo helper che la gestisce e trasferisce la connessione al processo helper prescelto Vantaggi i processi helper sono creati una sola volta e poi riusati (si evita l overhead dovuto alla fork()) maggiore semplicità e portabilità rispetto al metodo multithreading Svantaggi il processo dispatcher può divenire il collo di bottiglia scelta del numero di processi helper da (pre-)attivare Sistemi e Servizi di Rete - LS 2005/2006 Server Web 3.21 Metodo multi-threaded Esiste una sola copia del server che è in grado di generare thread multipli di esecuzione: il thread principale rimane sempre in ascolto delle richieste quando arriva una richiesta, genera un nuovo thread che la gestisce e poi termina ogni thread possiede una copia privata della connessione gestita, ma condivide con gli altri thread uno spazio di memeoria centrale (il codice del programma e le variabili globali) Vantaggi la creazione di un thread è molto più veloce di una fork() minore overhead per il context switching Svantaggi maggiore complessità del codice del server (gestione dei thread) il sistema operativo deve offrire delle librerie di supporto al multithreading (ad es., Linux/UNIX, Windows 2000) Sistemi e Servizi di Rete - LS 2005/2006 Server Web 3.22
Parte 3 Modulo 2: APACHE internals Directory in Apache Apache utilizza le seguenti directory fondamentali: ServerRoot Punto di origine dei file di amministrazione (/etc/httpd/) File di configurazione principale: httpd.conf DocumentRoot Punto di origine dei documenti (/home/httpd/html/) Programmi CGI Directory contenente script CGI (/usr/lib/cgi-bin/) Icone di sistema UserDir Directory contenente le pagine Web degli utenti del sistema (/home/*/public_html/) Server Root Document Root conf logs mod. html cgibin icons Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.24
(Premessa su Inetd) Inetd è l Internet super deamon: Ovvero un processo che rimane in ascolto su più socket e, ogni qualvolta arriva una richiesta, attiva il relativo demone in grado di gestirla correttamente Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.25 Apache: il servizio HTTP Il servizio HTTP è gestito dal demone httpd I file di configurazione vengono letti al momento dell avvio di httpd httpd può essere avviato direttamente dal sistema di inizializzazione (init), oppure può essere controllato da inetd 8 httpd 0 2 3x telnetd x inetd ftpd HTTP d S.O. Conf files We b file s Log files traianus:~$ pstree -p 629 httpd(629)-+-httpd(2051) -httpd(2052) -httpd(2053) -httpd(2054) -httpd(2056) -httpd(2057) -httpd(8162) -httpd(8362) `-httpd(14823) Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.26
Servizio richieste multiple Server sequenziale con accodamento delle richieste multiple Server concorrente Servizio parallelo mediante fork() Servizio parallelo mediante processi helper Servizio parallelo con thread Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.27 Metodo con processi helper Meccanismo usato da Apache 1.3 Si creano processi di appoggio pre-attivati Quando arriva una richiesta Il processo principale accetta la richiesta Smista la richiesta verso un processo helper Il processo helper serve la richiesta Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.28
Architettura software di Apache Apache è basato sul modello process-driven (mentre Apache 2.0 è caratterizzato da una implementazione multi-threaded) processo parent che ascolta le richieste e le assegna ad un processo child preforking dei processi child, in numero definito dalla direttiva StartServers (5) limite sul numero di processi child, definito dalla direttiva MaxClients (256) limite sul numero minimo e massimo di processi child idle, definito rispettivamente dalle direttive MinSpareServers (5) and MaxSpareServers (10) numero massimo di richieste HTTP servite da ciascun processo child, definito dalla direttiva MaxRequestsPerChild (30) Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.29 Ciclo di vita di Apache 1.3 Inizializzazione e configurazione del server Inizializzazione dei moduli Inizializzazione server secondario Inizializzazione server secondario Inizializzazione server secondario Ciclo delle richieste Ciclo delle richieste Ciclo delle richieste Termine esecuzione Termine esecuzione Termine esecuzione Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.30
Ciclo delle richieste La gestione della richiesta HTTP si suddivide in fasi successive, durante le quali vengono prese delle decisioni circa la richiesta (elaborata, scartata oppure passata intatta alla fase successiva) Le fasi possono essere trattate dal nucleo di base di Apache (ad es., l ascolto ed analisi di una richiesta, l invio della risposta HTTP) oppure da moduli esterni Se non viene definito alcun modulo gestore per una determinata fase, Apache manda in esecuzione il gestore di default Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.31 Ciclo delle richieste (2) REQUEST Wait Post-Read-Request URI Translation Cleanup Header Parsing Access Control Authentication Authorization Logging MIME Type Checking RESPONSE Fixup Documento Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.32
Ciclo delle richieste (3) Post-Read-Request vengono estratti i valori dei campi principali presenti nella richiesta HTTP e vengono inizializzate le strutture dati che verranno utilizzate successivamente dai moduli che implementano le varie fasi di gestione URI Translation L URI richiesto può riferirsi ad un file fisico, ad una risorsa dinamica prodotta da uno script esterno, oppure ad un documento generato da un modulo interno. Il server deve sapere come individuare il documento, prima di poter effettuare decisioni successive: è necessaria la conversione da URL a risorsa presente sul server. Le direttive standard di Apache Alias, ScriptAlias e DocumentRoot permettono ad esempio di tradurre l URI nel nome di un file presente nell albero dei documenti. Moduli esterni come il mod_rewrite possono assumere il controllo di questa fase ed effettuare traduzioni più sofisticate. Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.33 Ciclo delle richieste (4) Header Parsing Analisi dell header della richiesta HTTP, al fine di estrarre informazioni utili sul client Access control Identificazione della locazione di provenienza della richiesta (indirizzo IP) Authentication Identificazione del cliente che ha effettuato la richiesta Authorization Si stabilisce se il cliente possiede i diritti di accesso per il documento richiesto Mime type checking Individuazione del tipo MIME del documento richiesto. Il server deve sapere il tipo della modalità di elaborazione richiesta (prelievo file da disco, generazione dinamica di un documento) prima di poter preparare la risposta. Noto il tipo del file, Apache individua il gestore opportuno per la fase di risposta. Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.34
Ciclo delle richieste (5) Fixup Fase introdotta per permettere l esecuzione di un qualunque tipo di operazione prima dell invio della risposta. Response Le informazioni riguardanti il documento vengono passate al gestore opportuno (content handler), che si occupa di costruire l header della risposta HTTP e di spedirlo al client. Successivamente, creazione del contenuto del documento (ad es., letto dal disco) ed invio al client. In caso di errore, il gestore invia un codice di errore opportuno al server, che lo notifica al client. Logging L esito delle operazioni effettuate viene scritto su file. Apache fornisce un supporto per il logging degli accessi e degli errori, che può essere modificato oppure esteso. Cleanup Operazioni di chiusura, con cui i moduli possono deallocare le risorse utilizzate (ad es., liberare memoria principale, chiudere file). Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.35 Parte 3 Modulo 3: Altre caratteristiche di Apache
Moduli di Apache L architettura modulare di Apache permette di aggiungere o eliminare funzionalità semplicemente attivando o disattivando moduli software I moduli possono essere caricati staticamente e dinamicamente I moderni SO consentono di utilizzare il meccanismo detto linking/loading o Dynamic Shared Objects (DSO) che permette di costruire un pezzo di codice di programma in un formato speciale e di caricarlo a run-time nello spazio di indirizzamento del programma eseguibile I moduli sono scritti in linguaggio C o PERL Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.37 Categorie di Moduli di Apache Core: direttive principali Environment Creation: direttive per la gestione dell ambiente di lavoro Content Type Decisions: determinazione del contenuto dei documenti e negoziazione dei contenuti URL Mapping: aliasing, url rewriting, virtual hosting Directory Handling: gestione delle directory Access Control: controllo di accesso e autenticazione (MD5) HTTP Response: funzionalità di risposta Dynamic Content: gestione dei contenuti dinamici Internal Content Handlers: gestione di stato del sistema e informazioni sulla configurazione Logging: gestione dei logfile Miscellaneous: gestione immagini, caching (es., proxy) Sistemi e Servizi di Rete - LS 2004/2006 Web Server 3.38
Considerazioni sulla sicurezza Il daemon httpd viene normalmente avviato con i privilegi dell'utente root PERICOLOSISSIMO Quindi, attraverso delle opportune chiamate di sistema, httpd cambia questi privilegi portandoli a quelli dell'utente e del gruppo specificati con le direttive User e Group del file httpd.conf È molto importante che l'utente e il gruppo corrispondano a nobody o altro utente non privilegiato, e devono poi essere regolati i permessi delle directory I file di configurazione e di registrazione degli eventi di Apache non devono essere accessibili in scrittura da parte degli utenti normali (di qualunque tipo siano, escluso root). Nello stesso modo, non devono essere modificabili le directory che li contengono. Sistemi e Servizi di Rete - LS 2054/2006 Web Server 3.39 Considerazioni sulla sicurezza I file che compongono i documenti ipertestuali devono essere accessibili solo in lettura agli utenti normali, così le directory non devono essere modificabili, eccetto i permessi che può avere root È consigliabile utilizzare la direttiva SymLinksIfOwnerMatch per evitare problemi da parte degli utenti che hanno la possibilità di creare documenti HTML a partire dalla loro directory personale È bene evitare di permettere l utilizzo di script CGI al di fuori della directory definita con la direttiva ScriptAlias nel file di configurazione È opportuno evitare di concedere agli utenti normali di modificare le impostazioni attraverso i file.htaccess. Ciò si ottiene con la direttiva AllowOverride None Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.40
Logfile I logfile permettono di monitorare gli accessi ad un server Web Le informazioni che possono essere memorizzate nel logfile sono quelle che viaggiano all interno dei messaggi di richiesta e risposta che il server scambia con il client usato dagli utenti Generalmente i server Web permettono di definire quali campi dei messaggi devono essere memorizzati generando così dei logfile custom in modo da soddisfare al meglio le necessità dell amministratore del sito Web Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.41 Dati estraibili da un logfile Orari di maggiore traffico Tipologia degli utenti (browser utilizzato, provenienza geografica Pagine più popolari Quali siti fanno riferimento al proprio Attenzione: la presenza di proxy intermedi tra client e server Web può falsare i risultati Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.42
Utilità dei logfile Monitorare lo stato del server Capacity planning Billing Attack detection Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.43 Esempio di log file 127.0.0.1 - - [14/Oct/2002:18:00:16 +0200] "GET /icons/apache_pb.gif HTTP/1.1" 200 2326 "http://localhost/" "Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020913 Debian/1.2.6-2" 211.97.159.184 - - [14/Oct/2002:16:06:44 +0200] "GET /default.ida?nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%u cbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190 %u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 400 341 "-" "-"
Parte 3 Modulo 4: Note su Apache 2.0 e 2.2 Uno sguardo a Apache 2.0 Mutlithread Migliore supporto per architetture non Unix Supporto Ipv6 Migliore integrazione con Perl Moduli in cascata... Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.46
Metodo a thread Meccanismo usato da Apache 2.0 (usa anche processi helper) Al posto di fork() si usano funzioni tipo pthread_create(), meno onerose e che quindi richiedono meno tempo al Sistema Operativo Svantaggi: Programmazione più difficile Sistema più vulnerabile a crash Sistemi e Servizi di Rete - LS 2005/2006 Web Server 3.47 Esempio di crash: Processo Thread un processo molti thread molti processi più thread per processo molti processi un thread per processo
Esempio di crash: Processo Thread un processo molti thread molti processi più thread per processo molti processi un thread per processo molto veloce poco sicuro soluzione intermedia molto sicuro poco veloce MPM in Apache 2.0 MPM=multi process model Modelli di thread nativi beos mpmt_os2 mpm_winnt Modelli di thread unix oriented prefork (massima stabilità) worker (massime prestazioni) perchild
Configurazione di Apache conf/httpd.conf 3 sezioni impostazioni globali impostazioni del server di default impostazioni dei virtual server ServerRoot PidFile Timeout Connessioni persistenti Keepalive MaxKeepAliveRequests KeepAliveTimeout Listen LoadModule Impostazioni globali MPM prefork Un processo principale Processi aggiuntivi per il servizio di connessioni Parametri: StartServers MinSpareServers MaxSpareServers MaxClients MaxRequestPerChild
MPM worker Un processo principale Processi ausiliari con thread multipli Parametri: ThreadsPerChild StartServers MinSpareThreads MaxSpareThreads MaxClients ServerLimit, ThreadLimit Impostazioni server di default ServerName DocumentRoot <Directory> </Directory> Options Indexes, Includes FollowSymLinks, SymLinksIfOwnerMatch ExecGCI AllowOverride Allow, Deny UserDir Logging ErrorLog CustomLog Alias, ScriptAlias
Migliorie in Apache 2.2 Modifiche a livello di sistema Migliorie generali in diversi moduli (cache, auth,...) Supporto avanzato per proxy con bilanciamento di richieste Supporto per file >2GB Nuova struttura nella configurazione Nuovo MPM Event per connessioni keep alive Nuovi moduli Nuovi moduli per la'utenticazionedegli utenti Migliorie in Apache 2.2 Nuovi strumenti per gli sviluppatori Framework per connettersi a DBMS (basato su mod_dbd) Supporto per API SQL-compliant Le nuove funzioni sono disponibili per ogni modulo Nuovo engine per regular expression Le funzioni sono disponibili nel namespace di funzioni ap_ Rimuove conflitti con altre funzioni POSIX
Nuova struttura file di configurazione Configurazione gerarchica Maggiore modularità: ogni elemento ha un suo frammento della configurazione in un file Più semplice aggungere/togliere elementi Compaiono nuove directory: Una directory a parte contiene solo le configurazioni dei moduli Un'altra directory è dedicata ai virtual hosts Un file per ogni modulo/virtual hosts Posso abilitare/rimuovere moduli facendo dei simlink di snippet standard di configurazione nelle directory Parte 3 Modulo 5: Esempi
Virtual hosts <VirtualHost><VirtualHost/> Name-based NameVirtualHost ServerName ServerAlias IP-based Non serve NameVirtualHost Access control AllowOverride AuthConfig Creazione file.htpasswd htpasswd(2) [-c] <file> <user> Nel file.htaccess AuthType Basic AuthName AuthUserFile, AuthGroupFile Require {valid-user user <user> group <group>}