Le protocole HTTP

Le protocole dans sa version 1.1 est décrit dans les RFC 2068 et 2069.
Une version française est pour la version 1.0 est disponible ici.
L’étude de HTTP est également extraite du site http://reseau.plisson.org.

Le protocole HTTP est basé sur un paradigme requête/réponse. Un client établit une connexion vers un serveur et lui envoie une requête sous la forme d’une méthode, d’une URI (Uniform Resource Identifiers), du numéro de version, suivi d’un message de type MIME (RFC 1521 - MIME permet de redéfinir le format des corps de message afin d’autoriser la représentation et l’échange de messages de texte formatté/multipart ainsi que de données non-textuelles et ce, sans perte d’information) contenant les modificateurs de la requête, les informations sur le client, et éventuellement un corps. Le serveur répond par une ligne d’état, incluant la version de protocole et un message de succès ou d’erreur, suivi d’un message de type MIME contenant l’information sur le serveur et le corps éventuel.

La plupart des communications HTTP sont initiées par un utilisateur et consistent en une requête devant être appliquée (il s’agit d’une méthode) à une ressource sur son serveur origine. Dans le cas le plus simple, ceci peut être réalisé par une connexion simple (v) entre l’utilisateur (UA) et le serveur origine (O).

Requête ------------------------>
UA -------------------v------------------- O
<----------------------- Réponse

Dans l’InterNet, les communications HTTP s’appuient principalement sur le protocole de connexion TCP/IP. Le port utilisé par défaut est le port TCP 80, d’autres ports pouvant être utilisés. Ceci n’exclut pas que HTTP puisse être implémenté au dessus d’un autre protocole d’InterNet, ou sur d’autres types de réseau. HTTP nécessite seulement un transport fiabilisé ; tout protocole garantissant la sécurité de transmission peut être utilisé pour supporter HTTP.

Excepté pour des applications expérimentales, la pratique courante spécifie qu’une connexion doit être initiée par un client avant transmission de la requête, et refermée par le serveur après délivrance de la réponse. Le client et le serveur doivent être préparés à ce que la connexion soit coupée prématurément (suite à une action de l’utilisateur, à une temporisation automatique, ou à une faute logicielle) ; ils doivent apporter une réponse prévisible à cette situation. Dans tous les cas, la fermeture d’une connexion qu’elle qu’en soit la raison est assimilable à la conclusion de la requête, quel que soit l’état.

Le schème "http" est utilisé pour localiser une ressource réseau via le protocole HTTP. Cette section définit la syntaxe et la sémantique des URL :

http_URL = "http:" "//" host [ " :" port ] [ chem_abs ]
host = [un nom Internet d’ordinateur valide ou une adresse IP (sous forme numérique), comme définie en Section 2.1 de la RFC 1123]
port = *DIGIT

Si le port est vide ou non spécifié, le port 80 est pris par défaut. La sémantique précise que cette ressource est localisée sur le serveur acceptant les connexions TCP sur ce port et sur cet ordinateur, l’URI de requête de la ressource en est le chemin d’accès absolu (chem_abs). Si chem_abs n’est pas précisé dans l’URL, il doit être remplacé par un "/" lorsque l’URI de requête est utilisée.

Note : bien que le protocole HTTP soit indépendant de la couche transport, l’URL http identifie la ressource par son adresse TCP. Les ressources non TCP devant être atteintes via un autre schème d’URI.

Le protocole a evolué entre la version 1.0 et la version 1.1

  la version 1.1 permet d’avoir plusieurs serveurs web sur la même adresse IP

  de nouvelles requêtes (content-type, patch, link, unlink, derived from, etc.) ont été ajoutées.

Présentation d’Apache

Source : Apache, installation et mise en oeuvre (O’Reilly 1999)
Site : http://www.apache.org
Une documentation en français est disponible ici.

Le serveur httpd apache est un serveur puissant, flexible qui implémente le protocole HTTP/1.1. Il est extrêmement configurable et basé sur des modules. On peut étendre ses fonctionnalités à l’aide de modules extérieurs à ceux livrés avec apache.

