sas 02 et HTTP
By Mihamina Rakotomandimby on Monday 12 December 2011, 16:37 - formation - Permalink
Dans le développement web, nous sommes en permanence confronté à HTTP.
HTTP avant tout
Avant de se lancer dans le développement web, il est absolument necessaire de se familiariser avec HTTP.
HTTP dans le sas de formation 02
J'ai donc demandé aux stagiaires du sas de formation 02 de s'auto documenter sur HTTP.
- Comment se sont passé les recherches sur HTTP?
- Quels mots clés ont apporté quelles réponses?
- A-t-il été facile de trouver l'information?
Comments
Il existe beaucoup de sites qui fournissent des informations sur le protocole http. Certains sont assez difficile à comprendre tandis que d'autres le sont moins. Quels que soit le site visité, les idées convergent sur les points suivants:
1) HTTP fonctionne sur le mécanisme de "requête/réponse"
2) Le HTTP 1.1 (aussi connu comme "RFC 2616") s'exécute en "pipeline".
3) Les réponses en provenance du serveur HTTP sont catégorisés dans les classes (1 - 5).
Une remarque que j'ai constaté c'est que, Le sujet portant sur le protocole HTTP est très vaste, et si on ne délimite pas les recherches, on risque de s'y perdre, mais aussi de n'aboutir à aucun résultat bien concret.
Comme toutes les recherches sur le web, l'internet nous donne beaucoup de résultat sur le HTTP. Ça nous aide facilement à enrichir nous connaissances. Mais à part, c'est difficile de choisir les informations à collecter car chaque page consultée a sa propre façon de décrire le HTTP (comme dans le RFC). Donc, il faut bien comparer et bien choisir les informations importantes à retenir.
Les recherches sur le protocole HTTP se sont passés bel et bien en permettant de savoir que lors d'un transfert de ressources, HTTP utilise le protocole TCP (Transfert Control Protocol) comme couche de transport. Ces ressources ne sont que des objets ou sources de données (page html,fichier audio,etc..) identifiés par l'URL(Uniform Resource Locator). Le mot clé très important à savoir est le RFC ou Request For Comments. Ce sont des séries de documents établis par des experts techniques décrivant les standardisations, normalisations d'Internet et utilisés pour définir le protocole HTTP . Heureusement, la quantité d'information concernant l'HTTP sur internet sont nombreuses; d'où, la recherche d'information n'a pas connu de difficultés majeures.
On a recherché quelques informations supplémentaires autres que dans la formation 02 à propos de HTTP et HTTPS. Et les recherches se passent dans quelques sites.
Le mot clé HTTPS nous a donné des informations sur la sécurisation des données, le cryptage nous a menés vers le cryptage symétrique et asymétrique.
La plus part des informations sont faciles à trouver.
Il est impératif pour tout développeur web d’assimiler le fonctionnement du protocole HTTP . C'est pour cela que la formation de ce jour met en exergue la recherche d'information sur ce protocole .Bien évidement , la recherche est fructueuse car je comprend maintenant ce qui se passe lorsqu'une page se charge dans le navigateur web . Mais encore , des mots qui avant ce jour ne figuraient pas dans mon dictionnaire personnel prennent sens . Prenons , un pragma qui permet aux équipement HTTP de ne pas mettre en cache des informations . Et même , ce groupe de mot :"mettre en cache " je sais désormais qu'il observe le flux entre le navigateur et le serveur les requêtes en enregistrant les réponses . De plus , la différence entre un client et un serveur HTTP ainsi qu'une requête et une réponse HTTP devient maintenant une évidence .
Sans tenir compte du wiki , en ce qui concerne la recherche , j'ai trouvé de l'aide avec un ami fidèle qui est Google qui m'a dirigé vers d'autres liens sources d'information , à savoir : wikipedia , developpez.com et comment ça ma marche .
l'initiative de notre formateur de laisser d'abord aux "sasseurs" de chercher les informations sur un thème avant de donner le cours est une brillante idée car çà éveille notre curiosité et notre soif de connaissance cachés en nous et d'autre part , ça nous permet de projeter un avant première de ce que c'est réellement HTTP avant le cours .
Les recherches sur le protocole http ce sont généralement bien passé grâce aux différentes documentations sur l'internet en entrant les mots clés nécessaires pour la recherche telle que le mot HTTPs, cryptage, qui nous a permis par exemple d’avoir des informations sur les méthodes de cryptages des données, et la raison pour laquelle on utilise le https, etc…
La recherche des informations a été rendu plus simple aussi car l'auteur de chaque document a sa propre explication sur chaque terme technique utilisé, ce qui a rendu les informations plus clairs
L'internet rend facile les recherches sur le protocole HTTP, Il répond toujours à nos besoins par des divers résultats et c'est à nous de voir la nécessité. La liaison entre le client et le serveur lors de l'envoi d'une requête par le navigateur ou de renvoi d'une réponse par le serveur devient compréhensible. En effet, ce liaison se fait directement ou via un mandataire PROXY. Nous avons divers informations à propos du protocole HTTP, mais l'essentiel est de retenir quelque une à savoir la différence entre un client et un serveur HTTP, et la nuance entre une requête et une réponse HTTP.
La recherche a été assez difficile parce qu'en surfant sur internet, on a abouti sur un grand nombre de pages. Certains contiennent des informations importantes, certains n'ont pas réussi à répondre à nos attentes.
Les sites qui me paraissait satisfaisant utilisait toujours les termes suivants:
- RFC (Request For Comment) : documents de référence auprès de la communauté internet et qui décrivent, spécifient, aident à la mise en œuvre, standardisent et débattent de la majorité des normes, standards, technologies et protocoles liés à Internet et aux réseaux en général. Selon le site http://abcdrfc.free.fr/
-HTTP : le protocole HTTP repose sur les normes du RFC 1945 (HTTP/0.9), RFC 2068 (HTTP/1.0), RFC 2616 (HTTP/1.1) selon www.ietf.org
- Format de réponse HTTP: les réponses HTTP suivent un ordre bien précis:<version><statut><commentaire statut>|
<entêtes>|<contenus>
C'est facile de trouver des informations mais le plus difficile était d'en synchroniser avec nos besoins. On en a recueilli plusieurs mais la tâche la plus ardue était de les résumer à cause de leurs importances.
Après la recherche que nous avons fait sur l'Internet à propos du HTTP, nous croyons maîtriser et bien compris tout. Mais après la formation dans le SAS, nous se rendrons compte que nous ignorons beaucoup des éléments importants à retenir et que nous ne connaissons que peut sur le HTTP. Ainsi, nous avons appris beaucoup de chose autre que le thème du jour, comme le proxy et les différents termes techniques. La formation dans le SAS est très importante pour nous, elle enrichie de jour en jour nos bagages de connaissances. A part, le partage de la nouvelle du jour est très intéressant, il nous cultive et il nous mettre au courant tout ce qui se passe dans le monde entier.
Après la recherche d'information sur HTTP d'hier , la journée d'aujourd'hui s'est basée à la mini soutenance sur ce thème . Pour notre part , on a expliqué ce que c'est un URL , comment il est composé . Ensuite ,on a dessiné et expliqué un schéma sur la communication entre le navigateur et le serveur ; après on expliqué les méthodes GET et POST . en dernier lieu , on a différencier une requête d'une réponse HTTP .Sur les autres groupes , j'ai assimilé le fonctionnement d'un proxy(reverse et forward) , son rôle , son avantage et inconvénient par rapport au programmeur
Les erreurs du jours :
-On dit un proxy au lieu de serveur proxy car il est à la fois un serveur et un client
-Un Hacker n'est nécessairement pas un pirate c'est un programmeur astucieuse
-Google et à la fois un client et un serveur . De plus , les formulaires de google sont des réponses et non des requêtes
la phrase du jours :"Un client demande et ne répond jamais , le serveur ne demande rien , il répond "
J'ai apprécié le fait que durant la réunion de l'après midi , on s'assoit comme on veut(sur la table) histoire d’être à l'aise . ça m'a enlevé le stress !!!!!!!!!!
En complément de ce que j'ai affirmé hier voici:
1 )Le lien entre un proxy et un http
Par définition un proxy est un serveur qui va agir à la place d'un autre
Un proxy peut être à la fois un client et un serveur:
De la machine cliente jusqu'au proxy, ce dernier prend le rôle de serveur et du proxy au serveur de destination le proxy prend le rôle de client
Dans les deux intervalles le protocole utilisé est toujours du http.
2) Les procédures effectués lors du chargement d'une page
Le chargement d'une page http suit un ordre bien précis
D'abord la saisie de l'url dont le format en général est :
HTTP://<host>:<port>/<path>?<query>#<fragment>
La résolution de nom, c'est à dire la transformation du hostname en IP (IP du serveur cible)
L'envoi de la requête (qui sont généralement Get ou Post)
L'envoi des paramètres.
Aujourd’hui, l’exposé se basait sur le cours de HTTP, qui est un protocole de communication entre un client et un serveur. Nous avons fait des recherches sur ce thème, mais elles ne sont pas du tout suffisantes, d’où d’autres recherches pour avoir plus de connaissances et de résultats comme par exemple PROXY. PROXY est un composant logiciel qui a pour rôle d’être à la place du client et du serveur. En effet, nous retenons les différences entre un Reverse PROXY et Forward PROXY. Donc, la formation concernant le HTTP apporte des diverses avantages pour améliorer le niveau de notre connaissance. Le partage de la nouvelle du jour nous permet de se mettre au courant en ce qui concerne le WEB et la programmation WEB.
Concernant le proxy,
Un proxy est un terme informatique qui désigne un composant logiciel ou matériel qui se place entre deux programmes informatiques ou matériels pour faciliter les échanges.
Il existe deux cas de proxy HTTP: le "Forward" et le "Reverse"
- "Forward proxy": les clients se connectent à un serveur en interne. Celui-ci relaye la requête client vers le serveur de destination. Ici, le serveur intermédiaire tient le rôle d'un proxy.
Le proxy, ici, du côté client est un serveur; de l'autre côté, il joue le rôle d'un client.
- "Reverse proxy": les clients accèdent à un contenue sur un serveur mais ce contenu n'est pas en réalité stocker sur celui-ci.
Ce serveur va alors agir comme un proxy vers les serveurs de destination.
le proxy, ici aussi, joue le double rôle: à la fois client et à la fois serveur.
Du client au proxy(serveur), on utilise le protocole HTTP.
c'est aussi le cas du proxy(client) au serveur de destination.
Suite aux différents exposés qui se sont succédés aujourd'hui, et suivis par le cours portant sur le thème HTTP, un proxy agit à la fois en client et en serveur, donc il ne faut plus dire "serveur proxy" à partir de maintenant. Par définition, un proxy est un composant logiciel installé sur un ordinateur et situé entre le client et le serveur. Il a pour rôle important de mise en cache des ressources. Il y a 2 types de proxy: reverse (placé en frontal du serveur web) et forward (placé entre un réseau privé et l'internet). Tous ces 2 types de proxy assurent un grand niveau de sécurité des données. Autre sujet aussi, la méthode GET demande toute l'information située dans un serveur dans toute son intégralité, contrairement à la méthode HEAD, elle ne fait que la demande de l'en-tête des données. Le port 80 utilisé par défaut dans HTTP est déjà défini par le RFC (Request For Comments). Autre point très important à savoir aussi est que lorsqu'un formulaire d'un site web s'affiche dans le navigateur, c'est toujours une réponse et c'est le navigateur qui fait par la suite les requêtes adéquates en fonction des ressources nécessaires. Le client demande et le serveur répond.
Bonjour,
Aujourd’hui, on a appris beaucoup de chose le sur le HTTPS essentiellement sur le cryptage symétrique et surtout sur l’asymétrique.
Sans oublier le fonctionnement de virtual hosts pour avoir plusieurs noms de domaine sur un seul serveur qui est très intéressant si on a plusieurs sites.
Enfin, un je viens de connaître qu’un cookie est envoyé par un serveur HTTP à un client HTTP et on peut utiliser plusieurs set-cookie.
Merci pour le cours.
Suite au cours de HTTP dispensé aujourd'hui, un API ou Application Programming Interface est une documentation sur des méthodes exposées en faisant une interaction avec d'autres applications. Par exemple, on n'est plus contraint d'ouvrir facebook mais on peut aussi l'utiliser en agissant sur son API. De plus, un API peut être utilisé par d'autres applications. Un point important aussi est que dans le protocole HTTPS, on fait tout d'abord le cryptage SSL (Secure Socket Layer) avant de faire toutes transactions HTTP sur le réseau.
Voici les étapes SSL: le client se connecte sur le serveur en utilisant le port 443, ensuite le serveur envoye un certificat au Certificate Autority (CA) que la société d'authentification doit valider par la suite. Ainsi, le client demande le CA. Le navigateur génère une clé de façon aléatoire (ROT13,ROT6,...) et l'envoye au serveur. Finalement, le client et le serveur peuvent se communiquer par la suite avec une clé symétrique.
Autre point très important à savoir aussi est que les cookies sont des informations installées par le navigateur et contenant des paramètres de l'utilisateur. Les cookies servent aussi pour le "tracking" de l'utilisateur et ont pour fonction d'être un identifiant de session. On peut avoir plusieurs "Set-Cookie" dans une en-tête de requête HTTP.
La suite de la formation concernant le HTTP et le HTTPS que nous avons suivis aujourd'hui est très intéressante. Jusqu'ici, nous avons acquis une bonne connaissance concernant les étapes que le navigateur et le serveur effectuent pendant la navigation comme le mode de sécurisation des informations grâce au protocole HTTPS et les grands rôles des en-tête HTTP/HTTPS. Et aussi, nous avons acquis un nouveau méthode pour héberger localement un site local grâce au Vitual Host. En plus, nous abordons déjà le cours sur le COOKIES qui est un des éléments non négligeables pour le développement d'un site web.
HTTP face à HTTPS:
Le hic avec le HTTP, c'est qu'il présente un grand risque pour tout les tâches qui nécessite un minimum de sécurité. Donc pour résoudre ce dilemme, on a eu recours au https (dont le "s" signifie sécurité).
Dans le concept de l' https on y a intégrer du cryptage.
Son fonctionnement se fait de la manière suivante:
1) le navigateur se connecte au serveur
2) Le serveur averti de la présence de ce dernier envoie sa clé public avec son certificate Authority (CA)
3) Le navigateur vérifie alors la validité du CA
4) Le navigateur génère une clé aléatoire qui sera par la suite utilisée pour coder les données http ( les requêtes y compris) mais cette clé sera aussi envoyé au serveur afin qu' un décodage de ses données puissent s'effectuer. Lors de la réponse du serveur, le serveur va coder sa réponse avant de l'envoyer au navigateur. Le navigateur, à son tour va décoder cette réponse. Et ainsi de suite
les lexiques à savoir:
API: Un API ou (Application Programming Interface) est une documentation sur des méthodes, qui sont exposées, et qui sont utilisées plus tard pour créer d'autres applications.
Cookies: les cookies sont des informations qui sont stockés par le navigateur et qui sont en général utilisés pour faire un tracking des utilisateurs.
Aujourd'hui , j'ai appris qu un nom de domaine correspond à une adresse IP unique . la recherche de cette adresse IP est définit par la résolution de nom . Compliquons un peu les choses , comment héberger plusieurs nom de domaine sur une même adresse IP ? En utilisant des Virtual Host .En outre , après avoir terminé HTTP , on a tout de suite attaqué le protocole HTTPS ,"S" c'est la seule différence entre ces deux protocoles syntaxiquement , mais ce "S" a beaucoup de valeur du point de vue informatique notamment dans le monde du web . En effet, "S" signifie sécurité et dans ce sens le protocole HTTPS garantie l'intégrité des données , l'authenticité et la confidentialité. Ce sont les maitres mots d'HTTPS . Pour ce faire , HTTPS dispose de 2 techniques : le cryptage symétrique qui consiste à chiffrer et à déchiffrer un message via une seule clé publique jouant le double rôle . Malheureusement , cette technique n'est pas fiable car qui dit publique dit sans confidentialité ni authenticité . Heureusement , ce problème est résolu par la technique de cryptage asymétrique qui consiste à utiliser une clé publique pour crypter et une clé privée pour décrypter . De plus , le rôle d'SSL dans la vérification de l'authenticité à partir d'un certificat d'authenticité délivré par des organismes dont dont la réputation n'est jamais mise en question apporte une garantie à HTTPS .
La phrase du jour : "Une réponse a un seul content-type provenant d'une requête "
Les mots du jour :
-API : Application Programing Interface : c'est une documentation sur des méthodes qui sont exposée
-Virtual Host : permet d'utiliser plusieurs Noms de Domaines sur une même adresse IP
-clé publique et clé privée , cryptage symétrique et asymétrique
-cookie : informations sur le navigateur stockées sur une mémoire (le disque de l'utilisateur , RAM , Flash)
HTTP et HTTPS:
HTTP met en risque les informations confidentiels circulant dans le réseau, car la sécurité est moindre.
Pour plus de sécurité sur les transferts de données, HTTPs offre une sureté fiable.
Pour se faire, il faut crypter (chiffrer) les informations avant de les envoyer sur le réseau; assurer que le client se dirige vers la bonne adresse, et c'est le protocole HTTPS qui gère tout ça.
Encoder et crypter sont les mêmes d’un point de vue générale mais de degré de sécurité différente:
"Encoder" c'est transformer l’information (données) vers un ensemble de mots, et qu'on peut le décoder.
Par contre, "crypter" c'est transformer et sécuriser l'information pour que personne tiers ne peut y accéder et impossible de savoir la clé utilisée par l'autre.
Il existe différents méthodes de cryptage comme le célèbre algorithme de RSA (Rivest, Shamir et Adleman) entre autre.
(Voir http://www.apprendre-en-ligne.net/c...)
HTTPS utilise ces algorithmes de chiffrement pour sécuriser les données échangées sur le réseau.
Le cryptage des données se fait avant la préparation de l'entête HTTP.
Le fonctionnement est le suivant:
- Lorsqu'un client se connecte via le port 443
- Le serveur envoie sa clé publique avec le CA (Certificate Authority) au client
- Le navigateur vérifie alors la validité du CA
- Si le CA est valide: il génère une clé aléatoire et l'envoyé au serveur pour que le serveur puisse décoder les données du client.
- Enfin les deux font l'échange en clé symétrique.
Les cookies:
Concernant les cookies, ce sont des informations à stoker par le navigateur et il les met où il veut.
Les cookies viennent du serveur à partir de la réponse HTTP.
Généralement, les cookies sont utilisés pour un tracking.
Voici la procédure de création d'un cookie:
- du navigateur au serveur: le navigateur envoie une requête HTTP pour obtenir une ressource
- du serveur au navigateur: le serveur répond à la requête en y ajoutant un champ "set-cookie" pour que le navigateur stocke les cookies qu'il a généré.
Le serveur peut envoyer plusieurs cookies dans une réponse HTTP.
- après le stockage des cookies, les requêtes HTTP envoyées par le navigateur contiennent tous un champ "Cookie". Il y a plusieurs valeurs de cookies dans le champ "Cookie" et ils sont séparés par un point-virgule (";").
Aujourd'hui, la formation portant le thème sur HTTP nous a apporté beaucoup plus de détail et nous retenons que HTTP reste pour les requêtes et les réponses. Sur HTTP, le navigateur peut se connecter au serveur en envoyant la requête composée de l’en-tête et du contenu. Et la réception de la réponse est de même composante à celui de la requête. C’est la réponse de la demande du client.
En d’autre terme, sur HTTPs, la lettre ‘’s’’ veut dire ‘’sécurité’’ qui est très importante, c’était la différence entre HTTP et HTTPs. En effet, HTTPs ajoute des échanges de cryptages avant le démarrage des opérations HTTP. On a appris des bonnes connaissances à propos des cryptages symétriques et asymétriques, création du domaine local en utilisant des Virtual Hosts et sur le Cookies.
Aujourd'hui, nous avons mis en pratique le HTTP. Nous apprenons à saisir manuellement une requête HTTP via MSDOS en utilisant Telnet comme client. Et aussi, nous avons acquises des nouvelles connaissances sur les en-têtes HTTP grâce à Fortuna.
En plus, nous avons aussi mis en pratique la manipulation des cookies des navigateurs comme Firefox.
Aujourd’hui, on a utilisé TELNET pour envoyer une requête GET vers les serveurs distants. Pour cela, on a saisi la commande : telnet <nom du l’hôte> < port> et on tape la commande : set localecho permettant de voir la commande qu’on tape et on saisi la requête.
Ensuite on a fait des pratiques sur le cookie. Sur le navigateur, les cookies sont stockés dans le répertoire suivant : outils/option/vie privée/supprimer les cookies récents.
On utilisé le logiciel Ccleaner.exe pour supprimer tous les cookies, les caches, les fichiers temporaires, etc.
Les fichiers cookies sont placés dans le répertoire : C:\Documents and Settings\tsilavina\Application Data\Mozilla\Firefox\Profiles\c5frofue.default.
Telnet ou Terminal Network est un protocole réseau utilisé sur tout réseau supportant le protocole TCP/IP.
Telnet est aussi une commande permettant de créer une session Telnet sur une machine distante configurée comme serveur.
Telnet fonctionne dans un environnement client/serveur.
Auparavant, c’est Unix qui a la disposition de la commande. Mais les autres Système d’exploitation l’adopte ensuite.
Méthode pour créer une session Telnet et d'envoyer une requête HTTP via Telnet (pour Windows):
En entrant dans la commande DOS de Windows, on saisie "telnet" suivi de l' "IP" du serveur de destination et du "port" utilisé pour la connexion.
Pour que l'on voit ce que l'on écrite après la connexion, on appuyez sur "Ctrl+$" pour accéder au terminal telnet.
Dans le terminal on écrit "set localecho" pour qu'on peut voir ce qu'on écrit puis valider deux fois pour revenir au terminal DOS de Windows.
Dans le terminal telnet, on peut tapez "help" pour avoir de l'aide.
Après on peut saisir tranquillement la requête HTTP qu'on veut, en laissant une ligne vide après la requête pour la méthode GET ou valider directement après avoir entré les valeurs pour POST.
Et on a la réponse HTTP envoyée par le serveur.
A propos des cookies:
D'après le TP d'aujourd'hui, on a pu localiser où Firefox a stocké ses cookies.
On a essayer de les partager pour voir l'importance des cookies.
On a constaté que les cookies stockent les informations personnelles (login, mot de passe, session) et ils sont valides même si on change de machine et qu'on les recopient à l'emplacement des cookies du même navigateur.
Suite aux travaux pratiques qu'on a dispensé aujourd'hui concernant HTTP et les cookies, on a pu envoyer des requêtes HTTP à un serveur (port 80) en utilisant TELNET (Terminal Network). Voici les démarches à suivre en utilisant la commande DOS: telnet hostname port; par exemple telnet www.google.fr 80, et puis ctrl-$, ensuite 'set localecho'. C'est après qu'on envoit la requête HTTP avec ses en-têtes: GET / HTTP/1.1, Host: www.google.fr, User-Agent: Telnet, Accept: text/html, etc... On a remarqué que, quand on utilise la version plus ancienne de HTTP (HTTP/0.9), le serveur n'a pas pu traiter les requêtes avec succès c'est à dire que la plupart des serveurs en fonction actuels utilisent HTTP/ 1.0 et HTTP/1.1.
Concernant les cookies, on a pu repérer les dossiers et les fichiers oû ils sont stockés par le navigateur. En effet, le mot de passe, le nom de l'utilisateur, les sessions sont tous stockés dans un fichier différent. Par exemple, en mozilla firefox, le mot de passe est stocké dans le fichier "signons.sqlite" et les sessions dans le fichier "formhistory.sqlite" . Pour cela, on a utilisé le logiciel CCLEANER pour tracker facilement tous ces cookies.
Aujourd'hui , la formation est basée sur la pratique . D'une part ,j'ai appris à utiliser Telnet (terminal network) qui est un protocole réseau utilisé sur tout réseau supportant le protocole TCP/IP . Il est aussi un User Agent , en effet le client HTTP n'est pas forcement un navigateur . Pour ce faire , on s'est connecté a l'hostname (ou son adresse IP) muni du port 80 en utilisant le code : telnet hostname 80 . Lorsqu'on est connecté , on exécute une requête avec la méthode GET pour demander une ressource . Enfin , le serveur envoi la réponse HTTP .
D'autre part, une autre partie du TP est consacrée à la manipulation des cookies . on repère la cookie qui stock l'identification de session d'un utilisateur (on a choisi Yves comme user et facebook comme hostname) , on a copié dans la répertoire consacrée au cookie dans notre PC ce dossier . On a lancé facebook , et à notre grand étonnement le compte de Yves est ouvert , on s'est identifié en tant qu ' Yves . Ca montre à quel point il faut manipuler avec précaution les cookies d’où la gestion de la propriété expire .
La phrase du jour : "Le client HTTP n'est pas forcement le navigateur , Telnet peut l’être aussi et bien d'autre" .
Les mots clée du jour :
-Telnet
-User-agent
-port 80
- set localecho
-GET
-Cookie
Aujourd’hui, j’ai appris à saisir manuellement Telnet en exécutant une requête avec la méthode GET. C’est à partir de cet envoi qu’on obtiendra une réponse du serveur. La réponse est affichée en bas juste après l’exécution des commandes ci-après : « telnet www.facebook.com», « set localecho», «GET /HTTP/ 1.1», « host : www.facebook.com », « User-Agent : telnet »,…
On a aussi débarrassé de cookies en utilisant le logiciel CCleaner pour analyser et nettoyer toutes les cookies existants. Après, on a trouvé l’emplacement exacte de cookies telles le mot de passe, le nom d’utilisateur, la session,…
Ces applications sont nouvelles pour moi, alors je suis très intéressée.
TELNET
TELNET ou TELecommunication NETwork est une application console supportant le protocole TCP/IP mais aussi une commande. Son utilité est qu'il permet d'établir une connexion TCP interactive avec d'autres services tels que: SMTP,HTTP, POP, IMAP ... . Sa pratique rend concrète toutes les théories faites sur le HTTP (surtout sur son mode de fonctionnement).
LE DANGER PROVOQUE PAR LES COOKIES:
Les cookies aident, c'est un fait. facilité dans la navigation, facilité dans les recherches et autres. Mais sous cet aspect, demeure aussi le danger. Tout simplement parce que les cookies son stockées quelques par sur la machine du client. Par conséquent il est possible de les récupérer et de les utiliser à des fins personnels, d'autant plus que le temps d'expiration d'un cookies peut durer des années.
Pour palier cela, les clients et les développeurs ont une tâches à accomplir:
Pour le client, il faut qu'il ait l'habitude de toujours se déconnecter dès qu'il en a fini avec sa session et de demander à ce que son mot de passe ne soit jamais retenu (surtout si la machine utilisé n'est pas le sien)
Et pour les développeurs, il faut, qu'ils raisonnent bien dans leurs établissement de date d'expiration pour les cookies, surtout pour les sites de e-commerce.
Aujourd'hui, le partage des nouvelles nous apporte une riche culture dans le monde du web. Chaque sasseur apporte sa nouvelle du jour et tout participera au débat concernant ce dernier. Ça nous ouvre l'esprit avant de commencer la formation.
La formation du jour concerne toujours le HTTP. Aujourd'hui, nous avons acquis le fonctionnement du CACHE, son utilité et son importance.
Comme suite du programme, nous attaquerons le HTML la semaine prochaine. Le formateur nous a demandé de ce documenter sur l'Internet pour que nous même puissions nous auto-former et de présenter nos recherches à la prochaine rencontre.
On a terminé en beauté le cours d'HTTP aujourd'hui. Un cache est aussi un proxy ou un mandataire se trouvant entre un ou plusieurs serveurs web et un ou plusieurs clients dans l'architecture réseau. Seules les ressources statiques sont mises en cache. Si les en-têtes de la réponse ordonnent le cache de ne pas stocker les ressources alors il ne le fait pas. Autre point important aussi est le mot "Etag" qui est une balise-entité HTTP utilisée pour la validation du cache. Quand un URL est envoyé au serveur, ce dernier envoie les ressources avec le Etag (par exemple:686897696a7c876b7e) correspondant situé dans l'entête de la réponse. Après, le client peut décider de ne pas mettre en cache les ressources avec l'Etag. Plus tard, lorsque le client envoye le même URL, il envoye une copie de l'Etag précédent avec la requête "If-None-Match". Le serveur compare les Etag, et si ça correspond le serveur envoit seulement "HTTP 304 Not Modified" sinon il va envoyer toutes les ressources.
Concernant les sessions HTTP qui permettent de réaliser des applications web au-dessus du protocole HTTP; par exemple, à la première visite d'une page, un serveur web demande au client de conserver un cookie de session, qui contient un simple identifiant. Lorsque l'utilisateur passe sur une autre page du site, le cookie est envoyé au serveur web en même temps que la requête HTTP : le serveur web peut alors retrouver la session d'un utilisateur grâce à l'identifiant stocké dans le cookie.
Contrôler le cache:
On peut contrôler le cache via les en-têtes HTTP par l’intermédiaire des balises <META> dans le <HEAD>, dans le document HTML ;
ETag ou étiquette d'entité est une partie du protocole HTTP.
Un ETag est un identifiant unique attribué par le serveur web pour une ressource. Les ETags sont un moyen utilisé pour prévenir à une ressource. Si le contenu d’une ressource change, alors le serveur génère une nouvelle Etag pour cette ressource. Ils peuvent être comparées afin de déterminer si deux versions de ressource sont les mêmes ou non.
Cela permet d'économiser la bande passante, parce que le serveur n'a pas besoin d'envoyer une réponse complète si le contenu n'a pas été changé.
La session HTTP:
Une session permet la suivie d’un utilisateur lors de sa navigation sur un site. Elle peut être maintenue pendant un temps assez long, même de plusieurs jours, afin d’identifier un « utilisateur » qui reviendrait sur un site. C’est l’un des utilisations des cookies.
Au-delà d'une certaine durée d'activité, une session HTTP expire, et toutes les informations qui y sont attachées expirent.
La gestion d'une session peut se faire de deux manières. La manière la plus simple est de créer un cookie de session, envoyé au client, qu'il retournera dans l'en-tête HTTP à chaque requête. La valeur de ce cookie est un code de hachage, qui identifie un internaute de façon unique. Charge ensuite au serveur de conserver trace de ces cookies, et de les associer aux bons utilisateurs.
les caches conservent:
- Les informations standards : l'ID de session, la date de création, la date de dernière utilisation ;
- Les informations propres à l'application attachées à la session à l'aide de clés. Ces clés sont des chaînes de caractères.
Aujourd'hui ,on a achevé le cours sur HTTP en partant des cookies et les sessions , leur utilité et leur principe , les avantages et les inconvénients . De plus , on a appris comment , pourquoi et quand faire une mise en cache . Actuellement , nous sommes en mesure d'affirmer que nous comprenons bien le principe et le fonctionnement de ce dernier puisqu'on comprend maintenant ce qui se passe qu'on une page se charge , comment se déroule la communication entre le client et le serveur et en d'autre termes que ce passe t il lors d'un mise en cache .
La deuxième partie de la journée est généralement consacrée à la recherche sur un tout nous nouveau thème à l'image d' HTML , un thème tout autant passionnant qu' HTTP . Certes , la documentation sur HTML nous donne qu un aperçu du cours mais elle a permis de lever des zones d'ombre à ce sujet et encore nous permettra d'assimiler le cours au moment venu .
Les nouvelles du jour ont enrichis ma connaissance dans le sens où je suis au courant de ce qui se trame autour de l'informatique en ce moment notamment du développement web . En dernier lieu mais non des moindres , mon dictionnaire personnel en informatique s'est élargie en ajoutant ces mots dans sa bases de connaissances .
- CRUD : Create Read Update Delete
- CEO : Chief Executive Office ou Directeur Président Général
-SSII : Société de Service de l' Ingénierie Informatique
-Tikiwiki : un puissant CMS pour Wiki
-E tag : une en tête d'identification codé en hexadécimal coté serveur
Bon Week-end
Bonjour,
Aujourd’hui, on utilisé les Entity Tags (ETags). Les ETags sont utilisés pour pouvoir différencier deux versions d'un même document. C'est un identifiant de la forme "65df7x89-cva-d612sd99", unique pour une URL, qui est transmis entre le navigateur et le serveur dans les requêtes HTTP.
L'intérêt de cet ETag est que le navigateur peut demander au serveur si un document a été modifié en envoyant une requête de ce type :
If-None-Match: "65df7x89-cva-d612sd99"
Si le document n'a pas été modifié, le serveur répond avec "304 Not Modified" et le navigateur utilisera son cache pour afficher le document. Autrement, le document est téléchargé à nouveau par le navigateur.
Pour désactiver les ETags sur Apache, ajoutez cette directive à votre fichier .htaccess ou, encore mieux, à votre fichier de configuration httpd.conf :
Header unset ETag
FileETag None
Le protocole non connecté signifie que chaque requête est traitée indépendamment des autres et qu'aucun historique des différentes requêtes n'est conservé. Ainsi le serveur web ne peut pas se "souvenir" de la requête précédente, ce qui est dommageable dans des utilisations telles que le e-commerce, pour lequel le serveur doit mémoriser les achats de l'utilisateur sur les différentes pages.
Un protocole réseau orienté connexion est un protocole qui livre un flux de données dans le même ordre qu'avec lequel il a été envoyé, après avoir d'abord établi une session de communication.
LE CONCEPT DE LA SESSION HTTP
Une qualité de service à la fois excellente et rapide, c'est la clé du succès paraît t'il. Cette théorie est très appliqué par l'homme. Mais il se trouve que cette même théorie peut aussi s'appliquer dans le domaine de la navigation internet.
En effet, il se trouve qu'un même client se connecte souvent sur un même site. Cela prendrait beaucoup de temps si, à chaque fois qu'un tel événement se produit, on refait l'étape 1 jusqu'à l'étape n du mécanisme (méchanisme du protocole HTTP).
D'où l'idée de créer une session http. Quel est alors son rôle?
Et bien tout simplement:
1) Attribuer une id de session à l'utilisateur
2) lors de sa prochaine navigation sur ce même site, il sera automatiquement identifié.
En bref, l'idée générale est de tracr sa navigation, pour optimiser qu'à sa prochaine venue, le temps de réponse soit considérablement réduit.
Aujourd'hui, pour la matinée, lors de la réunion, nous prendrons plus de temps à discuter des nouvelles comme d’habitude et tout le monde y participent. Ce partage des nouvelles nous offre plus de connaissances et de cultures Web.
Pour la formation, le cours sur HTTP s’est terminé aujourd’hui. D’abord l’utilisation des caches pour réduire le temps d’attente et le trafic des réseaux et ses fonctionnements. Ensuite, les sessions nous permettent de réaliser des applications web au dessus du protocole HTTP.
Pour cette après-midi, nous avons fait des recherches sur HTML pour préparer l’exposée de la semaine prochaine.
Bonjour,
Aujourd'hui, on a fini le cours HTTP en parlant du COOKIES,de la CACHE et de la session, on a parlé aussi de l'Etag, ou balise d'entité qui fait partie du protocole HTTP, on a parlé l'intérêt d'utiliser l'Etag qui est le fait de pouvoir demander au serveur si le document a été modifié ou pas en envoyant de requête au serveur, on a parlé de « if-None-match« et de « if -modified -Since« .
là on a vue également que le HTTP et un protocole non connecté parce que le serveur n'a pas de moyen d'identifier le client (sans compter les cookies bien sur)
Après , on a débuté le cours HTML en commençant par la documentation sur internet à ce sujet
HTML est un langage balisé et est structuré comme un arbre. Il est composé des éléments. Ces derniers sont composés de balises. Et les balises ont des attributs.Les balises doit en générale être ouvert(ex: <div>) et fermé (ex: </div>).mais il y en a quelques unes qui ne suivent pas ce règle.
Une page HTML est en générale comme suit:
- en premier lieu le DOCTYPE qui donne plus de détail sur le type de document pour prévenir en avance le navigateur aux données qu'il doit recevoir et traiter. Il permet aussi de gérer la rapidité de l'interprétation du contenu. Dans le DOCTYPE qu'on doit mentionné le type et la version de HTML utilisé dans tout le document. Il existe deux type: le STRICT qui est stricte comme son nom l'indique, si on utilise par exemple HTML 4.0, la syntaxe ne doit pas déborder du celle de HTML 4.0; et le TRANSITIONAL, qui prend en compte la syntaxe utlisé par celle qu'on a mentionné et celle de la version précédente. Par exemple, si on a mentionné qu'on utlise XHTML, on peut coder en XHTML+HTML 4.0. Et c'est là qu'on a rencontrer un petit clique. Si une fois dans le document, on utilise une ou des balises qui ne correspond pas aux syntaxes de celle qui a été mentionnée dans le DOCTYPE, le navigateur passe en mode QUIRKS, plus clairement, il passe en mode devinette c'est à dire il devine "de quelle type on a utilisé pour coder", et ça prend du temps.
- Une entête HEAD, très différent et à ne pas confondre à celle du HTTP(celle du HTTP est plus loin avant que celle du HTML), qui doit contenir obligatoirement du titre "TITLE". A partir de celui-ci que les moteur de recherche classe le nom du site dans sa page de solution pour les internautes.
- Le corps, situé entre les balises ouvrante et fermante respectivement <BODY> et </BODY> contenant le contenu de la page.
Un site doit être vu par les moteur de recherche. Il y a une technique que expert font pour cela et c'est le SEO.