PR : Contrôles des connaissances
2. Un serveur HTTP
projet 04/01/2017

Le projet consiste à écrire un serveur HTTP interprétant une version réduite du protocole HTTP/1.1 mais cependant suffisamment étendue pour qu’un navigateur usuel puisse s’y connecter à distance et soumettre certaines requêtes. La suite de l’énoncé précise le travail à effectuer, le document de référence en cas de besoin étant le rfc 2616, sa révision par les volumineux RFC 7230 à 7238 n’étant a priori pas nécessaire ici. Chaque question ajoute une fonctionnalité supplémentaire au serveur.

Le projet est à réaliser en binôme. Il est à rendre exclusivement sous forme de Zip via le formulaire ci-dessous, pour le Mercredi 4 Janvier 2017 à midi, le cachet de la méthode POST faisant foi. Il est possible et conseillé de déposer ses versions successives plutôt que d’attendre le dernier moment ; seule la dernière version déposée sera prise en compte.

Une Foire Aux Questions est ouverte à la fin de l’énoncé ; toute question à son propos devra être posée sur ce forum, afin que chacun dispose des mêmes informations.


1 Structure du serveur

Le serveur à écrire sera un programme C prenant en ligne de commande le numéro de port sur lequel le serveur écoute, le nombre de clients qu’il peut accepter simultanément, et un autre nombre qui fait l’objet de la question 5. Le serveur lancera une thread à chaque fois qu’un client se présente.

Dans cette première question, le serveur n’accepte que des requêtes HTTP de deux lignes ainsi formées :

GET /chemin HTTP/1.1
Host: 127.0.0.1

chemin est un fichier présent dans le répertoire où est lancé le serveur (le / initial indique la racine du répertoire géré par le serveur, pas la racine de tout le système de fichiers). Ces deux lignes sont suivies d’un nouveau saut de ligne, ce qui indique au serveur que la requête est complète et que le client attend en réponse le contenu du fichier indiqué.

La réponse du serveur commence par la ligne

HTTP/1.1 nnn Message

nnn est un nombre à 3 chiffres valant 200 si le fichier est bien accessible, 404 s’il n’existe pas, 403 si ses droits d’accès sont insuffisants, et où Message est respectivement OK, Not Found, Forbidden. Le serveur envoie ensuite une deuxième ligne commençant par "Content-Type: " suivi du type du fichier par exemple :

Content-Type: text/html

puis une ligne vide, et enfin le contenu du fichier. Il ferme ensuite la connexion.

Pour trouver le type du fichier à partir de son extension, il faudra analyser le fichier mime.types (généralement présent dans le répertoire /etc mais cela dépend des systèmes d’exploitation) qui est une suite de lignes dont le premier mot est le type, et les suivants les extensions qui lui correspondent ; on y trouve par exemple :

text/html                                       html htm shtml

Ces spécifications sont suffisantes pour qu’un navigateur usuel puisse recevoir et afficher tout fichier textuel transmis par ce serveur.


2 Journalisation

On souhaite ajouter au serveur la mémorisation des requêtes auxquelles il répond. On convient de placer ce fichier dans le répertoire /tmp, avec comme nom votre identifiant à 7 chiffres précédé de "http" et suivi de ".log". Chaque requête provoque l’ajout à la fin de ce fichier d’une ligne formée des informations suivantes séparées par un espace :

  1. adresse IP du client ;
  2. date de la requête, à la seconde près ;
  3. PID du serveur ;
  4. identifiant de la Thread traitant la requête ;
  5. première ligne de la requête ;
  6. code de retour à 3 chiffres renvoyé par le serveur ;
  7. taille du fichier envoyé.

Naturellement il faudra gérer les accès concurrents des Threads à ce fichier.


3 Fichier exécutable

On souhaite à présent que le client puisse spécifier comme chemin un fichier exécutable, qu’il s’agisse d’un binaire ou d’un script. Dans cette situation, le serveur doit créer un processus fils par fork afin que même en cas d’erreur dans cet exécutable, le processus principal n’en soit pas affecté. Plus précisément, le serveur doit surveiller cette exécution de sorte que :

Dans tous les cas le serveur devra fermer la connexion et réaliser la journalisation. Trouver en particulier une technique permettant au processus fils de communiquer à son père le code de retour à 3 chiffres et la taille de la réponse transmise dans le premier cas ci-dessus.


4 Requêtes persistentes

Une des supériorités de HTTP/1.1 sur HTTP/1.0 est de permettre à chaque client d’émettre plusieurs requêtes pendant une même connexion. Ces requêtes en rafale n’ont même pas besoin d’attendre la réponse à l’une avant d’émettre la requête suivante, du moment que le serveur :

Modifier le serveur afin qu’une connexion comprenant plusieurs requêtes d’affilée (donc séparées par des lignes vides) soient traitées chacune par une Thread différente. Il faudra évidemment ordonnancer leurs réponses afin de respecter la première contrainte ci-dessus.


5 Contrer le déni de services

Une des utilisations du fichier de journalisation consiste à examiner si certaines adresses IP envoient un ensemble de requêtes exigeant des réponses trop volumineuses de la part du serveur : un tel comportement est l’indice d’un visiteur non humain provoquant, plus ou moins volontairement, un déni de service pour les autres visiteurs. Pour une telle adresse, on souhaite qu’à la prochaine requête qu’elle émet, le serveur réponde immédiatement par un code de retour 403. Ce comportement durera pendant 10 secondes, chaque nouvelle requête remettant ce compteur à 0.