Le code source d’apache est librement modifiable. Il tourne sur une grande variété de plate-formes (UNIX propriétaires, BSD libres, linux, windows, etc.). Toutefois, apache est optimisé pour tourner sur des serveurs de type Unix (il paraît qu’apache tourne plus rapidement sur les unix libres de type BSD - net, open et free BSD). Sous windows, toutes les options ne sont pas disponibles.

Apache tient son nom du fait qu’il est constitué de code existant et de certaines pièces rapportées (patches) - a patch. Bien sûr, on peut également penser à la célèbre tribu d’indiens. Le premier serveur web fut réalisé par Tim Berners-Lee du CERN, à Genève, en Suisse. L’ancêtre immédiat d’Apache fut développé par le NCSA (National Center for Supercomputing Applications). Le développement de ce serveur ayant été stoppé - et le code étant libre -, un groupe de webmasters a entrepris de poursuivre le développement de ce programme sous le nom d’apache qui est de loin le serveur web le plus utilisé dans l’internet.

Nouveautés de la version 2.0

Améliorations du noyau :

  Threads sur Unix

Sur les systèmes Unix, Apache peut s’exécuter selon un modèle hybride multi-processus et multi-threads, en employant les threads selon la norme POSIX. Ceci devrait améliorer les performances.

  Nouveau système de construction

Le système de construction a été entièrement réécrit et repose sur autoconf et libtool. Cela rend le système de configuration plus semblable aux autres paquetages.

  Support multiprotocole

Apache possède maintenant une infrastructure afin de servir de multiples protocoles. mod_echo a été écrit comme exemple de ces nouvelles fonctions.

  Meilleur support des plates-formes autres qu’Unix

Apache 2.0 est plus rapide et plus stable sur les plates-formes non Unix telles que BeOS, OS/2, et Windows. Avec l’introduction des modules multi traitements (MPMs) spécifiques aux plates-formes et l’exécuteur portable Apache (APR), le code pour ces plates-formes est réalisé en employant leurs API natives, permettant ainsi d’éviter les couches d’émulation POSIX souvent boguées et peu performantes.

  Nouvelle API Apache

L’API pour les modules de la version 2.0 a changé de manière importante. Beaucoup de problèmes d’ordonnancement des modules existants dans la version 1.3 devraient disparaître. La version 2.0 gère ceci de manière automatique, et l’ordonnancement des modules s’effectue selon une fonction d’accrochage afin de permettre une plus grande flexibilité.

Améliorations concernant les modules :

  mod_auth_digest

Il inclut une nouvelle gestion des sessions en utilisant un cache commun aux processus grâce à une mémoire partagée. mod_charset_lite

  mod_charset_lite

Nouveau module dans Apache 2.0. Ce module expérimental permet la traduction des pages de caractères ou leur recodage. mod_dav

  mod_dav

Nouveau module dans Apache 2.0. Ce module met en oeuvre la spécification "HTTP Distributed Authoring and Versioning (DAV)" permettant de distribuer et maintenir le contenu d’un site web.

  mod_file_cache

Nouveau module dans Apache 2.0. Ce module inclut les fonctionnalités du module mod_mmap_static existant dans la version d’Apache 1.3, en ajoutant davantage de possibilités de cache.

La version actuelle du serveur apache est la 2.0.52. Toutefois, la migration des versions 1.3 vers les versions 2.0x n’étant pas évidente, apache continue de maintenir la version 1.3, la dernière étant la 1.3.31.

Configuration d’apache

On décrira l’installation du serveur qui tourne sur notre machine diamant. Cette version est la 2.0.51 et provient de la distribution fedora core 2.

L’utilisateur apache

Si l’on compile soi-même apache à partir du code source, le serveur http tournera avec les droits restreints ̶ pas d’accès au shell ̶ de l’utilisateur et du groupe nobody.

