HTTP est donc un protocole somme toute assez simple par lui même. Ce qui complique la compréhension de l'ensemble des processus mis en œuvre, c'est toute « l'intelligence » qui est ajoutée, tant du côté serveur que du côté client.

Au départ, un client envoie une requête à un serveur HTTP et celui-ci y répond. Toute la difficulté vient de deux aspects qui sont indépendants du protocole HTTP lui-même :

• Le traitement de l'information pratiqué par le serveur avant d'envoyer le résultat de la requête.
• Le traitement de l'information pratiqué par le client avant d'afficher le résultat de la requête.

Lorsqu'une requête arrive sur le serveur, elle peut concerner :

• Une simple page HTML « statique » (le suffixe de la page étant alors généralement .htm ou .html). Tout son contenu est déjà défini en HTML et le serveur n'a qu'à l'envoyer tel quel, au client. Dans cette configuration, un site web est fortement ressemblant au contenu d'un livre, il est écrit une fois pour toutes. Toute modification doit faire l'objet d'une réédition.
• Une page HTML dont certains éléments sont « dynamiques », c'est-à-dire qu'ils sont construits à partir de sources d'informations diverses au moment de l'envoi au client. Ces méthodes ont pour but de produire deux fournitures d'informations typiquement impossibles à réaliser simplement avec des pages purement statiques:
  • Des informations qui sont le résultat d'un calcul à partir d'éléments que le client a transmis au serveur dans sa requête.
  • Des informations issues d'une base de données mise à jour par un moyen quelconque. Ces informations peuvent évoluer à tout instant et leur affichage via HTTP nécessite leur intégration en temps réel dans le document.
  • On peut bien entendu imaginer un document dont le contenu intègre les deux exercices précédents.

Plusieurs possibilités existent pour réaliser de telles opérations :

• Les exécutables  CGI (Common Gateway Interface).
  Ces exécutables construisent intégralement un flux HTML au moment de leur appel. Cette technique, la plus ancienne, n'est pas forcément la meilleure. Les exécutables peuvent être écrits dans un langage compilé comme C ou dans un langage interprété comme Perl, Python, Java, voire PHP (bien qu'il n'ait pas été initialement conçu pour cet usage). L'exécutable est déroulé sur le serveur lui-même (ou sur un autre, mais ce n'est qu'un détail).
• Des langages plus « spécialisés » comme PHP, JSP ou ASP. 
  Active Server Pages est une technologie Microsoft, alors que Personal Home Page est une technologie libre. Les deux sont sensiblement identiques au niveau des concepts, mais pas de la syntaxe.

Ces technologies sont dites « Server Side », c'est à dire que les traitements sur l'information sont effectués sur le serveur.

L'avantage du « server side » est que le code HTML reçu par le client est du HTML pur, ce qui veut dire qu'à priori, tout navigateur peut l'afficher correctement, sans trop de précautions particulières de la part de l'auteur du site, si ce n'est au niveau de leur compatibilité avec les standards.

L'inconvénient est que le serveur voit sa charge augmenter dans des proportions qui peuvent être considérables et qu'en cas de connexion lente, la navigation devient vite pénible, lorsqu'il y a beaucoup de traitement d'informations introduites par le client, comme des calculs exécutés à partir de données issues d'un formulaire.

HTML5 et CSS3 et suivants intègrent désormais la plupart des fonctionnalités qui étaient autrefois prises en charge par des plug-ins, javascript, bien qu'étant à ce jour (25/03/2025) un machin pas très propre, augmente encore les possibilités, à la condition que le navigateur soit «récent». Dans la pratique il y a toujours intérêt à utiliser la dernière version proposée.

Pour vous aider à mieux vous y retrouver, des exemples simples sont donnés plus loin.

(Multipurpose Internet Mail Extension. Format de messages de l'internet permettant de découper un message en plusieurs parties et d'y inclure des données non-ASCII, à savoir du son, des images..)
Définition empruntée au « Jargon Français ».

HTTP, un peu comme SMTP, ne sait pas nativement transporter autre chose que du texte. Il est bien connu de tous que le web propose aussi autre chose, comme des images (jpg, gif, png…), des animations et des documents aux formats plus ou moins particuliers (pdf, mpg, doc, xls, odt, ods…). Client et serveur doivent se mettre d'accord sur un moyen de coder ces information (serveur) et de les décoder (client) pour les afficher quand c'est possible, ou en proposer le téléchargement. Dans tous les cas, ces données non textuelles doivent être codées et décodées de façon cohérente.

Les cookies ne sont pas une mauvaise invention, c'est leur utilisation qui est parfois détournée à des fins contestables.

Contrairement à ce que l'on peut penser, Il n'existe pas de mémoire dans la navigation web.  Plus exactement, la notion de « session » n'existe pas (mais ça vient).  Pour bien comprendre, prenons un exemple simple : Vous entrez sur un site privé qui nécessite une authentification (nom d'utilisateur et mot de passe) A priori, sans l'aide des cookies, vous seriez probablement amené à vous identifier à chaque nouvelle page. Aujourd'hui d'autres techniques que le cookie sont développées pour répondre à cette question. Il n'en demeure pas moins que le cookie montre encore son utilité dans bien des cas.

Le principe est simple : Une fois authentifié, le serveur va déposer chez vous un « cookie » contenant des informations qu'il peut ensuite aller relire à chaque ouverture d'une nouvelle page, pendant toute la durée de vie de ce cookie.

Normalement, il n'y a que le serveur qui a déposé un cookie qui peut aller le relire (éventuellement un autre serveur du même domaine). Malheureusement, certains ont trouvé des moyens pour extorquer aux clients des cookies dont ils ne sont pas à l'origine, ce qui constitue un risque de sécurité, suivant les informations stockées dans ce cookie.

Nous allons profiter de l'occasion pour tordre le cou à une confusion trop souvent répandue entre deux méthodes qui permettent toutes deux l'accès au Net pour un réseau local :

• Le routeur NAT d'un côté.
  Le routeur NAT agit au niveau IP. Il fonctionne pour tous les protocoles applicatifs comme HTTP, FTP, mais aussi POP, IMAP, SMTP etc. (voir les chapitres dédiés : 110masquerade et Netfilter, Iptables, Nftables), puisqu'il agit au niveau IP.
• Le proxy de l'autre.
  Le serveur proxy travaille, lui, au niveau du protocole applicatif lui-même. Un serveur proxy n'assure aucun routage au niveau IP. En français, on appelle ça un serveur mandataire.

Pour l'exemple  nous mettrons en œuvre un serveur proxy libre sous Linux : le très célèbre SQUID dans le chapitre qui lui est dédié : Squid et SquidGuard.