Afin de réagir le plus rapidement possible à cette situation, il faudra non seulement changer le serveur comme indiqué, mais également lui ajouter une nouvelle thread mémorisant en permanence les informations nécessaires pour calculer le volume de données transmis par le serveur dans la minute écoulée, pour chaque adresse IP. Chaque thread réalisant une requête devra transmettre à cette nouvelle thread la taille de ce qu’elle a envoyé à cette adresse (on pourrait évidemment aller lire la dernière ligne ajoutée au fichier de journalisation, mais on souhaite réagir plus rapidement).

Le seuil à partir duquel une adresse IP peut être considérée comme tentant un déni de service dépend de la machine utilisée et des fichiers qu’on souhaite diffuser. On prendra comme valeur le 3e argument passé au serveur sur la ligne de commande, afin de pouvoir tester facilement.


6 Rapport de travail

Aux fichiers C demandés aux questions précédentes, vous ajouterez un court rapport de travail, nommé selon les conventions ci-dessous, décrivant pour chaque question ce que vous avez fait ou non, et si oui comment.


7 Foire Aux Questions

Cliquer sur le lien ci-dessous pour poser une question à propos du projet.

Les questions et les réponses apparaîtront à la suite de ce texte, précédées de la liste de toutes les questions posées afin qu’un coup d’œil rapide (sans nécessité de défilement) permette de voir si une question a déjà été posée. Pour profiter au maximum de cette fonctionnalité, pensez à donner un titre significatif, et différent de tous les titres précédents.