Depuis quelques années, les distributions Gnu/Linux créent un compte (uid 48) et un groupe (gid 48) apache et font tourner le serveur httpd sous cette identité qui n’a pas non plus d’accès au shell.

En fait, le premier processus est exécuté en tant que root mais les autres en tant qu’apache/apache.

Architecture

  les répertoires

Apache s’installe normalement dans le répertoire /usr/local/apache. Un certains nombre de sous répertoires sont créés :

bin => les binaires exécutables par tout le monde
sbin => le serveur httpd ainsi qu’un certain nombre de programmes annexes
libexec => les modules
conf => les fichiers de configuration
cgi-bin => le répertoire des fichiers exécutables par le serveur
logs => les logs
proxy
icons => les icônes
htdocs => les pages html

Toutefois, les distributions linux modifient cette architecture. La version installée sur le serveur diamant a l’architecture suivante :

bin => des utilitaires comme htpasswd (création de fichiers de mots de passe), etc.
sbin => /usr/sbin
libexec => /usr/lib/httpd/modules
conf => /etc/httpd/conf
cgi-bin => /var/www/cgi-bin
logs = > /var/log/httpd
icons => /var/www/icons
htdocs => /var/www/html

Un lien symbolique a été également créé de /usr/lib/httpd/modules à /etc/httpd/modules (cf. la directive LoadModule). Pareillement, un autre lien symbolique relie /var/log/httpd à /etc/httpd/logs.

  Les modules

Le serveur apache a été compilé de façon à séparer le serveur proprement dit des modules (parties autonomes du code source).
Les modules ont été compilés en dynamique : il s’agit de librairies DSO (Dynamic Shared Object Support).
Ainsi, en exploitation, il est possible d’activer ou de désactiver des fonctionnalités du serveur suivant ses besoins. Apache se lancera donc plus ou moins rapidement suivant que l’on inclura beaucoup ou peu de modules.
Cette fonctionnalité est disponible si et seulement si le serveur a été compilé avec les options --enable=so et --enable-shared=max.
On pourra donc installer ultérieurement (avec la commande apxs2, installée en standard) d’autres modules ou des versions plus récentes des mêmes modules.

Sur le serveur diamant, le binaire apache est le fichier /usr/sbin/httpd, les modules se trouvant eux dans le répertoire /usr/lib/httpd/modules.

On peut rapprocher cette architecture de celle du noyau linux : le noyau s’appelle /boot/vmlinuz et les modules se trouvent dans /lib/modules/[version du noyau].

Les fichiers de configuration

Le fichier sensible entre tous est le fichier httpd.conf, situé sur la machine diamant dans le répertoire /etc/httpd/conf.
Après une installation standard, toute la configuration est contenue dans ce fichier.

Toutefois, les distributeurs préconisent l’ajout de directives Include (gérées par le module mod_include.so) dans le fichier httpd.conf qui renvoient à d’autres fichiers situés parfois dans d’autres répertoires. Sur diamant, on aura :

