Ok ma scusa ... perché "in locale"? Le pagine non le può servire il server HTTP??
No, quella è sostanzialmente una "schifezza". E' solo l'esempio super-ultra basilare per fare "vedere" che una applicazione Java può rispondere ad una richiesta HTTP. Ma se operi direttamente a livello di socket ti esponi ad un sacco di "grane" oltre al fatto che DEVI conoscere benissimo tutte le minuzie del protocollo HTTP (e questo potrebbe richiedere settimane, se non mesi, se parti da zero o quasi).
L'ideale è usare una libreria di "server" HTTP. O incorporare un server come Jetty o Tomcat. Ad esempio tramite Spring Boot (ma questo richiede comunque anche "altre" competenze, cioè su Spring in generale).
CGI (Common Gateway Interface) è lo standard che si usa(va) (una volta...) per far sì che un web server potesse lanciare script/eseguibili esterni che "rispondevano" alle richieste ricevendo/inviando i dati tramite i suoi standard input/output. Quindi ogni richiesta creava un processo esterno. Questo E' pesante.
Tutte le moderne web application, che siano con un "vero" application server, che siano con un server HTTP embedded o altro, sfruttano il multi-threading. Quindi molto più leggero. E quindi NON è un CGI.


Rispondi quotando