Serveur HTTP simple

Pour observer les messages de reponses HTTP produits par un serveur Web classique, il est possible d'emettre des requetes simples en mode texte par l'intermediare d'une connexion TCP ouverte sur le port d'ecoute de ce serveur.

Par exemple, le serveur etudiant.univ-mlv.fr est accessible de l'interieur du domaine etudiant sur le port 80, et la machine qui heberge ce serveur a pour nom canonique kapouer.univ-mlv.fr. Ainsi, en ouvrant une connexion TCP sur le port 80 de cette machine par un utilitaire comme telnet ou nc (netcat) vous obtenez un terminal interactif connecte au serveur Web.

Vous pouvez demander a recuperer (methode GET) la ressource correspondant a la page d'accueil (/).
$ nc kapouer http
GET / HTTP/1.0

Experimentez quelques requetes simples sur cette connexion, en respectant le format des messages de requetes HTTP. En particulier, verifiez que :

• en version HTTP/1.0, le serveur repond sans champ Content-Length et ferme la connexion apres avoir envoye la reponse ;
• en version HTTP/1.1, le champ d'en-tete Host est obligatoire ;
• en version HTTP/1.1, la connexion n'est pas fermee par le serveur apres une reponse de succes. Dans ce cas, comment pouvez vous etre certain que la reponse a ete recue en entier ?
• une requete HEAD produit le meme resultat qu'une requete GET, mais sans le corps de message
• en HTTP/1.1, il est possible de demander explicitement au serveur de fermer la connexion apres l'envoi de la reponse (comment ?).

Écrire un petit programme Java qui permet d'émuler un serveur HTTP très simple. Vous pourrez le tester en faisant vos requetes depuis votre navigateur préféré (en interrogeant http://localhost:8080 par exemple).
Voici les fonctionnalités qui doivent être implantées par ce petit serveur:

• répondre aux requêtes GET des clients sur des noms de fichiers réguliers (pas les répertoires);
• attribuer le type MIME application/octet-stream aux ressources retournées. On pourra également faire des essais, plus visuels, avec les types text/plain ou text/html. Ensuite, on pourra tenter de déterminer le Content-Type à partir de l'extension du fichier à renvoyer;
• pour simplifier la gestion de la connexion avec le client, on pourra fermer la connexion après l'envoi de la ressource. En revanche, il est nécessaire de lire l'intégralité de la requête du client avant de fermer la connexion.
• Ajouter au serveur la fonctionnalité suivante: lorsqu'une ressource recherchée par un client n'est pas un fichier régulier, et que le serveur n'est pas en mesure de la retourner, renvoyer un message d'erreur 404 Not Found accompagné d'une page HTML expliquant poliment que la ressource n'est pas accessible. Faire la même chose avec une erreur 403 si la ressource demandée est un répertoire.