Include conf.d/*.conf

C’est ainsi que la configuration ssl ira dans /etc/httpd/conf.d/ssl.conf. La configuration apache du module php (à ne pas confondre avec celle du fichier php.ini) dans /etc/httpd/conf.d/php, etc.

Cela permet de nettoyer le fichier de configuration. Notons que cette fonctionnalité n’existe que depuis la version 1.3

Etude du fichier httpd.conf

Ce fichier est séparé en plusieurs sections.

  La première section concerne la configuration générale d’apache.

• La directive ServerTokens concerne la façon dont apache s’annonce. Avec le paramètre OS, apache indiquera simplement sa version suivi du système d’exploitation. Soit, sur le serveur diamant :
  Apache/2.0.51 (Fedora)

L’important est de « cacher » la liste des modules activés au démarrage ainsi que leurs versions !

• La directive ServerRoot indique quel est le répertoire principal qui contient les sous-répertoires de configuration, des modules et des logs.
  Sur le serveur diamant, on a :
  ServerRoot "/etc/httpd"

Cela explique pourquoi on a dans /etc/httpd :

Comme la distribution Fedora « éclate » les répertoires d’apache en différents endroits de l’arborescence au lieu de tout mettre dans /usr/local/apache, il y a nécessité de jouer avec les liens symboliques.
Cela explique pourquoi on a d’autre part :
Include conf.d/*.conf

Ici le répertoire conf.d est bien un sous-répertoire de /etc/httpd.

• PidFile /var/run/httpd.pid
  Il s’agit du numéro de processus d’apache (s’il tourne).

• MaxClients 60
  Il s’agit du nombre de navigateurs qui peuvent accéder en même temps au serveur.

• Listen 80 _apache écoute les connections sur le port 80.

  On passe ensuite aux modules. En version 2, tout est simplifié. Plus besoin de directives ClearModuleList ou AddModule

• La directive importante est LoadModule qui va charger en mémoire le module correspondant. Par exemple :
  LoadModule auth_ldap_module modules/mod_auth_ldap.so

Il s’agit ici du module qui gère l’authentification via un annuaire LDAP.

  La deuxième section contient les paramètres du serveur principal, c’est à dire celui qui n’est pas défini en tant que « VirtualHost ».

• Les directives User et Group définissent l’utilisateur et le groupe avec lesquels va s’exécuter apache.

• ServerAdmin moineau@math-info.univ-paris5.fr
  (l’administrateur du serveur)

• ServerName www.ens.math-info.univ-paris5.fr

Utile pour forcer un alias défini dans le DNS : on évite de voir apparaître un nom de machine.

• La directive DocumentRoot définit le répertoire de base dont Apache servira les fichiers.
  Sur le serveur diamant, on a :
  DocumentRoot /var/www/html
  L’URL http://www.ens.math-info.univ-paris5.fr va afficher le contenu du fichier /var/www/html/index.html

• La directive UserDir indique quel est le nom du répertoire racine qui contient les pages d’un utilisateur. Par défaut, il s’agit de public_html.
  Ainsi, la page personnelle de l’utilisateur dupl peut être accessible sous l’URL suivante :
  http://diamant/˜dupl/.
  Le signe ˜ signifie comme sous Unix le répertoire de base de l’utilisateur. Mais ici, il s’agit du répertoire de base suivi du répertoire public_html.

• La directive DirectoryIndex définit quels sont les noms des fichiers d’index qu’apache peut utiliser. Si apache ne trouve pas de fichiers correspondant dans un répertoire donné, alors il reconstruit (s’il en a le droit), la liste des fichiers/répertoires présents dans le répertoire en question.
  Sur diamant, on a :
  DirectoryIndex index.html index.htm index.shtml index.cgi Default.htm default.htm index.php3 index.php

• La directive FancyIndexing facilite l’indexation. Par exemple, l’utilisateur peut cliquer sur le titre d’une colonne pour trier les entrées par valeur.

• La directive AddIcon indique au serveur quelle icône afficher suivant le type d’extension.

• La directive DefaultIcon indique au serveur quelle icône afficher si l’extension du fichier de ne trouve pas dans une des directives AddIcon définies ci-dessus.

On passe sur quelques directives mineures ou non implémentées à l’UFR...

• La directive AccessFileName est une directive de sécurité. Elle indique quel est le nom du fichier qu’apache doit scanner pour savoir si le répertoire est ou non protégé.
  Par défaut, on a :
  AccessFileName .htaccess

• La directive TypesConfig décrit quel est le fichier de description de types MIME qu’apache doit utiliser.
  Sur diamant, on a :
  TypesConfig /etc/httpd/conf/apache-mime.types

• La directive DefaultType indique au serveur quel est le type MIME par défaut des documents dont apache ne reconnaît pas l’extension.

• La directive AddLanguage permet de spécifier la langue d’un document.

• La directive LanguagePriority permet de définir l’ordre des priorités de langue.

• La directive Redirect fait correspondre un URL à un nouvel URL.

• La directive Alias permet de stocker les documents à un endroit du système de fichiers autre que DocumentRoot.
  Sur diamant, on a :
  Alias /icons/ /var/www/icons/

• La directive ScriptAlias permet de stocker sans danger des scripts/exécutables de type CGI (Common Gateway Interface) ainsi que de marquer les répertoires dans lesquels ils sont stockés comme des répertoires contenant des scripts/exécutables CGI.

• La directive AddType permet de faire en sorte que certains fichiers soient associés à certains types de fichiers. Cette option est déterminante pour le module php.
  Sur diamant on a :
  
  AddType application/x-httpd-php .php
  AddType application/x-httpd-php .php3
  AddType application/x-httpd-php-source .phps
  
  De cette façon, les fichiers .php3 sont reconnus par php4.

• La directive AddHandler permet notamment d’associer des types d’extension à certaines actions.
  En pratique, elle est essentiellement utilisée pour les scripts CGI.
  Sur diamant, on a :
  AddHandler cgi-script .cgi

• La directive ErrorDocument permet de personnaliser les messages d’erreur du serveur.
  Par exemple, pour éviter l’affichage du fameux « 404 not found », on peut créer un fichier missing.html. Dans ce cas, on pourra avoir :
  ErrorDocument 404 /missing.html

• La directive BrowserMatch permet de modifier le comportement standard d’apache en fonction du navigateur client.

  La troisième section a trait à la sécurité.

Elle permet notamment de restreindre l’accès à un certain nombre de répertoires. Pour des questions de lisibilité, il est possible dans faire un fichier autonome appelé par défaut access.conf. Ce fichier devra être défini à l’aide de la directive Include.
C’est donc dans cette section que l’on pourra définir des répertoires réservés à certains utilisateurs ou à certaines adresses ip.
Les permissions sont prises en charge par des modules d’apache. On a, suivant la configuration choisie :

mod_access, mod_auth, mod_auth_anon, mod_auth_db, mod_auth_dbm,mod_auth_digest, mod_auth_sys, etc.

On va d’abord commencer par définir des permissions générales pour les répertoires / et /home.
Note : le bloc Directory / définit les permissions générales par défaut : tout répertoire qui n’est pas redéfini par une autre directive Directory prend les valeurs du bloc <Directory />.

La directive AllowOverride indique au serveur apache quelles directives du fichier .htaccess peuvent « surcharger » des directives précédentes. Autrement dit, si AllowOverride a pour valeur None, alors aucun utilisateur ne pourra définir des droits spécifiques sur le ou les répertoire(s) qu’il gère.

Comme il s’agit du répertoire racine du serveur http, on peut lister le contenu d’un répertoire (Indexes), on autorise le serveur à utiliser des fichiers .shtml (Includes) et on autorise les liens symboliques uniquement si le propriétaire du lien est le propriétaire de la source (SymLinksIfOwnerMatch).

La configuration est la même pour le répertoire /users, là où sont stockés les répertoires des étudiants.

En revanche, à partir de l’arborescence /users/prof, on a en plus :

Les enseignants ont donc ici la possibilité de positionner des fichiers .htaccess.

On s’occupe maintenant des CGI :

La différence entre ces deux blocs tient au fait que, pour le premier bloc, tout le monde peut exécuter les CGI.
En revanche, la directive allow permet dans le deuxième bloc de filtrer l’accès. Ici, localhost signifie la machine serveur (diamant) mais on pourrait également réserver l’accès à une autre machine, à un domaine ou à une plage d’adresses IP.

Une autre méthode existe, celle fondée sur la directive Location.

On va voir maintenant une authentification fondée non sur des adresses ou un nom de domaine mais avec un annuaire LDAP.
Il s’agit, en test, d’un espace intranet créé pour la Licence Professionnelle.

La directive AuthName permet au navigateur d’afficher un message dans la barre du haut de la fenêtre de saisie de mot de passe.
On a ensuite des directives propres à l’interrogation d’un serveur LDAP.
On a enfin la directive require valid-user qui indique que l’authentification est obligatoire.

Pour cela, j’ai dû installer le module mod_auth_ldap qui est maintenant présent en standard - comme pour mod_ssl - dans la version 2 d’apache.
On note que la directive LDAP_StartTLS n’est pas implémentée dans la version 1.3 d’apache.

Les hôtes virtuels

Voici comment est géré le domaine virtuel uel.ens.math-info.univ-paris5.fr
Tout d’abord, on a rajouté un CNAME dans notre serveur de noms :

uel             IN      CNAME   www.ens.math-info.univ-paris5.fr.

Ensuite on a entré les lignes qui suivent dans le fichier Vhost.conf :

On peut aligner autant de virtual hosts que l’on veut avec la même adresse ip mais on doit :

  redéclarer notre serveur principal en tant que virtual host

  faire précéder les autres par la directive NameVirtualHost.

On peut également par ce mécanisme avoir des serveurs qui ne sont pas un sous domaine du serveur principal (ex : www.math-descartes.org) à condition :

  d’avoir déclaré le domaine math-descartes.org à un organisme qui gère les noms de domaine

  d’avoir configuré une zone spéciale du serveur de noms dédiée au domaine math-descartes.org.

SSL

Un fichier spécial existe pour la configuration cryptée du serveur diamant : /etc/httpd/conf.d/ssl.conf

Le serveur diamant a pour adresse ip 193.49.117.7

Il s’agit des options générales du module SSL. La configuration des hôtes virtuels https ira dans un autre fichier.

On charge d’abord le module :
LoadModule ssl_module modules/mod_ssl.so

Le serveur https écoute les connections effectuées sur le port 443 :
Listen 443

On ajoute les bons types MIME pour le téléchargement des certificats :

Enfin, https a ses propres logs :

Installation

L’installation d’apache est justement réputée pour être assez ardue.
La configuration des modules requiert en effet la présence de nombreuses librairies sur la machine serveur. Cela est particulièrement vrai pour le module mod_ssl qui permet de se connecter en https (port 443) sur le serveur serveur apache.
L’autre difficulté rencontrée est la compilation des modules d’apache non pas dans le binaire httpd mais comme modules dynamiques DSO.

C’est pourquoi les distributions linux fournissent en standard des binaires d’apache.
L’avantage évident est que l’administrateur ne doit s’occuper que de la phase de configuration et non de celle d’installation.
L’inconvénient est que la mise à jour est assez difficile :
  il faut attendre que le distributeur rende disponible une nouvelle version d’apache et de ses modules.
  suivant la distribution installée (et surtout de sa version), ces mises à jour sont régulières ou non.
  il faut également mettre à jour des librairies du système

=> au bout de quelques années de fonctionnement, cela n’est plus possible !

Heureusement, une solution intermédiaire existe !
Des administrateurs ont développé plusieurs scripts qui permettent une installation d’apache relativement simplifiée.

Pour ma part, J’ai utilisé le script ApacheToolBox

Sans rentrer dans les détails, il convient d’attirer l’attention sur le fait que le serveur https a besoin pour fonctionner correctement d’un certificat valide.

La partie la plus ardue de l’installation d’apache est génération du certificat SSL. Elle peut se faire lors de la compilation d’apache (make certificate) ou à tout moment (les instructions sont données sur le site http://www.modssl.org).

Normalement, on doit créer les clés publique et privée du serveur puis envoyer la clé publique à un organisme de certification qui va la contre-signer.

Cette opération étant par nature payante, on peut décider d’auto-signer soi-même sa clé. Il convient d’éviter alors un piège : le champ CommonName du certificat du serveur (server.key) doit contenir le nom véritable du serveur (ex. www.math-info.univ-paris5.fr) mais celui de l’autorité de certification (ca.key) doit être différent (ex. Centre de Calcul).

Si les deux champs sont identiques, des navigateurs comme Internet Explorer rejetteront la connexion....