Titres des 35 intervention(s)


  • Fichier envoyé ? 4303
    31 décembre 2016 à 12h23min

    Bonjour

    Est-ce normal que les champs "Fichiers" et "Action" (cf pj) soient vide ?

    Cordialement

    • Fichier envoyé ? 4306
      1er janvier 2017 à 14h13min par Saint James Emmanuel

      Comme vous ne vous êtes pas authentifié avant d’envoyer ce message non signé, je ne peux vous dire s’il y a quelque chose d’anormal ou pas vous concernant. Indiquez impérativement votre numéro d’étudiant ou authentifiez-vous. Je pourrai alors vous dire si votre envoi fait partie des 10 projets déjà bien arrivés à ce jour.

      • Fichier envoyé ? 4308
        1er janvier 2017 à 16h07min

        Le numéro étudiant est 3504018,

        Encore merci !

        • Fichier envoyé ? 4310
          1er janvier 2017 à 17h48min par Saint James Emmanuel

          Votre Zip a été refusé par le formulaire sans que les logs donnent plus de précisions. J’ai augmenté leur niveau, essayez à nouveau, et envoyez moi un mail pour ne pas encombrer cette FAQ avec ce problème technique.

  • Emplacement dans le Makefile 4292
    28 décembre 2016 à 16h15min par Salleron Nicolas

    "Cette compilation provoquera la création d’un répertoire /tmp/$USERS, et tous les fichiers créés par le Makefile devront l’être dans ce répertoire exclusivement."

    On parle bien du répertoire courant donc "./tmp/$USERS" et non de la racine du système ?

    • Emplacement dans le Makefile 4293
      28 décembre 2016 à 18h07min par Saint James Emmanuel

      Si, il s’agit de la racine du système.

      • Emplacement dans le Makefile 4298
        30 décembre 2016 à 11h07min

        J’en profite, mais pour la question 2 c’est également la racine du système du coup ?

        • Emplacement dans le Makefile 4299
          30 décembre 2016 à 15h29min par Saint James Emmanuel

          Oui, c’est la racine du système.

  • Question 5 : Gestion de l’exécutable 4267
    26 décembre 2016 à 19h16min

    Bonjour,

    Etant donné que l’exécutable écrit au client, on ne connaît pas à l’avance la quantité de données qu’il va envoyer, on a cette information lorsque l’exécutable a déjà répondu au client.
    Dans ce cas là comment gérer le seuil limite de données ?

    Merci pour votre réponse

    • Question 5 : Gestion de l’exécutable 4268
      26 décembre 2016 à 21h06min par Saint James Emmanuel

      A la question 4 il a été demandé que le début de la réponse comporte l’en-tête Content-Length, indiquant la longueur de la réponse. Dans le cas d’un exécutable, il est censé fournir cet en-tête, et cela répond à votre question. S’il ne l’a pas fait, on a le choix entre deux stratégies côté serveur. Soit faire au minimum en ne cherchant pas à connaître cette longueur, et renoncer à l’éventuelle connexion persitante. Soit faire au maximum en capturant le flux de sortie de l’exécutable, afin de calculer l’en-tête manquante, l’envoyer d’abord puis envoyer tout le flux capturé, ce qui vous ramène à la situation précédente.

  • Question 3 : crash de l’exécutable 4255
    24 décembre 2016 à 12h20min

    Si l’exécutable crash durant son exécution (par exemple une division par 0 ou toute erreur de ce type provoquant un crash), comment devons nous gérer ce cas étant donné que le fils ne renvoie éventuellement pas un code de retour différent de 0 ?

    Merci de votre réponse

    • Question 3 : crash de l’exécutable 4257
      24 décembre 2016 à 13h49min par Saint James Emmanuel

      C’est typiquement le cas où le rôle du processus père est de retourner lui-même le code de retour 500 pour indiquer qu’il y a eu un problème de son côté. Les pères sont responsables des bêtises de leurs fils visiblement peu adultes.

  • Question 4 : Code de retour lors d’une rafale de requête 4253
    21 décembre 2016 à 12h47min

    Bonjour,

    Lors d’une rafale de requête, devons-nous renvoyer un code de retour 100 avec le message de retour "Continue" pour chaque requête de la rafale ?

    Par ailleurs, comment devons-nous traiter le cas où deux requêtes arrivent séparément (par exemple avec 3-4 secondes d’intervalle) lors d’une même connexion ?

    Cordialement

    • Question 4 : Code de retour lors d’une rafale de requête 4254
      21 décembre 2016 à 17h19min par Saint James Emmanuel

      Chaque requête doit recevoir son code de retour. Le code 100 n’est utilisé que lors de connexion lente, le serveur signifiant ainsi qu’il n’a reçu que le début d’une requête et qu’il attend la suite ; mais cela n’est pas à programmer dans le cadre du projet.

      Votre deuxième question m’est obscure : le serveur répond à une requête dès qu’elle est entièrement exprimée (c’est-à-dire suivi de deux lignes vides), passe à la suivante s’il y en a une etc. Le temps d’émission entre deux requêtes sur une même connexion n’est à prendre en compte que si on veut instaurer un Timeout de la part du serveur.

  • GET dossier ? 4251
    20 décembre 2016 à 22h59min par Lacour Hadrien

    Que devons-nous renvoyer (ou quelle erreur) lorsque le chemin de la requête réference un dossier ?

    • GET dossier ? 4252
      21 décembre 2016 à 09h30min par Saint James Emmanuel

      Bonne question. Les serveurs HTTP standards ont un fichier de configuration pour préciser que faire (chercher un "index.html" dans le dit répertoire etc). En l’absence de celui-ci, et en se souvenant que le problème est plus général (par exemple ça peut référencer un Pipe nommé ! ), on doit plutôt considérer qu’il s’agit d’une mauvaise requête, donc envoyer un code de retour 400.

  • Identifiant thread 4249
    20 décembre 2016 à 02h01min par Lacour Hadrien

    Vu qu’il n’y a aucun moyen d’avoir l’identifiant d’un thread de manière portable (POSIX, cf. http://pubs.opengroup.org/onlinepub... rubrique RATIONALE), que sommes-nous censés faire pour la question 2 ?
    - Considérer que l’OS est GNU/Linux -> syscall(SYS_gettid) ou cast en en unsigned long
    - Afficher le résultat de pthread_self en hexadécimal et prier pour que le résultat soit unique

    • Identifiant thread 4250
      20 décembre 2016 à 16h35min par Saint James Emmanuel

      Vous êtes censé faire ce que vous avez appris ce semestre : utiliser pthread_self (mais je ne me souviens pas qu’on vous ait appris à prier ce semestre :-)). Vos remarques sont fondées mais ce point du projet est vraiment très marginal : l’idée était plutôt qu’en précisant le numéro de thread et pas seulement le numéro de processus, ça permettait plus facilement de contrôler quel thread s’occupe de quel requête.

  • Question 3 : Eclaircissement de la question 4241
    16 décembre 2016 à 17h38min

    Comment l’exécutable peut-il répondre au client s’il ne le connaît pas ?
    Supposons nous que nous passons les informations du client en argument de l’exécutable ?

    D’une manière générale pouvez vous expliciter la question 3 et plus précisément ce que fait l’exécutable dans un cas nominal ?

    Merci d’avance pour votre réponse

    • Question 3 : Eclaircissement de la question 4244
      16 décembre 2016 à 20h06min par Saint James Emmanuel

      Déjà répondu en 4023.

  • Question 3 : Eclaircissement de l’énoncé 4240
    16 décembre 2016 à 17h37min par Nguyen Thi Phan Nguyet

    Bonjour,

    De quoi il s’agit "la réponse transmise" à la fin de la Question 3 ?
    C’est la réponse "HTTP/1.1 200 Ok" + "Content-Type : ..." + le contenu du fichier ou la réponse rendue par l’exécutable ?

    • Question 3 : Eclaircissement de l’énoncé 4243
      16 décembre 2016 à 19h37min par Saint James Emmanuel

      Le message 4142 donne un exemple minimal d’exécutable actionné via HTTP. Le contenu du fichier est le code à exécuter, il n’est pas à envoyer.

  • requêtes persistantes : journalisation 4237
    16 décembre 2016 à 14h37min

    Bonjour,
    Dans le cas des requêtes persistantes, est-il permis de journaliser qu’une seule fois par connexion (et non par nombre de requêtes contenues dans une connexion) ?

    Aussi, est-il permis de découper le travail d’une thread en deux parties ? sachant que chaque partie sera traitée d’une façon séquentielle par une thread différente. Au bout de compte, pour chaque client et à chaque instant, une seule thread est dédiée à ce client.

    • requêtes persistantes : journalisation 4239
      16 décembre 2016 à 15h22min par Saint James Emmanuel

      La question 2 demande bien que chaque requête provoque sa journalisation. Attendre la fin de la connexion pour cela aurait pour effet qu’un attaquant pourrait commencer à opérer incognito pendant toute la durée de sa connexion, ce n’est pas raisonnable.

      Je ne suis pas sûr de comprendre votre deuxième question, mais votre idée ne me paraît pas compatible avec ce qui est demandé : il faut une thread par requête, elles peuvent parfaitement coexister (l’une lit un fichier, l’autre exécute qqch, une troisième contacte un autre serveur etc).

  • HTTP keep-alive 4230
    15 décembre 2016 à 13h37min

    Bonjour,

    Sommes-nous amenés à considérer le cas d’une connexion keep-alive durant l’élaboration du projet puisque le HTTP1.1 permet de le faire ?

    En d’autres termes, devons-nous rester à l’écoute d’une connexion jusqu’à ce qu’elle soit définitivement fermée ?

    • HTTP keep-alive 4235
      16 décembre 2016 à 09h07min par Saint James Emmanuel

      Le serveurs HTTP ont l’habitude de limiter de plusieurs manières les requêtes persistentes : durée maximale, nombre de requêtes maximal, taille maximal des réponses ou autres. Vous êtes libre de fixer la politique de votre serveur sur ce point. Il est certain qu’attendre que le client prenne l’initiative de la fin de connexion est la politique la moins pertinente.

  • explication sur le rendu 4228
    15 décembre 2016 à 10h41min par Bakkouri Adil

    Bonjour,
    est ce que on a le droit de joindre nos fichiers dans des repértoires (SRC,INCLUDE,LIB,RESSOURCE,BIN,OBJ) ? sachant qu’on a un MAKEFILE qui s’occupe de la compilation et du test.

    • explication sur le rendu 4229
      15 décembre 2016 à 13h28min par Saint James Emmanuel

      Réponse à cette question dans le message 4022. Merci de lire les questions précédentes avant d’en poser une nouvelle.

  • Question 1 : Téléchargement du fichier 4216
    14 décembre 2016 à 13h20min

    Bonjour,

    Lorsque le client demande un fichier image ou audio par exemple, doit-on faire en sorte que le navigateur lance le téléchargement du fichier ? Ou le navigateur affiche seulement le contenu du fichier ?

    Merci

    • Question 1 : Téléchargement du fichier 4218
      14 décembre 2016 à 14h10min par Saint James Emmanuel

      Votre question, si je la comprends bien, est hors sujet : le serveur envoie au client un document en annonçant son type par l’en-tête Content-Type ; ensuite c’est le client qui décide quoi en faire selon ses possibilités : il y a beaucoup de formats d’images et audio, et aucun navigateur ne sait les gérer tous. Encore une fois ce n’est pas du ressort du serveur que vous avez à écrire.

  • Parallélisation 4215
    14 décembre 2016 à 12h32min par Dominguez Jose-Paul

    Peut on dériver un peu de l’énoncé et gérer un pool de threads prêts au lieu de lancer un thread par connexion acceptée ?

    • Parallélisation 4217
      14 décembre 2016 à 14h07min par Saint James Emmanuel

      Si vous voulez, mais il faudra motiver ce choix, et gérer proprement le cas où tous les thread sont occupés.

  • Deni de service : nombre des adresses IP 4213
    13 décembre 2016 à 22h02min par Mehellou Abdelatif

    Bonjour,

    pour le control de deni de service, je voudrais savoir est ce qu’il y a des contraintes sur le nombre des adresses IP qu’on doit mémoriser leur quantité de donnée envoyer, ou on prend un nombre arbitraire,par exemple les 4 dernier adresses IP. on prend que la dernière, comme en travail localement, donc c’est toujours le localhost.

    • Deni de service : nombre des adresses IP 4214
      14 décembre 2016 à 09h17min par Saint James Emmanuel

      Toutes les adresses IP sont à surveiller.

      • Deni de service : nombre des adresses IP 4290
        28 décembre 2016 à 14h21min par Mehellou Abdelatif

        dans le cas ou l’adresse IP X depasse le seuil et il répond immédiatement par l’erreur numéro 304 et ferme la connexion. est ce qu’on fait la journalisation dans ce cas ?

        • Deni de service : nombre des adresses IP 4291
          28 décembre 2016 à 15h41min par Saint James Emmanuel

          L’erreur 403 vous voulez dire. Oui, il faut toujours faire la journalisation.

  • Nombre de thread 4210
    13 décembre 2016 à 19h08min

    Le nombre de thread lancés par le serveur est-il limité d’une quelconque manière ?
    Est-il autorisé de lancer un nombre de thread supérieur au nombre de clients que peut accepter simultanément le serveur, sans avoir à gérer de pool de thread ?

    • Nombre de thread 4212
      13 décembre 2016 à 20h39min par Saint James Emmanuel

      Le nombre de thread n’est pas limité.

  • Foire Aux Questions 4209
    13 décembre 2016 à 15h07min par Fernandez Alexandre

    Bonjour, est-on obligé de compiler avec -ansi ?

    Merci de votre attention.

    • Compilation -ansi 4211
      13 décembre 2016 à 20h38min par Saint James Emmanuel

      Non ce n’est pas obligatoire. Une question quasi-identique a été posée ci-dessous, pensez à les lire et à donner un titre significatif à vos questions.

  • Contrer le déni de service 4162
    12 décembre 2016 à 14h48min par Koehler Thomas

    Bonjour,
    Pour contrer le déni de service peut on utiliser une simple fenêtre de 1mn au terme de laquelle tous les compteurs sont remis à zéro ou doit-t-on avoir une gestion plus fine ?
    Je m’explique par un exemple :
    - T le début d’une fenêtre
    - T + 0.8 mn, C demande N1 données
    - T + 1mn, changement de fenêtre, remise à zéro
    - T + 1.2 mn, C demande N2 données
    à ce moment là avec une simple fenêtre on a, avec NC le compteur de C :
    NC = N2
    cependant avec une gestion plus fine on pourrais remarquer que :
    NC’ = N1 + N2
    car en réalité N1 a été demandé il y a moins d’une minute.

    • Contrer le déni de service 4170
      13 décembre 2016 à 10h54min par Saint James Emmanuel

      Il faut avoir une gestion fine, autrement un attaquant pourrait exploiter l’intervalle de temps où il n’est pas vraiment contrôlé.

  • Question 5 : Eclaircissement de l’énoncé 4159
    12 décembre 2016 à 13h57min par Idri Sofiane

    Bonjour,

    En considérant la valeur que le serveur reçoit en 3e argument comme étant le seuil/Période, ou Période=1minute dans notre cas. Alors, peut-on considérer les 10 secondes citée dans l’énoncé de la question 5 comme étant, d’une la valeur ajoutée à la Période pour la dernière requête émise par une IP qui a déjà atteint son seuil/Période, et d’autre part, une période de référence pour le calcul de la valeur à ajouter pour les requêtes précédant sa dernière dans un intervalle de temps de 10 secondes en arrière ?

    Ainsi, pour la réception de deux requêtes émise par une IP qui a déjà atteint le seuil, séparées, à titre d’exemple, de 5 secondes. donnera
    seuil(IP)=seuil/(Période+15).

    Merci d’avance pour votre éclaircissement.

    • Question 5 : Eclaircissement de l’énoncé 4161
      12 décembre 2016 à 14h16min par Saint James Emmanuel

      Votre question est grammaticalement incorrecte jusqu’à la rendre incompréhensible. L’important est de ne pas répondre à une adresse IP suspecte pendant 10 secondes au moins. On pourrait raffiner la question en augmentant la pénalité selon des critères supplémentaires, mais ce n’est pas la peine de compliquer les choses : l’essentiel est de comprendre comment un serveur HTTP peut lutter contre le déni de service.

      • Question 5 : Eclaircissement de l’énoncé 4163
        12 décembre 2016 à 15h07min

        Le point sur lequel nous demandons un éclaircissement est le suivant :
        Supposons que le seuil soit de : 100 octets/minute et que le seuil soit atteint au bout de 10 secondes, i.e, il a déjà reçu 100 octets au bout de 10 secondes. Il n’envoie ensuite aucune requête pendant 10 autres secondes, faut-il donc le débloquer au bout de ces 10 secondes ?
        Alors que le seuil est de 100 octets/minute, ne doit-on pas plutôt attendre la fin de la minute ?

        • Question 5 : Eclaircissement de l’énoncé 4169
          13 décembre 2016 à 10h50min par Saint James Emmanuel

          Sans rajouter de code, on aura l’équivalent d’un rejet de 1 minute dans votre exemple : au bout de 10 secondes on accepte la requête, on s’aperçoit que le seuil est déjà dépassé, donc on repart pour 10 secondes d’arrêt. Au bout du compte, si une seule requête avait dépassé le seuil à elle seule, le client sera bloqué 6 fois pendant 10 secondes, cela revient au même.

  • Question 5 - Le troisième nombre 4154
    11 décembre 2016 à 16h49min

    "Le seuil à partir duquel une adresse IP peut être considérée comme tentant un déni de service dépend de la machine utilisée et des fichiers qu’on souhaite diffuser. On prendra comme valeur le 3e argument passé au serveur sur la ligne de commande, afin de pouvoir tester facilement."

    Le 3ème argument passé au serveur représente donc la taille maximal d’envoi pour une adresse IP ?

    • Question 5 - Le troisième nombre 4156
      12 décembre 2016 à 08h44min par Saint James Emmanuel

      La taille maximale par minute, oui.

  • Foire Aux Questions 4137
    9 décembre 2016 à 23h55min par Mehellou Abdelatif

    Bonjour,

    pour la partie 3 fichier exécutable, est ce que c’est correcte si le serveur traite que les fichiers de type text/x-shellscript pour les scripts et application/x-executable pour l’executable ou on doit traiter d’autre cas, parce que chaque cas à un traitement spécifique à faire.

    • Type de l’exécutable 4142
      11 décembre 2016 à 08h44min par Saint James Emmanuel

      Le type MIME d’un exécutable est totalement indifférent : le serveur décide de lui passer la main simplement parce que le Chmod indique qu’il est exécutable. Le type MIME de la réponse est décidé par l’exécutable et n’a aucun rapport avec le type MIME de celui-ci, il n’y a aucune distinction à faire là-dessus. Pour fixer les idées, voici un exécutable minimal fournissant une réponse bien formée ; il est écrit en Shell mais pourrait être écrit en n’importe quel autre langage, y compris en binaire :

      #!/bin/sh
      echo "Content-Type: text/plain; charset=utf-8"
      echo
      date
  • Question 4 - intérêt de l’utilisation de plusieurs threads 4031
    6 décembre 2016 à 09h53min par Chouteau Clement

    Bonjour,

    Dans la question 4, il est demandé :
    "plusieurs requêtes d’affilée (donc séparées par des lignes vides) soient traitées chacune par une Thread différente. Il faudra évidemment ordonnancer leurs réponses afin de respecter la première contrainte ci-dessus"

    Les requêtes d’affilés doivent êtres traités par des threads différents, mais si l’on impose que les réponses arrivent dans l’ordre alors seulement un seul thread peut envoyer une réponse à la fois, cela n’apporte donc rien aux performances, ou bien il y a quelque chose que je n’ai pas compris dans l’énoncé ?

    Merci

    • Question 4 - intérêt de l’utilisation de plusieurs threads 4032
      6 décembre 2016 à 11h12min par Saint James Emmanuel

      Si la réponse à une requête est bloquée pour une raison quelconque (accès à une ressource non disponible ou lente), l’utilisation de threads pour les réponses suivantes permettront à celles-ci d’être préparées pendant le temps d’attente de celle qui est bloquée. Evidemment cela n’est perceptible que si les suivantes ont un minimum de travail à faire avant d’avoir quelque chose à envoyer, mais c’est toujours le cas (en particulier déterminer la taille de la réponse).

  • Question 3 - Création du fils 4025
    5 décembre 2016 à 14h33min

    Bonjour,

    j’ai une interrogation quant-à la question 3. Il est dit dans l’énoncé (en résumé) que le serveur doit créer un fils qui exécute l’exécutable demandé par le client puis, que le serveur surveille l’exécution de son fils. Le serveur doit-il créé un fils directement ou il doit créé un Thread qui lui créera un fils ?
    Car attendre 10 secondes pour attendre que son fils se termine est un temps bien trop long qui empêcherai les autres clients de se connecter.

    Merci par avance pour votre réponse.

    • Question 3 - Création du fils 4026
      5 décembre 2016 à 14h59min par Saint James Emmanuel

      Vous êtes libre de choisir votre stratégie, du moment que le fichier exécuté, s’il ne se termine pas normalement, n’entraîne pas l’arrêt ou le dysfonctionnement du serveur.

      • Question 3 - Création du fils 4033
        6 décembre 2016 à 11h25min

        Bonjour,

        j’ai une autre question. Je ne comprends pas ce que doit faire le fichier exécutable, doit-il communiquer avec le client ou pas ? Et si oui, que doit-il envoyer au client ?

        • Question 3 - Création du fils 4034
          6 décembre 2016 à 13h16min par Saint James Emmanuel

          N’avez-vous jamais rempli un formulaire sur un site Web ? Ne vous êtes-vous jamais dit qu’une page Web qui vous dit que vous êtes le N-ième visiteur n’est pas un simple fichier textuel mais un exécutable gérant un compteur ? Cet exécutable renvoie un en-tête Content_type comme à la première question, d’autres en-têtes HTTP au besoin, puis un document du type annoncé : HTML, TXT, SVG, MP3 ou n’importe quoi d’autre. Simplement il a effectué des calculs avant d’envoyer tout ça, rien n’indiquant au client que la réponse qu’il reçoit n’est pas le contenu d’un fichier pré-existant mais le résultat d’une exécution.

  • Question 3 - récupération du code retour 4023
    3 décembre 2016 à 23h15min par Chouteau Clement

    Bonjour,

    Je ne comprends pas comment on pourrait trouver une "technique" (question 3, dernier paragraphe) pour obtenir le code retour du fils.

    Si j’ai bien compris, le fils est un exécutable quelconque qui est censé envoyer des paquets TCP au client (qu’il ne connaît même pas).
    Le père est censé espionner les paquets du fils pour détecter le code retour.

    • Question 3 - récupération du code retour 4024
      4 décembre 2016 à 17h39min par Saint James Emmanuel

      Il ne s’agit nullement de descendre au niveau TCP. Les exercices que nous avons fait ce semestre autour des flux d’entrée et de sortie devraient vous suffire pour trouver comment le fils peut communiquer au père ce qu’il doit communiquer aussi au client.

      • Question 3 - récupération du code retour 4028
        5 décembre 2016 à 22h22min

        Bonjour,

        Pourriez-vous, s’il vous plait, me confirmer que c’est bien à nous de créer le fichier exécutable. Ainsi, on adopterait l’approche adéquate afin de permettre la transmission des informations nécessaires et cela dans les deux sens.

        • Question 3 - récupération du code retour 4030
          6 décembre 2016 à 07h56min par Saint James Emmanuel

          Pas du tout, l’un des rôles d’un serveur HTTP est justement de lancer l’exécution de fichiers écrits par d’autres. Du reste, la question sera sans intérêt sinon.

  • Format de rendu 4021
    3 décembre 2016 à 14h28min par Koehler Thomas

    Bonjour,
    Peut-on fournir un rapport en ’.md’ ?
    "L’archive ne devra contenir aucun sous-répertoire"
    Donc nous n’avons strictement le droit à aucun répertoire, même pas de ’src’ ou autre ?

    • Format de rendu et répertoires inutiles 4022
      3 décembre 2016 à 16h19min par Saint James Emmanuel

      Pas de format nécessitant d’aller charger une application non disponible dans les OS usuels, donc pas ".md" en particulier.

      Pour les répertoires, le contenu du Makefile esquissé à la fin de l’énoncé réduit ceux utilisés d’ordinaire à Src et Include. Vous pouvez à la rigueur créé ces deux répertoires, mais l’essentiel de la recommandation consiste à ne pas laisser dans votre rendu des répertoires cachés (préfixés par ".") contenant des sauvegardes et des profils énormes, qui conduiraient à un temps déballage et une occupation mémoire énorme étant donné le nombre d’inscrits

  • Rafale de requête 4003
    2 décembre 2016 à 18h43min

    Bonjour,

    Comment pouvons-nous envoyer une "rafale de requête" à partir d’un navigateur internet ?

    Merci par avance pour votre réponse.

    • Rafale de requête 4020
      3 décembre 2016 à 11h49min par Saint James Emmanuel

      C’est possible avec du JavaScript, mais c’est plus simple d’utiliser des clients HTTP non graphiques comme Curl ou Wget, et de programmer une boucle en Shell les appliquant sur le serveur.

      • Rafale de requête 4115
        9 décembre 2016 à 11h32min par Mehellou Abdelatif

        Bonjour,

        je suis entrain d’utiliser Curl pour envoyer plusieurs requete, avec une boucle dans un script, pour chaque appel à Curl url, va générer une nouvelle requete GET ce qui provoque l’établissement d’une nouvelle connexion, donc nouvellle socket. j’ai essayé d’appeler Curl avec plusieur url mais les connetions ne sont pas " persistantent" . est ce qu’il y a d’autre alternatif.

        • Rafale de requête 4129
          9 décembre 2016 à 14h02min par Saint James Emmanuel

          En effet CURL va ouvrir une nouvelle connexion à chaque fois mais ça n’a pas d’importance : un déni de service doit être combattu même s’il est organisé à partir de plusieurs connexions. C’est d’ailleurs pourquoi il faut analyser le journal : si on se limitait à une seule connexion, il suffirait de compter le nombre de requêtes sur celle-ci.

          • Rafale de requête 4130
            9 décembre 2016 à 14h12min par Mehellou Abdelatif

            pour le traitement de déni du service, le paramètre X représente la quantité du donnée envoyé au Client pout tout les fichiers ou pour le mème fichier. pour savoir si on n’accepte plus de connexion du Client pour tout les GET ou juste pour GET du meme fichier qui a depassé X.

            • Rafale de requête 4135
              9 décembre 2016 à 16h14min par Saint James Emmanuel

              Distribuer les requêtes sur plusieurs fichiers est une technique des attaquants pour essayer de masquer leur tentative de déni de service : c’est bien le total des demandes d’un client qu’il faut considérer.

      • Rafale de requête : test d’envoyer plusieurs requêtes 4269
        26 décembre 2016 à 22h35min par Nguyen Thi Phan Nguyet

        Bonjour,
        Est-ce que wget -i list-requets.txt où list-requets.txt est par ex :
        localhost:2000/file1
        localhost:2000/file2

        est une bonne façon pour le test d’envoyer plusieurs requêtes dans une même connexion ?

        Je vous remercie,

        • Rafale de requête : test d’envoyer plusieurs requêtes 4271
          27 décembre 2016 à 09h36min par Saint James Emmanuel

          La documentation de wget semble dire que oui. Je pense qu’utiliser l’option -B, et de mettre dans le fichier que des URL relatives (sans http://localhost) serait plus sûr. Vous devriez pouvoir le vérifier au niveau de votre serveur.

  • Foire Aux Questions 4002
    2 décembre 2016 à 17h29min

    Bonjour,

    Les clients (navigateurs, ici) doivent se connecter au serveur via un port. Or, le champs Host de la requête http devient du type 127.0.0.1:port, ce qui ne correspond pas exactement à l’exemple de l’énoncé. Faut-il parser en prenant en compte le port ?

    Merci.

    • Choix du port 4019
      3 décembre 2016 à 11h45min par Saint James Emmanuel

      L’en-tête Host n’intervient qu’après la connexion, essentiellement pour gérer les proxys et les hôtes virtuels qui ne sont pas le sujet du jour ; elle n’existait d’ailleurs pas en HTTP/1.0. Pour connecter un navigateur à un serveur sur un port qui n’est pas celui par défaut (80), il suffit de rajouter " :" puis le numéro du port après l’adresse IP ou le nom du serveur. Par exemple pour un serveur local écoutant sur le port 3456, il suffit d’écrire dans la barre de navigation de votre navigateur http://127.0.0.1:3456/.

  • Foire Aux Questions 3988
    2 décembre 2016 à 00h12min par Mehellou Abdelatif

    Bonjour,

    je voudrais savoir, pour trouver le type de fichier, est ce qu’on est obliger de parser le fichier mime.types ou on a le droit d’utiliser d’autre alternative ?

    Cordialement.

    • Foire Aux Questions 3991
      2 décembre 2016 à 08h29min par Saint James Emmanuel

      Les serveurs HTTP se servent de ce fichier, je ne vois pas quel avantage il y aurait à ne pas l’exploiter, à quoi pensez-vous ? Je signale l’existence en C des fonctions regexec etc qui permettent d’appliquer une expression rationnelle et donc de résoudre rapidement ce problème.

      • Foire Aux Questions 4027
        5 décembre 2016 à 16h28min

        Le répertoire de l’exécutable doit-il contenir le fichier mime.types ou doit-on le récupérer dans le répertoire etc du système ? (sachant que son emplacement change suivant les systèmes d’exploitation)

        • Le fichier mime_types 4029
          6 décembre 2016 à 07h54min par Saint James Emmanuel

          Vous pouvez le mettre dans le répertoire du serveur, bien que ça pose le problème de son obsolescence à terme.

  • Question 2 (exécutable ) 3985
    1er décembre 2016 à 23h59min par Lamoureux Aurelien

    Bonjour,
    Dans la seconde question vous proposez que le client puisse lancer un fichier exécutable sur le serveur.
    Es ce que celui ci doit écrire GET /nomDuFichier
    Ou plutôt EXEC /nomDuFichier
    Ou autre chose, car l’énoncer ne le précise pas

    Merci

    • Question 2 (exécutable ) 3990
      2 décembre 2016 à 08h23min par Saint James Emmanuel

      L’énoncé précise qu’une exécution est lancée si le fichier indiqué dans la requête est un fichier exécutable, autrement dit son chmod indique "x" pour le serveur. Il ne serait pas raisonnable que la spécification du protocole laisse au client la décision de savoir ce qui est exécutable et ce qui ne l’est pas sur le serveur.

      • Question 2 (exécutable ) 4236
        16 décembre 2016 à 12h46min

        En utilisant chmod, on sait déjà si le fichier existe ou non et si on a le droit d’accès au fichier, donc si on arrive au fork le code de retour à trois chiffres sera forcément 200 ou 500 non ? Dans ce cas là quel est l’intérêt que le fils renvoie le code de retour à trois chiffres au père ?

        • Question 2 (exécutable ) 4238
          16 décembre 2016 à 15h10min par Saint James Emmanuel

          Un exécutable qui s’exécute bien est libre d’envoyer le code de retour qu’il veut : il y a les 3xx qui indiquent des redirections, les 4xx qui indiquent que la requête ne peut être honorée (l’exécutable est accessible mais une de ses ressources non par exemple) etc. Le père étant chargé de mettre dans le journal le code de retour envoyé, il faut bien qu’il lui soit communiqué.

  • Coté client 3984
    1er décembre 2016 à 20h14min par Mehellou Abdelatif

    Bonjour,

    est ce qu’on doit fournir le code du client aussi ? si oui, est ce que c’est possible de faire plusieurs clients, chauqe’un pour tester un ou deux fonctionnalités

    Cordialement.

    • Coté client 3989
      2 décembre 2016 à 08h18min par Saint James Emmanuel

      Comme le précise l’énoncé, un navigateur usuel doit pouvoir se connecter à votre serveur HTTP, écrire un client est donc hors sujet : vous devez tester votre serveur avec votre navigateur habituel.

  • Standard 3968
    30 novembre 2016 à 20h10min par Dominguez Jose-Paul

    Peut on compiler en -std=c11 ?

    • Standard 3969
      30 novembre 2016 à 21h35min par Saint James Emmanuel

      Oui, du moment que vous fournissez une Makefile qui s’en occupe.

  • Soumission du projet 3964
    30 novembre 2016 à 18h13min

    Bonjour,

    l’authentification au site de PR ne fonctionne pas depuis chez nous, la réelle date limite de soumission est donc avant de partir en vacances ?

    Cordialement,

    • Soumission du projet 3971
      30 novembre 2016 à 21h38min par Saint James Emmanuel

      Les vacances se terminent le 3 au matin, la soumission est ouverte jusqu’au 4 à midi, votre question est donc hors sujet.

  • Travail en binôme obligatoire ? 3963
    30 novembre 2016 à 17h46min par Di Lisi Alexis

    Bonjour,
    ma question ne concerne pas le sujet du projet, mais est-il possible de réaliser ce travail seul ??
    Je ne suis pas sur Paris pour les vacances, et je ne souhaite pas pénalisé un éventuel binôme.

    • Travail en binôme obligatoire ? 3972
      30 novembre 2016 à 21h44min par Saint James Emmanuel

      Oui on peut faire le projet seul.

      • Travail en binôme obligatoire ? 3980
        1er décembre 2016 à 10h17min

        Dans ce cas, y a-t-il une démarche particulière à faire (vous prévenir à l’avance par exemple) ou pas ?

        • Travail en binôme obligatoire ? 3981
          1er décembre 2016 à 15h55min par Saint James Emmanuel

          Il suffit que ce soit indiqué clairement dans le rapport et son nom (i.e. un seul numéro dedans, cf. les directives de soumission).

  • Question 1 - Plusieurs messages du client ? 3960
    30 novembre 2016 à 17h10min

    Petite question à propos de la question 1. Le client envoie t-il les deux lignes de la requête une par une où tout d’un coup i.e le client fait-il :
    write(sock_serv, "GET/chemin HTTP/1.1", taille1) ;
    write(sock_serv, "Host : 127.0.0.1", taille2) ;
    write(sock_serv, "\n", 2) ;

    OU

    write(sock_serv, "GET/chemin HTTP/1.1 /n Host : 127.0.0.1 \n", taille3) ;

    Merci par avance de votre réponse.

    • Question 1 - Plusieurs messages du client ? 3973
      30 novembre 2016 à 21h48min par Saint James Emmanuel

      Quand l’énoncé dit que le client envoie deux lignes, cela veut dire qu’il y a un "\n" à la fin de chacune. Quant au serveur, il ne peut pas savoir par combien d’appels à Write l’envoi a été effectué, il ne voit que le résultat global.

      • Question 1 - Plusieurs messages du client ? 3977
        30 novembre 2016 à 22h00min par Dominguez Jose-Paul

        Attention, la RFC précise que c’est une séquence CRLF (’\r’ suivi de ’\n’) qui sépare les lignes même si ils conseillent d’être tolérant sur CR ou LF seul.

        • \n et \r 3978
          30 novembre 2016 à 22h53min par Saint James Emmanuel

          La question ne portant pas là-dessus, je ne suis pas entré dans ce détail, mais c’est exact.

  • Constitution des binômes 3958
    30 novembre 2016 à 16h01min

    Bonjour,

    peut-on composer un binôme avec 2 personnes de groupes de TD différents ?

    • Constitution des binômes 3974
      30 novembre 2016 à 21h49min par Saint James Emmanuel

      Oui, pas de problème.




8 Remise du projet Un serveur HTTP (20  point(s))

Vous devez déposer exclusivement une archive au format Zip, la commande unzip appliquée à l’archive devant fournir un répertoire où figurent tous les fichiers nécessaires à l’application, autrement dit tout ceux que vous avez créés plus ceux fournis dans l’énoncé, éventuellement modifiés.

Fichier à créer : \.zip$

Date limite: 4 janvier 2017 à 12h00min


Cliquer ici pour vous authentifier