L'objectif de ce projet est d'écrire un relais (proxy) filtrant HTTP/1.1 concurrent.
Un relais HTTP relaye les requêtes HTTP reçues d'un client vers le serveur demandé. En fait, au lieu de s'adresser directement au serveur contenant un document, le client fait la requête au relais, le relais relaye cette requête vers le serveur concerné ou un autre relais, il reçoit la réponse (le document) et le retourne au client. Le protocole de communication entre le client et le relais est HTTP, le seul impératif est que la ligne de requête (GET) HTTP contienne l'URL complet (en particulier, le nom du serveur auquel le relais doit s'adresser). Ce mécanisme de relais permet, entre autre, de filtrer les requêtes ou de cacher les documents récupérés. Les navigateurs classiques contiennent tous dans leurs préférences la possibilité de passer par un relais. Pour tester votre relais vous devrez utiliser cette possibilité.
Le filtrage consiste à interdire certaines opérations. Par exemple, le relais devra permettre d'interdire de récupérer des documents en provenance de certains sites, ou interdire les requêtes provenant de certains clients. Par défaut, tout client est interdit en entrée du relais et tout serveur est accepté en sortie. La configuration sera lue au démarrage depuis deux fichiers in.cfg et out.cfg.
Ces fichiers contiendront par exemple pour in.cfg :
deny
pcguest.univ-mlv.fr
allow *.univ-mlv.fr
Le relais accepte alors des requêtes en provenance de toute machine du domaine univ-mlv.fr sauf pctest. Dès qu'une directive correspond elle est appliquée sans tenir compte de la suite. Elles doivent donc être ordonnées de la plus précise à la moins précise.
Le relais est composé d'un ensemble de processus légers (thread). Leur nombre est variable est dépend de quatre variables (MIN_THREAD, MIN_SPARE_THREAD, MAX_SPARE_THREAD, MAX_THREAD) précisées dans le fichier de configuration du serveur relais.cfg.
MIN_THREAD définit le nombre minimum de processus légers à tout instant, en particulier au démarrage ;
MAX_THREAD définit le nombre maximum de processus légers ;
MIN_SPARE_THREAD définit le nombre minimum de processus légers libres (qui ne sont pas en train de traiter une requête), ce nombre conditionne la création de nouveaux processus légers ;
MAX_SPARE_THREAD définit le nombre maximum de processus légers libres, ce nombre conditionne la destruction de processus légers libres.
Les valeurs de MIN_THREAD et MAX_THREAD sont prioritaires par rapport à celles de MIN_SPARE_THREAD et MAX_SPARE_THREAD.
En plus de ces valeurs, le fichier relais.cfg devra contenir un ensemble de numéros de port TCP sur lesquels attendre les requêtes des clients, et le nom d'au moins un fichier de journalisation.
En effet, le serveur devra faire de la journalisation (logging). Le format sera le suivant :
[127.0.0.1] [Sat Mar 08 14:51:47] [GET
http://www.toto.com/icons/dir.gif HTTP/1.0] [ACCEPTED]
[128.93.7.60]
[Sat Mar 08 14:53:44] [GET http://www.microsoft.com/index.asp
HTTP/1.0] [DENIED]
Une fois que ces fonctionnalités minimales auront été implantées vous ajouterez, dans l'ordre, les fonctionalités suivantes.
Une gestion des droits de connexion au relais en fonction de l'utilisateur en utilisant l'authentification via HTTP Basic.
La configuration à distance et à la volée du relais via HTTP en utilisant des formulaires (arrêt et démarrage, changement du nombre de processus légers, etc...).
La supervision à distance via HTTP. Par exemple visualisation des log en fonction de différents critères (date, numéro ip source, destination, etc...).
Une gestion fine de la persistance des connexions HTTP/1.1. Plus précisément, découplez la gestion des connexions entre le client et le relais de la gestion des connexions entre le relais et le serveur, par exemple, garder la connexion ouverte entre le client et le relais alors que la connexion est fermée après chaque requête du relais vers le serveur.
La configuration et la supervision du relais en utilisant SNMP.
Une gestion de cache. Plutôt que de renvoyer uniquement les documents vers le client, le relais peut les stocker afin de les resservir ultérieurement. Attention à la concurrence, aux connexions interrompues par le client ou par le serveur, au temps stockage dans le cache, aux directives HTTP ...