Indice dei contenuti
Dopo gli articoli dedicati al protocollo HTTP e al ciclo HTTP request/response, pubblichiamo un approfondimento dedicato al protagonista principale dell'interazione tra client/browser e il world wide web: il server web (o server HTTP), ovvero l'applicazione applicazione software che ha il compito di ricevere e gestire le richieste HTTP.
In questo articolo ci riferiremo al server web adottando la definizione di Wikipedia, che lo descrive come il servizio o applicativo software in esecuzione su una macchina server fisica o virtuale: tuttavia, il termine viene spesso utilizzato anche per definire la macchina su cui tale applicativo è installato. Le due diverse accezioni del termine sono comunque in buona parte intercambiabili, in quanto sia l'applicazione che (per esteso) la macchina sono chiamate a svolgere le medesime funzioni principali.
Concetti generali
Come detto in apertura, il web server è un servizio installato su una macchina fisica o virtuale (tipicamente una workstation con un sistema operativo di tipo Windows, Linux o altro) che si occupa di “ascoltare” una o più porte TCP (solitamente la 80 e/o la 443) e gestire le richieste (request) ad esse indirizzate, provenienti dai client/browser. La gestione di queste richieste prevede la negoziazione della chiamata (e del canale crittografato, in caso di HTTPS), lo “spacchettamento” della URL relativa alla request e l’utilizzo delle sue singole parti per svolgere le seguenti attività:
- Verificare che il protocollo richiesto sia tra quelli gestiti/accettati.
- Verificare che l’hostname richiesto sia tra quelli configurati come validi.
- Verificare che la porta TCP utilizzata sia tra quelle configurate come valide.
- Verificare che il percorso (path) punti a un file fisico avente una estensione valida o sia gestito tramite un handler, uno script CGI o un altro componente server-side opportunamente configurato per gestire quel tipo di request.
- Gestire la richiesta (request) e trasmettere la risposta (response) al client.
IMPORTANTE: Il Web Server è tipicamente configurato per gestire solo alcune estensioni specifiche (solitamente definite tramite una white-list): tutte le altre vengono rifiutate e gestite tramite uno Status Code 404 - Not Found, anche se il relativo file è presente sul file system.
Pagine statiche e pagine dinamiche
La maggior parte dei siti web sono composti da una pluralità di pagine statiche e/o dinamiche. A dire il vero sarebbe più corretto parlare di risorse, in quanto oltre alle pagine web i siti trasmettono anche una pluralità di contenuti (immagini, file CSS, JavaScript, etc) che possono essere anch'essi statici o dinamici: tuttavia, per semplificare l'argomento, ci limiteremo a mettere a fuoco le pagine web, ovvero i contenuti HTML richiesti dal client/browser e ricevuti tramite il server web. Fatta questa premessa, cerchiamo di comprendere la differenza tra pagine statiche e pagine dinamiche:
- Le pagine statiche sono quelle che il web server recupera e trasmette da file system: in altre parole, sono pagine immutabili e che risultano identiche tutte le volte che un utente le visualizza e per tutti gli utenti.
- Le pagine dinamiche sono quelle generate di volta in volta a seconda di una serie di condizioni che cambiano: parametri GET, parametri POST, data e ora, etc, risultando quindi potenzialmente diverse ad ogni chiamata e per ogni utente.
Per inviare al client una pagina statica, il browser svolge le seguenti operazioni:
- Recupera la pagina dal filesystem (sotto forma di file “contenuto”). Alcuni esempi: hello.html, image1.gif, etc.
- Determina il content type dall’estensione del file
- Legge e trasmette il contenuto del file (e relativo content type) al browser
Per inviare al client una pagina dinamica, il browser svolge le seguenti operazioni:
- Recupera la pagina dal filesystem (sotto forma di file “eseguibile”). Alcuni esempi: index.php, default.asp, etc.
- Esegue il file utilizzando il relativo framework server-side (PHP, ASP, ASP.NET, Python, etc), recuperando il risultato dell’esecuzione (incluso il content type)
- Trasmette il risultato dell’esecuzione (e relativo content type) al browser
Web Server e Framework Server-Side
Come fa il web server a “sapere” quale è il framework server-side da utilizzare? Risposta: sempre tramite l’estensione. L’estensione del file "dinamico" determina qual è il framework da utilizzare, o per meglio dire l'applicativo (handler, parser, pre-processor, etc.) a cui trasmettere la HTTP Request e che si occuperà di "generare" la HTTP Response da trasmettere al client. Ovviamente il framework deve essere installato e opportunamente configurato sul web server: ad esempio, per poter “eseguire” pagine con estensione .php, sul server dovrà essere installato l’interprete di comandi PHP, altrimenti quelle pagine restituiranno con tutta probabilità un errore (Status Code 404 - Not Found) in quanto non è presente alcuna associazione per quel determinato content type.
IMPORTANTE: il client non ha alcuna notizia del framework server-side (e/o del relativo linguaggio di programmazione) utilizzato dal server per eseguire le pagine dinamiche, né ha alcuna necessità di saperlo, in quanto tutto ciò che lui riceve è il risultato di tale elaborazione. Questo significa che:
- Il client non può sapere con certezza se il server web utilizza pagine PHP, ASP, ASP.NET, etc: può soltanto ipotizzare la tecnologia server-side utilizzata, basandosi su quelli che sono i comportamenti standard dei vari framework e/o le “tracce” che possono lasciare nei vari elementi che compongono la HTTP response. Ad esempio, se i link interni dell'applicazione web puntano a pagine con estensione .php, è ragionevole pensare che il sito sia stato realizzato in PHP.
- Il client non necessita di avere nessun framework server-side installato sul poprio sistema, in quanto si limita a ricevere dal server web il risultato dell'elaborazione delle pagine dinamiche sotto forma di HTTP Response. In altre parole, non è lui a dover "eseguire" quelle pagine: il suo scopo è quello di richiedere al server web (request) il risultato di tale esecuzione, così da poterlo ricevere (response) e mostrare a schermo. Per approfondimenti su questa dinamica HTTP request/response consigliamo di leggere questo articolo.
Conclusione
Per il momento è tutto: ci auguriamo che questa panoramica, sia pure con le inevitabili semplificazioni del caso, possa essere utile a chi si sta avvicinando per la prima volta a questi concetti fondamentali del World Wide Web.
