Apache (o un web server in generale a questo punto) come fa ad avviare uno specifico script ? Ci saranno dei file di configurazione ?
E' il minimo. Per esempio, il supporto a PHP va esplicitamente abilitato
https://www.tutorialspoint.com/php7/php7_apache_configuration.htm
Il resto lo fa l'URL. Apache lo analizza, lo confronta con le regole che l'amministratore ha impostato nella sua configurazione e da lì capisce cosa fare. Per questo se scrivi
http://pippo.ext/miofile.php, Apache non ti manda indietro il codice del file php, ma l'output dell'esecuzione di questo script.
Apache Apre un socket “di benvenuto” su cui ascolta (ad esempio su porta 80).
Tutti i programmi che fungono da server fanno così. Anche un'ipotetico script Node.js che implementi un webservice.
Non appena un client invia una richiesta Apache crea un socket specifico facendo L handshake e avvia la comunicazione (domanda stupida: una semplice WEB app utilizza TCP vero? ).
Il socket specifico serve per evitare di dover multiplexare le comunicazioni tra Apache e millemila client sullo stesso socket. Sarebbe una follia. Invece viene creato un socket ad hoc che collega il server allo specifico client.
E no, l'handshake TCP e compagnia viene gestito dal sistema operativo. Apache usa i socket. Apre, chiude, legge, scrive.
Una webapp ovviamente è basta su TCP, come lo è quasi tutto quello che compone il web. Ma non è che il programmatore della webapp vada ad implementare il protocollo TCP. La webapp sta almeno 2 livelli più su. Per capirci, una webapp è un programma Javascript che gira su un browser. E' l'equivalente di un sito web. Tant'è che Gmail è definito webapp, ma si tratta di un sito web. Webapp è un termine markettaro più che tecnico.
Ora : il client aveva precedentemente richiesto durante il benvenuto ( o la fa ora? ) la pagina/risorsa denominata “Homepage”.
L'URL!! Contiene la risorsa richiesta.
https://pippo.ext/risorsa-richiesta.xxx
C'è una specifica che definisce le varie parti dell'URL, come il nome di dominio, il TLD ( ext ) , il protocollo, e la risorsa. E il nome della risorsa può essere tante cose. In principio era una classica gerarchia di file Unix... dir1/dir2/dir3/miofile ...e indicava al web server che si voleva quel file che si trovava ( sul server ) sotto quelle directory. Ma se vai a leggere qualcosa sul protocollo REST, noterai che il nome della risorsa può indicare qualcosa di astratto, per esempio ordini/nome-articolo/codice-ordine...e questa stringa non si riferisce ad un file, ma ad un ordine di un certo articolo con un certo codice. Sta al server interpretarlo e decidere cosa farne ( magari accede ad un db, legge dei dati, li formatta in un certo modo e li spedisce al client ).
Homepage è in realtà una pagina fortemente dinamica.
La homepage è la root di un sito web. In passato equivale a index.html. E no, non dev'essere dinamica. Può benissimo essere un file con dentro del codice HTML.
Magari generata usando Python e Php.
O qualsiasi altra cosa.
Come fa a sapere Apache quale script deve eseguire e in che ordine ?
L'URL. Il nome dello script da eseguire è contenuto nell'URL. Se manca, ci dev'essere una regola nel file di configurazione che gli dice cosa fare in quel caso.
Metti una cosa tipo "DirectoryIndex home.php", così lui sa che deve chiamare home.php ogni volta che il client vuole accedere alla home/root.
(Per errore potrebbe magari dare in risposta la semplice “homepage.html” che magari dentro ha solo il footer :D non ancora processata ).
Un file con estensione html è in genere un file HTML statico, quindi non c'è niente da processare.
Apache quindi “sniffa” già nella pagina per vedere se ci sono script ?di fatto leggendola ogni volta .. Se si come ?
O a fare questo sono programmi “CGI” (possono chiamarsi così ? “Programmi CGI? )
No. Apache sa che certe risorse, i cui nomi hanno certe caratteristiche, sono script di un certo tipo e vanno mandati al relativo interprete. Dopo di che, legge l'output dell'esecuzione di questi script e lo manda al client.
CGI è una vecchia tecnica per richiamare gli interpreti per eseguire gli script. Oggi si usano moduli Apache per fare la stessa cosa. Tranne alcuni casi.
Per chiarirti le idee, leggi qui
https://code.tutsplus.com/tutorials/how-to-use-php-in-html-code--cms-34378
"PHP tags in your
.html document are not detected, and they're just considered plain text, outputting without parsing. That's because the server is usually configured to run PHP only for files with the
.php extension.
If you want to run your HTML files as PHP, you can tell the server to run your
.html files as PHP files"
Come vedi è una questione di configurazione. Se dici ad Apache di mandare i file .html all'interprete PHP, lui lo farà. Ma in genere è una pessima idea.
Il resto lo fa l'interprete PHP, il quale accetta che codice HTML possa essere ficcato direttamente in un file sorgente PHP. Ma solo perché PHP supporta quest'opzione. Python non la supporta, per esempio.
