TCP non bloquant

Pour tout ce TP, nous allons écrire nos seurveurs dans le cadre fourni par les fichiers ChannelHandler.java et NioTCPServer.java . Ce cadre reprend le schéma du BiBuffer.

Réaliser un serveur Echo dans le cadre présenté ci-dessus.

Réaliser un serveur TCP LongSum comme dans l'exercie du TP précédent.

Écrire un petit programme Java qui permet d'émuler un serveur HTTP 1.0 très simple en ré-utilisant le serveur TCP avec un nombre de thread borné.
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 text/html aux ressources retournées.
• Si la ressource n'est pas trouvée, on renverra l'erreur 404 et si la commande n'est pas GET, on renverra l'erreur 502.
• 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 (on supposera qu'il n'y a pas de body) du client avant de fermer la connexion.

Dans le ChannelHandler, vous devrez maintenir un état (pour faire simple un int).

1. Dans l'état 1, on est en train de lire la première ligne de la requète. On lit jusqu'à trouver le premier octet \n. On passe ensuite dans l'état 2.
2. Dans l'état 2, on est en train de lire (sans le traiter) les headers. La fin du header est signaler par les 4 octets \r\n\r\n. Une fois cette lecture finie, il y a trois possibilités :
   1. La requête n'est pas une requète GET. On passe dans l'état 5 pour renvoyer l'erreur 502.
   2. La ressource n'est pas disponible dans le répertoire courant du serveur. On passe dans l'état 6 pour renvoyer l'erreur 404.
   3. Si la ressource est bien là, on passe dans l'état 3.
3. Dans l'état 3, on envoie le header de la réponse. A la fin de cette étape on passe dans l'état 4.Toutes les lignes sont terminées par \r\n

       HTTP/1.1 200 OK
       Content-type: text/html
       Content-length: 13298
   

4. Dans l'état 4, les octets correspondant à la ressource demandée puis on ferme la connection avec le client.
5. Dans l'état 5, les octets correspondant à l'erreur 502.

   HTTP/1.1 502 Not Found\r\n\r\n
   

6. Dans l'état 6, les octets correspondant à l'erreur 404.

   HTTP/1.1 404 Not Found\r\n\r\n
   

Le protocole HTTP
(Hyper Text Transfert Protocol) RFC 2616 (version 1.1). Protocole sans état, rapide, léger, de niveau application permettant le transfert de données au dessus d'une connexion de type TCP (sure). Ce protocole utilise les URLs : (port par défaut 80, basé sur le paradigme de requête / réponse). Chaque requête et chaque réponse est un " message HTTP ". Ce protocole est largement utilisé sur le World Wide Web.

Principe Requête/Réponse
Connexion TCP établie entre un client et le port 80 (en général) du serveur HTTP. Le client envoit un message HTTP, dit requête. Le traitement de cette requête est effectué par le serveur qui envoit un message, dit réponse, au client. En HTTP 0.9 et 1.0, la connexion est fermée par le serveur après chaque réponse. En HTTP 1.1, il est possible de conserver la même connexion TCP pour plusieurs échanges de requêtes/réponses.

Format des messages HTTP

    Ligne de début
    Champ d'en-tête_1: valeur_1
    ...
    Champ d'en-tête_n: valeur_n
                               // ligne vide \r\n
    [ corps éventuel ]
      

La présence de zéro, un ou plusieurs champs d'en-tête permet de spécifier des paramètres. La présence d'un corps de message dépend de la ligne de début de ce message.

Message de requête
Constitution de la première ligne de requête Méthode Ressource Version :
Exemple :

  GET /index.html HTTP/1.1
  Host: www.univ-mlv.fr

Méthode représente le type d'opération à effectuer : GET, HEAD, POST, PUT, TRACE,...
Ressource identifie la ressource recherchée
HTTP/1.1 exige que le champ Host soit spécifié
Version identifie la version du protocole utilisée. Si rien n'est spécifié, la version HTTP 0.9 est considérée.
Une requête HTTP a donc la syntaxe suivante (<CRLF> signifie retour chariot ou saut de ligne) :

METHODE URL VERSION<CRLF>
EN-TETE : Valeur<CRLF>
...
EN-TETE : Valeur<CRLF>
Ligne vide<CRLF>
CORPS DE LA REQUETE

Voici donc un exemple de requête HTTP :

GET http://www.commentcamarche.net HTTP/1.0
Accept : text/html
If-Modified-Since : Saturday, 15-January-2000 14:37:11 GMT
User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)

Message de réponse
Constitution de la ligne dite de statut : Version Code Message
Exemple :

    HTTP/1.1 200 OK
      Server: Netscape-Enterprise/4.1
      Date: Wed, 18 Sep 2002 09:30:24 GMT
      ...
      Content-type: text/html
      Content-length: 13298
      <!DOCTYPE HTML PUBLIC ....
      <html><head>
      ...
      </html>

Les codes de statut sont organisés en 5 catégories :

• 1xx informatifs : acceptés uniquement dans les versions 1.1. Réponse intermédiaire du serveur.
  Ex : 100 Continue
• 2xx de succès : la réception, la compréhension ou l'acceptation de la requête est réussie.
  Ex : 200 OK
• 3xx de redirection : d'autres actions sont requises pour traiter la requête.
  Ex : 301 Moved Permanently
• 4xx erreurs du client : erreur de syntaxe ou de spécification.
  Ex : 404 Not Found
• 5xx erreurs du serveur : serveur incapable de répondre.
  Ex : 501 Method Not Implemented

Quelques champs d'en-tête
Spécifiques (requêtes/réponses) ou bien généraux :

• Server (réponse) : informations sur le serveur HTTP
• Date (général) : estampille les messages HTTP
• Last-modified (serveur) : date de dernière modification
• ETag : identifiant de la ressource géré par le serveur
• Content-type (général) : type le corps du message
• Content-length (général) : nombre d'octets du corps
• Accept: text/plain (requête) : ce qu'accepte le client
• Accept-charset, Accept-language, Accept-encoding, Content-encoding, Transfert-encoding...

Réalisez un proxy TCP comme au TD 7 mais en non-bloquant.