Les bases pour comprendre le web - Episode 1
Les bases pour comprendre le web - Episode 2
Dans ces deux premiers articles, nous avons expliqué les bases d'Internet, dans ce troisième volet nous mettons le focus sur le Web.
C'est quoi le Web ?
Web c'est une abréviation de World Wide Web, toile mondiale en bon Français.
Alors World Wide, on l'a bien expliqué par la nature d'Internet qui est une interconnexion de réseaux locaux au niveau mondial.
Par contre que vient faire cette histoire de toile ?
En fait, on parle de toile car si on tirait un trait entre toutes les pages Web qui sont chaînées entre elles par des liens hypertextes, ça donnerait, en théorie du moins, quelque chose qui ressemble à une toile.
Au passage, vous savez maintenant pourquoi la plupart des sites internet sont préfixés par www (www.google.com, www.facebook.com etc.). www c'est juste l'acronyme pour world wide web ; et comme nous l'avons vu, c'est juste une habitude, on pourrait avoir monserveurhttp.google.com ou toto.google.com, si la fantaisie avait pris les gens de google de dénommer ainsi leur serveur http dans le système DNS.
Nous allons maintenant expliquer les technologies qui permettent l'existence du web.
Les technologies du web
HTTP : Hyper Text Transfer Protocol, un protocole trop simple !
Alors HTTP est un protocole qui permet pour l'essentiel à un client de télécharger (downloader) un fichier stocké sur un serveur (machine) distant qui exécute une logiciel serveur implémentant le protocole http (un serveur web donc).
Les fichiers en question peuvent être de n'importe quelle nature : texte ou binaires, fichiers de données ou programmes exécutables. Ce n'est pas le problème du serveur http. On lui demande des fichiers, il les donne. Ce qu'en fera le client, c'est le problème du client, chacun sa merde, non mais sans blague.
Pour obtenir un fichier, un client établit donc une connexion réseau via tcp/ip avec le serveur. Il faut voir cette connexion (socket dans la jargon informatique) comme un tuyau temporairement branché entre le client et le serveur.
Une fois le tuyau en place (la connexion réseau établie), le client exprime sa requête : il demande par le verbe "GET" une ressource dont il fournit une identification via une URL. Puis il signifie qu'il a fini de parler. On peut faire la parallèle avec une communications radio où une personne dît un truc du genre "terminé" ou "over" quand elle a fini de parler pour que l'autre en face puisse parler à son tour et répondre.
Le serveur comprend que GET veut dire "envoie moi ce fichier" (ben oui, c'est un serveur http, il parle donc le http couramment), il lit l'URL et en extrait la partie qui l'intéresse (le nom et le chemin du fichier), puis il regarde sur son disque dur si il a ça en boutique. Si tel est le cas, il répond au client par un code "200" qui veut dire "OK, j'ai ton machin je te l'envoie" puis il lit le fichier sur son disque et en écrit le contenu dans le tuyau qui le relie, puis a son tour signifie qu'il a fini de parler. Si il n'a pas le fichier demandé, il va répondre par un code d'erreur "404" qui veut dire "Fichier non trouvé" puis signaler qu'il a fini de parler. Il existe d'autres codes d'erreurs correspondant à différents cas d'erreurs possibles, citons l'inénarrable "500" qui veut dire "Erreur Interne du Serveur", en gros "y a une couille dans le potage".
Quand le client entend le "j'ai terminé" du serveur, la connexion réseau est fermée, le client et le serveur ne peuvent plus se parler (sauf à établir une nouvelle connexion et redémarrer à zéro, pour cette raison le protocole http est qualifié de stateless - sans état -).
A ce stade, le client dispose du fichier que le serveur lui a envoyé. Il doit maintenant décider quoi en faire.
HTTP : Hyper Text Transfer Protocol : une histoire de bits
Attention, tout mauvais esprit est interdit !
Comme nous venons de le voir, le client http (le navigateur le plus souvent) demande au serveur web (le serveur http) de lui envoyer un ficher et si tout se passe bien, il reçoit le fichier.
Et là désolé, je vais devoir employer quelques gros mots. En informatique, toutes les informations sont représentées sous forme d'une suite de 0 et de 1, ce qu'on appelle des chiffres binaires, en anglais binary digit, abrégé en bit.
Ces suites de 0 et de 1 sont combinées en paquets de 8 chiffres, et on appelle ces nombres des octets, bytes en anglais. Ne me demandez pas pourquoi des paquets de 8 et pas de 6 ou de 10, à priori il n'y a pas vraiment de raison hormis que ça dû sembler être une bonne idée à un ingénieur un jour quelque part.
Ce nombre de 8 bits permet d'exprimer 256 valeurs différentes soit 2 élevé à la puissance 8. Ce calcul est simple à comprendre, en faisant le parallèle avec le système décimal à 10 chiffres (de 0 à 9 donc) que nous utilisons tous sans même y faire attention : dans le système décimal (à base 10 d'où le "déci"), avec un chiffre, on peut exprimer 10 valeurs (0 à 9), avec 2 chiffres on peut exprimer 100 valeurs (0 à 99), avec 3 chiffres on peut exprimer 1000 valeurs (0 à 999) etc. Si on généralise, on voit que quel que soit le système (binaire et décimal par exemple), on peut exprimer un nombre de valeur égal à la base (2 pour le binaire, 10 pour le décimal) élevé à la puissance du nombre de chiffres utilisé (2 chiffres en décimal = 10 puissance 2 = 100 valeurs ; 8 chiffres en binaire = 2 puissance 8 = 256 valeurs).
Donc à ce stade, le navigateur a reçu un paquet de 0 et de 1, il les a assemblés en paquet de 8 et il se retrouve donc avec une série d'octets. C'est bien beau mais tout ça n'a encore aucun sens.
Pour que ça puisse en prendre un, il faut en fait interpréter cette série de chiffres selon une convention.
Par exemple, si la convention est que chaque octet représente une valeur numérique entière et positive, chaque octet exprimera une valeur entre 0 et 255 ; si à chaque valeur entre 0 et 255 on fait correspondre un caractère spécifique (lettre minuscule, lettre majuscule, chiffre, signe de ponctuation etc.), on est capable d'interpréter cette suite de 0 et de 1 comme du texte. Mais si on prend une autre convention cette suite de 0 et de 1 peut représenter le dernier tube de Nirvana (du son donc), la sextape de Paris Hilton (de la vidéo du coup), une suite d'instruction (un programme informatique), et en bref tout ce qu'on veut dès lors qu'on a établi une convention pour représenter une information sous forme binaire (ou sous forme de texte qui est lui même interprété selon une convention ...)
Bon super, on sait maintenant que dès qu'on sait quelle convention utiliser, cette suite de 0 et de 1 peut prendre un sens.
Mais ... comment le navigateur sait il quelle convention utiliser ? Ha ha ! Quelle suspense ...
Hé bien, ici encore pas de mystère, si la navigateur le sait, c'est tout simplement que le serveur le lui a dit. Quand ils se sont causés, le serveur avant de lui envoyer les données, lui a précisé la nature des informations. En fait le protocole qu'ils utilisent pour se parler prévoit que le serveur fournisse d'une certaine façon, convenue à l'avance et définie par le protocole, cette information (et d'autres, je vous épargne les détails). Pour les plus curieux, c'est un header (entête) de la réponse http qui s'appelle Content-Type qui contient une valeur exprimée selon une n-iéme norme qu'on appelle le type mime.
Par exemple "text/html" ça veut dire qu'il faut interpréter les 0 et 1 comme du texte, et plus précisément que ce texte est du code html. Autre exemple, "image/gif" ça veut dire que la suite de 0 et de 1 ce sont des données binaires qui représentent une image au format gif (et là, bien sur, le navigateur connait le format gif, faut de quoi il ne pourrait pas afficher l'image) etc.
Quand on vous dit que l'informatique c'est pas compliqué !
HTTP : Hyper Text Transfer Protocol : que faire des données ?
Donc le navigateur a reçu des données, et il en connait la nature. Et maintenant que va il en faire ?
Ben comme c'est un navigateur et que c'est sa principale raison d'exister, si il reçoit du HTML il va l'afficher (le langage HTML permet de décrire des pages, nous allons détailler ça plus loin). De la même façon, il y a un certain nombres de contenus liés à la gestion des pages web qu'il va savoir utiliser de la bonne façon (des images affichées dans la page par exemple)
Mais, il peut aussi recevoir des données qu'il ne sait pas traiter de base ; dans ce cas, il regarde si il dispose d'un plugin (parfois appelé greffon ou extension) qui étend ses fonctionnalités et qui sait traiter ce format ; si tel est le cas, il passe ça au plugin qui va par exemple afficher le contenu d'un fichier pdf (une facture, un bon de commande, un billet de train ...) ou jouer une vidéo. Nous détaillons ce mécanisme de plugin plus loin.
Et pour finir, il se peut que le navigateur ne sache pas quoi faire du fichier, et qu'il ne dispose d'aucun plugin adéquat. Dans ce cas, il va simplement vous afficher une boite de dialogue et vous proposer d'enregistrer le fichier, voire de l'afficher (mais dans ce dernier cas, il va l'interpréter comme du texte et comme ce n'en est pas, le résultat ne voudra rien dire, vous aurez un tas de caractères incohérents à l'écran). Le comportement ici peut varier un peu selon les navigateurs et leur configuration.
Bon vous devez maintenant comprendre pourquoi certains liens fonctionnent dans certaines navigateurs et pas dans d'autres (par exemple, un lien vers un fichier pdf fonctionnera sur un navigateur équipé d'un plugin qui lit le pdf, et ne fonctionnera pas sur un autre qui n'a pas ce plugin).
HTTP : Hyper Text Transfer Protocol : les autres verbes
Le protocole HTTP comprend quelques autres verbes que GET mais qui ne nous intéressent pas pour le moment, dans le cadre d'une utilisation basique du web, hormis un second : POST.
Si le verbe GET permet à un client de recevoir (lire) des données stockées sur un serveur distant (download), le verbe POST permet à l'inverse à un client d'envoyer (écrire) des données sur un serveur distant (upload) ; c'est donc l'opération inverse.
Le verbe POST permet donc d'uploader des fichiers du client vers le serveur, mais il permet également d'envoyer des données. Le cas d'utilisation le plus classique du verbe POST est l'envoi de données saisies via un formulaire sur un site web (et bien sur l'upload de fichiers).
Il existe une seconde façon pour un client d'envoyer des données au serveur, en conservant l'utilisation du verbe GET. Il ajoute simplement les données qu'il veut envoyer au bout de l'URL par exemple : http://www.toto.com?do=create&id=40. Si vous vous rappelez la description de la norme URL, ceci doit vous parler (sinon, relisez l'article précédent). En fait dans ce cas, le serveur reçoit deux données, une qui s'appelle "do" et qui a la valeur "create" et une autre qui s'appelle "id" et qui a la valeur "40". Si vous voyez des trucs du genre %C3%A8 c'est parce que certains caractères sont représentés d'une façon spéciale pour des raisons techniques que je vais vous épargner (histoire qu'on reste concentrés sur notre http plutôt que sur de sordides détails d'encodage de caractères non ascii - disons non américains pour prendre un raccourci assez exact - et de calcul hexadécimal...)
Vous devez vous demander ce que fait le serveur quand il reçoit des données de cette manière, ou par une requête POST ? Ou encore quand il reçoit un fichier ?
Hé bien, dans ce cas il ne fait rien par lui même. En effet, la seule chose qu'il sait faire c'est envoyer des données qu'on lui demande et réceptionner des données qu'on lui transmet (mais pas les traiter). Et dès lors qu'on lui envoie des données à traiter, il ne peut que faire appel à un autre programme qui, lui, sera écrit spécifiquement pour gérer ce cas de figure. Le recours à la programmation est donc indispensable ici (contrairement au simple traitement de requêtes d'envoi de fichier qui ne nécessitent que l'installation et la configuration du serveur web).
Ce programme peut être un module interne directement exécuté par le serveur web en son sein (un programme écrit selon certains règles précises pour pourvoir s'exécuter dans le même processus que le serveur http), ou le plus souvent (du moins pour l'informatique professionnelle) ce sera un programme externe avec lequel le serveur web via dialoguer, toujours dans notre fameux mode client/serveur.
Le serveur http va donc être à son tour un client, de ce programme, avec qui il va dialoguer : il va lui envoyer les données qu'il a lui même reçu et attendre une réponse du programme, réponse qu'il enverra ensuite à son propre client. Pour ce faire, le serveur web devra avoir été spécifiquement configuré afin d'être capable de parler au programme en question, via son propre protocole. Le programme en question pourra s'exécuter sur la même machine que le serveur web, il y aura alors une communication inter-processus, ou sur une machine distante, il y aura alors une seconde communication réseau.
Si je rajoute que le programme serveur appelé par le serveur web peut lui même faire appel à un ou plusieurs autres serveurs, qui à leur tour peuvent faire appel à d'autres serveurs etc., la notion d'informatique distribuée devrait vous apparaître plus clairement. Et maintenant, vous comprenez pourquoi vous n'avez parfois jamais de réponse quand vous cliquez sur un lien, ou que c'est très lent (détail important, quand vous cliquez sur un lien, votre navigateur envoie une requête http GET).
HTML/CSS and co
HTML (Hyper Text Markup Language) est un langage qui permet de décrire sous forme textuelle à la fois des données et la façon dont on veut présenter les données
Le langage a connu plusieurs versions et est normalisé par un organisme appelé le world wide web consortium et généralement désigné sous l’acronyme w3c. La version actuelle est la version 5 et elle apporte beaucoup de nouveautés et modernise fortement le langage.
Le HTML est un langage à base de balises. Une balise est une information non affichable qui est destinée à être interprétée par un interpréteur HTML et qui donne des informations sur l’utilisation à faire de la donnée. Exemples :
Une page HTML permet uniquement d'afficher des informations (en couple avec CSS), et c'est bien normal car c'était là la vocation initiale du web et la raison pour laquelle il a été inventé (par un chercheur en physique nucléaire qui voulait simplement partager ses travaux avec ses collègues un peu partout dans le monde).
Mais quand le web a commencé à être utilisé par le grand public, on a voulu en faire d'autres usages, et est vite apparu la nécessité de pouvoir embarquer un peu de code informatique dans les pages.
Ce code est nécessaire pour améliorer l'interaction avec l'utilisateur et avoir une meilleure ergonomie. Prenons un exemple tout bête. Vous remplissez un formulaire avec par exemple votre numéro IBAN, vous êtes susceptibles de vous tromper dans la saisie. Sans javascript, le seul moyen de vérifier que votre saisie est correcte, c'est d'envoyer une requête POST au serveur web, qui va la passer à un programme, qui va faire le contrôle et renvoyer une page HTML avec écrit en gros, gras et rouge "IBAN invalide" si vous vous êtes trompé. Tout ceci prend du temps car on a fait un aller/retour avec le serveur qui est peut être à l'autre bout de la planète, et que lui même a du faire un échange réseau avec le programme chargé de valider la saisie. A l'inverse, si on peut embarquer un bout de programme (du code informatique) directement dans la page, il sera possible de vérifier votre saisie avant tout échange avec le serveur ; ainsi en cas d'erreur vous le saurez tout de suite au lieu d'attendre 2 ou 3 secondes et on aura économisé de la bande passante, de la CPU serveur etc.
C'est un exemple basique mais il y a des tas d'autres cas d'usage tels que la modification dynamique d'un formulaire de saisie en fonction de votre saisie (par exemple si vous indiquez "sexe masculin", on va enlever le champ "nom de jeune fille").
Avec ce qu'on a appelé le web 2.0 (ce qui au passage ne veut pas dire grand chose, c'est juste un terme marketing qui ne fait référence à aucune norme), les applications web ont énormément gagné en souplesse d'utilisation et en fonctionnalités ; tout ceci est dû pour l'essentiel au progrès des navigateurs en matière d'exécution de code javascript, et surtout au progrès des outils utilisés par les développeurs.
Etant donné la vocation grand public d'Internet, le langage Javascript a été conçu pour être "simple" et accessible à des non professionnels. Pour ma part, je suis plus que critique sur ce choix car il en résulte un langage truffé de défauts ; quoi qu'il en soit ce n'est que mon avis et de toute façon, on n'a pas le choix car c'est aujourd'hui un standard incontournable. Fort heureusement, les outils professionnel dédiés au développement javascript (éditeurs, librairies, frameworks, surcouches syntaxiques diverses) ont permis de largement améliorer les choses (maintenabilité, productivité du développement, testabilité).
Maintenant vous devez comprendre pourquoi désactiver le support du javascript dans votre navigateur est la dernière chose à faire ...
Le navigateur
Le navigateur est à la croisée des chemins. C'est lui qui permet le fonctionnement du Web en combinant l’utilisation de HTTP, HTML (et sa balise <a>) et URL.
Un navigateur est un logiciel sophistiqué qui combine de nombreuses fonctions :
Plus de détail sur le navigateur
Le navigateur est donc un élément essentiel puisque sans lui le web n'existerait pas, il est à la croisée de tous les chemins. Du coup, ça vaut le coup de creuser un peu plus le sujet.
w3c
W3C, ou World Wide Web Consortium, est une organisation qui est en charge de rédiger les spécifications des normes qui permettent le fonctionnement du web, en particulier HTML, CSS, DOM (expliqué plus loin).
Les normes du w3c sont censées être respectées par les différents navigateurs.
Moteur de rendu HTML, DOM
Le moteur de rendu est un des composant majeurs du navigateur. Il est en charge d'interpréter le code HTML et d'afficher la page décrite par ce code.
Le traitement se passe en deux temps :
On voit donc que ce qui est affiché, ce n'est pas le HTML, mais l'interprétation qui en a été faite, à savoir un DOM. Ceci n'est pas un détail car c'est ce qui permet d'expliquer les techniques modernes popularisées par le web 2.0 ; ces techniques ont pour caractéristique (notamment) qu'elles permettent de mettre à jour ce qui est présenté à l'écran sans devoir recharger une nouvelle page, ce qui permet d'avoir des applications avec une ergonomie et une réactivité sans commune mesure avec ce qui existait à l'origine du web. En fait ces applications modifient directement le contenu du DOM (en javascript) et comme c'est le DOM qui est affiché, toute mise à jour du DOM entraîne une mise à jour de l'affichage.
Le moteur de rendu est un composant informatique qui existe indépendamment du navigateur et qui peut être utilisé dans d'autres contextes ; vous avez déjà remarqué sans doute qu'il n'y a pas que les navigateurs qui savent afficher du code HTML.Par exemple, un client de messagerie est capable d'afficher des mails au format HTML car il s'appuie, lui aussi, sur un composant "moteur de rendu html", parfois le même que le navigateur.
Il existe différents moteurs de rendu développés par différentes organisations, et ces moteurs s'améliorent continuellement. Tous les navigateurs n'utilisent pas le même moteur de rendu, ceci explique qu'une même page s'affichera différemment dans deux navigateurs différents, et que parfois deux navigateurs afficheront exactement la même chose (quand ils utilisent le même moteur de rendu).
Le navigateur Chrome utilise le moteur WebKit développé par Google (mais également les navigateurs Opera et Safari, et de nombreux navigateurs pour smartphones), le navigateur Firefox utilise le moteur Gecko développé par la fondation Mozilla, Internet Explorer a utilisé le moteur Trident (développé par Microsoft) jusque IE11 et utilise maintenant EdgeHTML avec son nouveau navigateur Edge (apparu avec Windows 10).
Les moteurs de rendu sont censés respecter de façon stricte les normes HTML, CSS et DOM. Le respect de ces normes est un critère important de qualité d'un moteur, avec sa vitesse d'affichage. Il existe des tests spécialisés qui permettent de vérifier la conformité d'un navigateur (en fait de son moteur de rendu HTML) à ces normes.
A ce jour, il est toujours très difficile pour les développeurs Web d'écrire des sites qui fonctionneront sur tous les navigateurs en raison des différences de comportement des différents moteurs ; ces différences sont dues soit à des interprétations différentes des normes w3c qui ne sont pas toujours assez précises, soit simplement à des bugs. Cependant, la situation s'est largement améliorée depuis 2 ou 3 ans et continue à s'améliorer.
Vous devez maintenant comprendre pourquoi quand un site ne fonctionne pas avec un navigateur, vous devez essayer avec un autre navigateur, et qu'il faut donc en avoir au moins deux ou trois sur votre PC.
Moteur d'exécution JavaScript
Le moteur d'exécution javascript est un autre composant informatique utilisé dans les navigateurs. Comme son nom l'indique, il est chargé d'exécuter les programmes javascript.
Le moteur d'exécution est un composant informatique qui existe indépendamment du navigateur et qui peut être utilisé dans d'autres contextes ; vous avez peut être déjà remarqué qu'il n'y a pas que les navigateurs qui savent exécuter du code javascript.
Il existe différents moteurs d'exécution développés par différentes organisations, et ces moteurs s'améliorent continuellement. Tous les navigateurs n'utilisent pas le même moteur, ceci explique qu'un même site fonctionnera différemment sur deux navigateurs (le plus souvent, il fonctionnera avec un moteur et ne fonctionnera pas avec un autre).
Le navigateur Chrome utilise le moteur V8 développé par Google, le navigateur Firefox utilise le moteur SpiderMonkey développé par la fondation Mozilla, Internet Explorer a utilisé le moteur Trident (développé par Microsoft) jusque IE8, puis Chakra depuis IE9.
Sans trop rentrer dans la technique, le langage javascript est un langage assez "rudimentaire" (il était destiné initialement à être aisé de prise en main par des non spécialistes) ce qui a diverses conséquences fâcheuses, et en particulier une nette propension à la lenteur et aux fuites mémoire : les programmes écrits en javascript sont plus lents que ceux écrits dans d'autres langages, et sont plus difficile à coder proprement pour ne pas gaspiller les ressources mémoire.
Fort heureusement, ces dernières années les interpréteurs javascript (moteurs d'exécution, c'est la même chose) ont fait des progrès spectaculaires (V8 de Google a lancé la danse, Microsoft a fait très fort avec la dernière version de Chakra utilisée dans Edge) ; et il était plus que temps car le web 2.0 fait un usage immodéré des technologies javascript pour offrir une ergonomie sophistiquée et modernes aux sites actuels, qui parfois n'ont plus grand chose à envier aux applications natives.
Les moteurs de rendu sont censés respecter de façon stricte la norme EcmaScript (en fait, javascript n'est qu'une implémentation de la norme EcmaScript ; il en existe d'autres mais c'est bel et bien javascript qui est employé aujourd'hui). Il existe des tests spécialisés qui permettent de vérifier la conformité d'un navigateur (en fait de son moteur js) à cette norme, ainsi que des tests de performance.
Vous devez maintenant comprendre pourquoi quand un site ne fonctionne pas avec un navigateur, vous devez essayer avec un autre navigateur, et qu'il faut donc en avoir au moins deux ou trois sur votre PC.
Plugins
Le terme plugin est assez générique en informatique, il désigne un logiciel facultatif qui vient compléter un logiciel principal et lui apporter des fonctionnalités supplémentaires. Le logiciel principal existe indépendamment de ses plugins dédiés et a été conçu pour être extensible par ce mécanisme de plugin. Le plugin quant à lui ne peux fonctionner dans un autre contexte que celui qui est fourni par le logiciel principal.
Les navigateurs sont donc conçus de façon a ce qu'on puisse y installer des plugins qui leur apportent des fonctionnalités supplémentaires, vous en utilisez tous les jours sans en avoir conscience :
Le support ou non de tel ou tel plugin par les navigateurs est important car il conditionne la capacité du navigateur à supporter certaines fonctions (lire un fichier pdf, diffuser une vidéo au format flash).
Le paysage en matière de plugins évolue fortement ces derniers temps, aussi nous faisons un focus sur ce point.
Flash vs HTML5 : Flash Player a été un standard de fait depuis très longtemps car c'était la principale solution qui permettait de diffuser de la vidéo dans les pages web, technique sans laquelle des sites comme youtube n'existeraient même pas. Cependant, ce produit ne répond à aucune spécification publique et officielle, le format est propriétaire (pas une norme w3c mais une technologie appartenant à une société privée). La situation a évolué avec la version 5 de la norme HTML qui standardise un format et des mécanismes de streaming vidéo ; une fois cette version largement implémentée par les navigateurs couramment utilisés (ce qui est le cas actuellement), la plupart des sites ont commencé à migrer vers ce nouveau format rendant Flash Player bien moins intéressant. Par ailleurs, Flash Player n'est pas supporté sur certaines smartphones (Iphone Apple, Windows Phone) pour diverses raisons (techniques ou politiques) et du coup Adobe (l'éditeur de Flash) a abandonné le support Android (système d'exploitation de très nombreux smartphones, à commencer par les Samsung). Le résultat de tout ceci est que cette technologie est en train de mourir et ne sera à terme plus supportée par les navigateurs.
Abandon du support NPAPI : Un autre changement important concerne l'abandon du support NPAPI par les principaux éditeurs de navigateurs (Microsoft depuis la sortie de Edge, Google pour Chrome depuis la mi 2015, et bientôt Mozilla pour Firefox). NPAPI était une interface de programmation datant de l'aube des navigateurs Internet (N vient de Netscape, l'ancêtre de tous les navigateurs). En gros, ça définit comment doit être écrit un plugin ; du coup tout plugin qui respecte ces règles peut s'exécuter dans tout navigateur qui supporte NPAPI, c'est à dire tous les navigateurs jusque il y a peu. Or, comme les éditeurs de navigateurs ont annoncé que leurs navigateurs ne supporteraient plus cette norme, tous les plugins écrits avec cette norme ne fonctionnent plus ou ne fonctionneront bientôt plus avec tous les principaux navigateurs. Les éditeurs de plugin ont toujours la possibilité de réécrire leurs plugins pour qu'ils supportent les nouvelles normes, mais il est peu probable que ça se fasse pour diverses raisons : déjà ça coûte cher et les plugins sont fournis gratuitement aux utilisateurs, ensuite il n'y a pas une API unique pour tous les navigateurs ce qui multiplie le nombre de développements à réaliser, certains navigateurs n'offrent même pas d'API pour plugin (Edge en particulier), et enfin les plugins indispensables (lecture pdf et flash dans une période intermédiaire) sont d'ores et déjà fournis directement par les éditeurs des navigateurs.
Le principal impact va donc être que tous les sites basés sur certains plugins largement utilisés à une période ne vont plus fonctionner et devront être réécrits... Si il ne sont pas réécrits, leurs utilisateurs n'auront d'autre alternative que d'utiliser d'anciens navigateurs (IE11 pour l'essentiel) qui supportent encore les vieux plugins. Or on ne peut rester longtemps avec un vieux navigateur sans problème, en particulier de sécurité. Les sites en question sont ceux qui font usage d'applets Java (composant développés dans la langage Java et exécuté par un moteur Java appelé par le navigateur), qui sont basés sur SilverLight (équivalent des Applets Java chez Microsoft), ou encore d'ActiveX (technologie Microsoft encore assez répandue). Les sites grands public font peu d'usage de ces technologies, par contre de nombreuses applications fournies par des éditeurs, ou applications en entreprise, sont encore basée sur ces technologies.
Par exemple, l'interface d'administration de mon antivirus AVG est développée en SilverLight, AVG va devoir réecrire entièrement son outil, et je devrais me mettre à jour. Un site de régie de transports de Reims qui calcule des itinéraires en bus est développé avec des Applets, il ne fonctionnera bientôt plus. Etc.
Pour le fun : avant que le couple infernal HTML5/javascript ne s'impose définitivement comme plateforme de développement pour les années à venir, il y a eu une période récente (disons il y a 3 ou 4 ans) où l'industrie hésitait à s'orienter vers une solution basée sur une généralisation de l'usage de plugins évolués permettant d'offrir des applications modernes et ergonomiques au sein du navigateur. Ceux qui ont fait ce choix doivent aujourd'hui le regretter amèrement, et pourtant ils n'ont rien à se reprocher car la situation était tout sauf lisible. A titre personnel, j'ai vu une grande banque Française devoir mettre à la poubelle des années/homme de développements et de R&D suite à l'abandon de Flex (une évolution de Flash Player pour faire simple) par Adobe qui a décidé brutalement de se recentrer sur HTML5.
Fonctions cryptographiques
Le protocole http est un protocole non crypté, et en outre particulièrement simple.
Conséquence, le premier ado boutonneux venu peut s'amuser à sniffer des trames réseau (écouter les informations qui circulent sur Internet, comme on peut espionner des communications téléphoniques) et récupérer toutes sortes d'informations. Les outils pour faire ça sont largement accessibles, et si on peut considérer que le hacking est un passe temps largement préférable à la drogue, aux tournantes et courses sauvage avec la voiture volée à papa, j'en connais certains qui ont eu la mauvaise surprise de voir débouler la gendarmerie chez eux pour une perquisition et la saisie de tous leurs ordinateurs.
Plus sérieusement, le développement du Web comme plateforme pour le commerce électronique était impossible tant qu'on ne pouvait pas garantir un minimum de sécurité. Ceux qui se sont fait pirater leur CB une fois voient de quoi je veux parler.
Alors, je ne vais pas entrer dans le détail, ce serait un peu long, mais disons simplement que les navigateurs modernes embarquent divers algorithmes sophistiqués et des bases de certificats de sécurité (émis par les organismes de certifications). Tout ceci permet de faire fonctionner le protocole HTTPS. Le "S" en plus c'est pour dire SECURE http, et cette sécurisation s'appuie sur un cryptage du protocole http par une technologie appelée SSL (Secure Socket Layer) ou TLS (nouveau nom de SSL).
L'intérêt est que ce cryptage intervient sur la couche transport et est donc totalement transparent pour le protocole http lui même (qui est sur la couche application). Bon, si vous ne comprenez pas cette phrase ce n'est pas grave. Ce qu'il faut retenir c'est que rien ne change, hormis un peu de configuration au niveau des serveurs et un peu de travail administratif (achat et déploiement de certificats SSL auprès de tiers de confiance, aka organismes certificateurs). Par contre, pour les utilisateurs, tout est identique : simplement un petit cadenas apparaîtra dans le navigateur et l'url démarrera par HTTPS au lieu de HTTP.
Le seul souci est que dans la course aux armements entre missile et blindage, il est nécessaire de faire évoluer régulièrement les algorithmes de cryptographie utilisés, et d'autres éléments, au fur et à mesure que la NSA et autres groupes mafieux (non je ne peux pas blairer les yankees) arrivent à casser les codes.
Du coup, il est parfois requis de changer de navigateur, les navigateurs trop anciens étant insuffisamment sécurisés. C'est comme si vous rouliez avec un char en blindage de 30 quand Daech dispose de missiles qui percent du 40 : il vous faut prendre un char en blindage de 50.
Si les choses sont stables depuis un bon moment et que ce problème ne concerne que ceux qui tournent avec de très vieux systèmes, il va cependant revenir sur le devant de la scène en 2016:2017 suite à l'abandon de SHA-1 au profit de SHA-2 (des chercheurs en mathématique ont démontré que l'algo SHA-1 utilisé depuis des années était dépassé et pouvait être cassé sans nécessiter des moyens techniques hors de portée des groupes mafieux, et Snowden a balancé le fait que la NSA a dépensé les milliards requis pour pouvoir casser les cryptages actuels).
J'ai prévu, quand j'aurais un peu de courage, un article pour vulgariser les notions de base en cryptographie (mais là j'ai pas le temps, j'ai déjà une série à finir sur le montage d'un NAS maison et c'est du boulot, et pleins d'autres idées).
Plus de détail sur le reste ...
Ascii ?
Bon, je développe cette histoire de ascii quand même.
Nous avons vu qu'on exprimait du texte en binaire en attribuant une valeur numérique décimale à chaque caractère et en exprimant cette valeur décimale en binaire.
Et la fameuse convention qui dit que la lettre "a" par exemple vaut la valeur 97 (01100001 en binaire), ben elle s'appelle Ascii (American Standard Code for Information Interchange, convention américaine pour l'échange d'information) et comme son nom l'indique elle est américaine ...
Or les américains, bien centrés sur leur nombril de yankee, ont juste oublié qu'ils n'étaient pas seuls au monde et que dans les pays civilisés (le reste du monde en gros, le premier qui dis que je n'aime pas les usa a gagné un bon point), on utilisait des caractères accentués (é è à â etc.. rien qu'en France, ajouter là-dessus les tildes espagnols, umlaut allemand et des tas d'autres trucs).
Du coup, quand on a voulu les traiter dans les systèmes informatiques initialement basés sur ce code Ascii ça a soulevé des tas de problèmes amusants avec lesquels on est encore en train de galérer 30 ans après (mais ça s'améliore grâce à une norme appelée Unicode qui prend en compte tous les caractères de tous les alphabets du monde).
Bref, je ferme cette parenthèse car il faudrait toute une série d'articles rien que pour expliquer tout ça en détail. Si vous ne comprenez pas, ne vous inquiétez pas, je connais des tas de gens avec des diplômes d'ingénieur en informatique et qui ne savent même pas ça :-(
Déjà, vous devez comprendre pourquoi les caractères accentués ne sont pas lisibles directement dans les URL (ils sont ré-encodés avec d'autres conventions), ou pourquoi il peut arriver que quand vous lisez des fichiers envoyés par un collègue étranger, certains caractères soient perdus et remplacés par d'autres.
Conclusion
C'est quoi le Web ?
Web c'est une abréviation de World Wide Web, toile mondiale en bon Français.
Par contre que vient faire cette histoire de toile ?
En fait, on parle de toile car si on tirait un trait entre toutes les pages Web qui sont chaînées entre elles par des liens hypertextes, ça donnerait, en théorie du moins, quelque chose qui ressemble à une toile.
Au passage, vous savez maintenant pourquoi la plupart des sites internet sont préfixés par www (www.google.com, www.facebook.com etc.). www c'est juste l'acronyme pour world wide web ; et comme nous l'avons vu, c'est juste une habitude, on pourrait avoir monserveurhttp.google.com ou toto.google.com, si la fantaisie avait pris les gens de google de dénommer ainsi leur serveur http dans le système DNS.
Nous allons maintenant expliquer les technologies qui permettent l'existence du web.
Les technologies du web
HTTP : Hyper Text Transfer Protocol, un protocole trop simple !
Alors HTTP est un protocole qui permet pour l'essentiel à un client de télécharger (downloader) un fichier stocké sur un serveur (machine) distant qui exécute une logiciel serveur implémentant le protocole http (un serveur web donc).
Les fichiers en question peuvent être de n'importe quelle nature : texte ou binaires, fichiers de données ou programmes exécutables. Ce n'est pas le problème du serveur http. On lui demande des fichiers, il les donne. Ce qu'en fera le client, c'est le problème du client, chacun sa merde, non mais sans blague.
Une fois le tuyau en place (la connexion réseau établie), le client exprime sa requête : il demande par le verbe "GET" une ressource dont il fournit une identification via une URL. Puis il signifie qu'il a fini de parler. On peut faire la parallèle avec une communications radio où une personne dît un truc du genre "terminé" ou "over" quand elle a fini de parler pour que l'autre en face puisse parler à son tour et répondre.
Le serveur comprend que GET veut dire "envoie moi ce fichier" (ben oui, c'est un serveur http, il parle donc le http couramment), il lit l'URL et en extrait la partie qui l'intéresse (le nom et le chemin du fichier), puis il regarde sur son disque dur si il a ça en boutique. Si tel est le cas, il répond au client par un code "200" qui veut dire "OK, j'ai ton machin je te l'envoie" puis il lit le fichier sur son disque et en écrit le contenu dans le tuyau qui le relie, puis a son tour signifie qu'il a fini de parler. Si il n'a pas le fichier demandé, il va répondre par un code d'erreur "404" qui veut dire "Fichier non trouvé" puis signaler qu'il a fini de parler. Il existe d'autres codes d'erreurs correspondant à différents cas d'erreurs possibles, citons l'inénarrable "500" qui veut dire "Erreur Interne du Serveur", en gros "y a une couille dans le potage".
Quand le client entend le "j'ai terminé" du serveur, la connexion réseau est fermée, le client et le serveur ne peuvent plus se parler (sauf à établir une nouvelle connexion et redémarrer à zéro, pour cette raison le protocole http est qualifié de stateless - sans état -).
A ce stade, le client dispose du fichier que le serveur lui a envoyé. Il doit maintenant décider quoi en faire.
HTTP : Hyper Text Transfer Protocol : une histoire de bits
Attention, tout mauvais esprit est interdit !
Comme nous venons de le voir, le client http (le navigateur le plus souvent) demande au serveur web (le serveur http) de lui envoyer un ficher et si tout se passe bien, il reçoit le fichier.
Ces suites de 0 et de 1 sont combinées en paquets de 8 chiffres, et on appelle ces nombres des octets, bytes en anglais. Ne me demandez pas pourquoi des paquets de 8 et pas de 6 ou de 10, à priori il n'y a pas vraiment de raison hormis que ça dû sembler être une bonne idée à un ingénieur un jour quelque part.
Ce nombre de 8 bits permet d'exprimer 256 valeurs différentes soit 2 élevé à la puissance 8. Ce calcul est simple à comprendre, en faisant le parallèle avec le système décimal à 10 chiffres (de 0 à 9 donc) que nous utilisons tous sans même y faire attention : dans le système décimal (à base 10 d'où le "déci"), avec un chiffre, on peut exprimer 10 valeurs (0 à 9), avec 2 chiffres on peut exprimer 100 valeurs (0 à 99), avec 3 chiffres on peut exprimer 1000 valeurs (0 à 999) etc. Si on généralise, on voit que quel que soit le système (binaire et décimal par exemple), on peut exprimer un nombre de valeur égal à la base (2 pour le binaire, 10 pour le décimal) élevé à la puissance du nombre de chiffres utilisé (2 chiffres en décimal = 10 puissance 2 = 100 valeurs ; 8 chiffres en binaire = 2 puissance 8 = 256 valeurs).
Pour que ça puisse en prendre un, il faut en fait interpréter cette série de chiffres selon une convention.
Par exemple, si la convention est que chaque octet représente une valeur numérique entière et positive, chaque octet exprimera une valeur entre 0 et 255 ; si à chaque valeur entre 0 et 255 on fait correspondre un caractère spécifique (lettre minuscule, lettre majuscule, chiffre, signe de ponctuation etc.), on est capable d'interpréter cette suite de 0 et de 1 comme du texte. Mais si on prend une autre convention cette suite de 0 et de 1 peut représenter le dernier tube de Nirvana (du son donc), la sextape de Paris Hilton (de la vidéo du coup), une suite d'instruction (un programme informatique), et en bref tout ce qu'on veut dès lors qu'on a établi une convention pour représenter une information sous forme binaire (ou sous forme de texte qui est lui même interprété selon une convention ...)
Bon super, on sait maintenant que dès qu'on sait quelle convention utiliser, cette suite de 0 et de 1 peut prendre un sens.
Mais ... comment le navigateur sait il quelle convention utiliser ? Ha ha ! Quelle suspense ...
Hé bien, ici encore pas de mystère, si la navigateur le sait, c'est tout simplement que le serveur le lui a dit. Quand ils se sont causés, le serveur avant de lui envoyer les données, lui a précisé la nature des informations. En fait le protocole qu'ils utilisent pour se parler prévoit que le serveur fournisse d'une certaine façon, convenue à l'avance et définie par le protocole, cette information (et d'autres, je vous épargne les détails). Pour les plus curieux, c'est un header (entête) de la réponse http qui s'appelle Content-Type qui contient une valeur exprimée selon une n-iéme norme qu'on appelle le type mime.
Par exemple "text/html" ça veut dire qu'il faut interpréter les 0 et 1 comme du texte, et plus précisément que ce texte est du code html. Autre exemple, "image/gif" ça veut dire que la suite de 0 et de 1 ce sont des données binaires qui représentent une image au format gif (et là, bien sur, le navigateur connait le format gif, faut de quoi il ne pourrait pas afficher l'image) etc.
Quand on vous dit que l'informatique c'est pas compliqué !
HTTP : Hyper Text Transfer Protocol : que faire des données ?
Donc le navigateur a reçu des données, et il en connait la nature. Et maintenant que va il en faire ?
Ben comme c'est un navigateur et que c'est sa principale raison d'exister, si il reçoit du HTML il va l'afficher (le langage HTML permet de décrire des pages, nous allons détailler ça plus loin). De la même façon, il y a un certain nombres de contenus liés à la gestion des pages web qu'il va savoir utiliser de la bonne façon (des images affichées dans la page par exemple)
Mais, il peut aussi recevoir des données qu'il ne sait pas traiter de base ; dans ce cas, il regarde si il dispose d'un plugin (parfois appelé greffon ou extension) qui étend ses fonctionnalités et qui sait traiter ce format ; si tel est le cas, il passe ça au plugin qui va par exemple afficher le contenu d'un fichier pdf (une facture, un bon de commande, un billet de train ...) ou jouer une vidéo. Nous détaillons ce mécanisme de plugin plus loin.
Et pour finir, il se peut que le navigateur ne sache pas quoi faire du fichier, et qu'il ne dispose d'aucun plugin adéquat. Dans ce cas, il va simplement vous afficher une boite de dialogue et vous proposer d'enregistrer le fichier, voire de l'afficher (mais dans ce dernier cas, il va l'interpréter comme du texte et comme ce n'en est pas, le résultat ne voudra rien dire, vous aurez un tas de caractères incohérents à l'écran). Le comportement ici peut varier un peu selon les navigateurs et leur configuration.
Bon vous devez maintenant comprendre pourquoi certains liens fonctionnent dans certaines navigateurs et pas dans d'autres (par exemple, un lien vers un fichier pdf fonctionnera sur un navigateur équipé d'un plugin qui lit le pdf, et ne fonctionnera pas sur un autre qui n'a pas ce plugin).
HTTP : Hyper Text Transfer Protocol : les autres verbes
Le protocole HTTP comprend quelques autres verbes que GET mais qui ne nous intéressent pas pour le moment, dans le cadre d'une utilisation basique du web, hormis un second : POST.
Le verbe POST permet donc d'uploader des fichiers du client vers le serveur, mais il permet également d'envoyer des données. Le cas d'utilisation le plus classique du verbe POST est l'envoi de données saisies via un formulaire sur un site web (et bien sur l'upload de fichiers).
Il existe une seconde façon pour un client d'envoyer des données au serveur, en conservant l'utilisation du verbe GET. Il ajoute simplement les données qu'il veut envoyer au bout de l'URL par exemple : http://www.toto.com?do=create&id=40. Si vous vous rappelez la description de la norme URL, ceci doit vous parler (sinon, relisez l'article précédent). En fait dans ce cas, le serveur reçoit deux données, une qui s'appelle "do" et qui a la valeur "create" et une autre qui s'appelle "id" et qui a la valeur "40". Si vous voyez des trucs du genre %C3%A8 c'est parce que certains caractères sont représentés d'une façon spéciale pour des raisons techniques que je vais vous épargner (histoire qu'on reste concentrés sur notre http plutôt que sur de sordides détails d'encodage de caractères non ascii - disons non américains pour prendre un raccourci assez exact - et de calcul hexadécimal...)
Vous devez vous demander ce que fait le serveur quand il reçoit des données de cette manière, ou par une requête POST ? Ou encore quand il reçoit un fichier ?
Hé bien, dans ce cas il ne fait rien par lui même. En effet, la seule chose qu'il sait faire c'est envoyer des données qu'on lui demande et réceptionner des données qu'on lui transmet (mais pas les traiter). Et dès lors qu'on lui envoie des données à traiter, il ne peut que faire appel à un autre programme qui, lui, sera écrit spécifiquement pour gérer ce cas de figure. Le recours à la programmation est donc indispensable ici (contrairement au simple traitement de requêtes d'envoi de fichier qui ne nécessitent que l'installation et la configuration du serveur web).
Ce programme peut être un module interne directement exécuté par le serveur web en son sein (un programme écrit selon certains règles précises pour pourvoir s'exécuter dans le même processus que le serveur http), ou le plus souvent (du moins pour l'informatique professionnelle) ce sera un programme externe avec lequel le serveur web via dialoguer, toujours dans notre fameux mode client/serveur.
Le serveur http va donc être à son tour un client, de ce programme, avec qui il va dialoguer : il va lui envoyer les données qu'il a lui même reçu et attendre une réponse du programme, réponse qu'il enverra ensuite à son propre client. Pour ce faire, le serveur web devra avoir été spécifiquement configuré afin d'être capable de parler au programme en question, via son propre protocole. Le programme en question pourra s'exécuter sur la même machine que le serveur web, il y aura alors une communication inter-processus, ou sur une machine distante, il y aura alors une seconde communication réseau.
Si je rajoute que le programme serveur appelé par le serveur web peut lui même faire appel à un ou plusieurs autres serveurs, qui à leur tour peuvent faire appel à d'autres serveurs etc., la notion d'informatique distribuée devrait vous apparaître plus clairement. Et maintenant, vous comprenez pourquoi vous n'avez parfois jamais de réponse quand vous cliquez sur un lien, ou que c'est très lent (détail important, quand vous cliquez sur un lien, votre navigateur envoie une requête http GET).
HTML/CSS and co
HTML (Hyper Text Markup Language) est un langage qui permet de décrire sous forme textuelle à la fois des données et la façon dont on veut présenter les données
Le langage a connu plusieurs versions et est normalisé par un organisme appelé le world wide web consortium et généralement désigné sous l’acronyme w3c. La version actuelle est la version 5 et elle apporte beaucoup de nouveautés et modernise fortement le langage.
Le HTML est un langage à base de balises. Une balise est une information non affichable qui est destinée à être interprétée par un interpréteur HTML et qui donne des informations sur l’utilisation à faire de la donnée. Exemples :
- <b>ce texte sera restitué en gras</b>. Les balises <b> et </b> indiquent que le texte compris entre elles devra être affiché en gras (gras = bold en anglais)
- <i>ce texte sera restitué en italique</i>
- <a href=http://www.amazon.com/livres/sf/1984.pdf>1984</a>. Ici les balises <a> et </a> indiquent que le texte « 1984 » devra être affiché et géré comme un lien hypertexte. Un lien hypertexte est un texte sur lequel on peut cliquer. Le fait de cliquer sur le lien provoque l’établissement d’une connexion avec le serveur mentionné dans l’URL spécifiée par le paramètre href en vue d’obtenir la ressource spécifiée par l’URL. Cette balise <a> justifie le « Hyper Text » de HTML et sous son aspect anodin explique la notion même de WEB.
Une page HTML comprend deux parties, un entête (Head) qui contient des informations de nature techniques destinées au navigateur (et qui ne seront pas affichées), et un corps (Body) qui contient les informations et la description de leur mise en page.
Une page HTML mélange joyeusement des informations "pures" (données) destinées à être affichées et des informations de mise en page (balises html) destinées à être interprétées par le navigateur. Ceci rend l'écriture et surtout la maintenance des pages très complexes. Pour cette raison, le w3c a élaboré dans un second temps une norme complémentaire qui permet d'écrire des règles de mise en page dans des feuilles de style appelées CSS. Ainsi, le document HTML au lieu de décrire toutes les informations de mise en page, référence simplement les styles décrits dans une feuille associée à la page (via une balise dédiée située dans la partie HEAD). Le document HTML est ainsi plus lisible, les styles peuvent être mutualisés (réutilisés) sur plusieurs pages, et c'est bien plus maintenable (en modifiant la définition du style a un seul endroit, dans la feuille de style, on impacte automatiquement toutes les pages qui utilisent ce style).
Le Javascript
Une page HTML permet uniquement d'afficher des informations (en couple avec CSS), et c'est bien normal car c'était là la vocation initiale du web et la raison pour laquelle il a été inventé (par un chercheur en physique nucléaire qui voulait simplement partager ses travaux avec ses collègues un peu partout dans le monde).
Mais quand le web a commencé à être utilisé par le grand public, on a voulu en faire d'autres usages, et est vite apparu la nécessité de pouvoir embarquer un peu de code informatique dans les pages.
Ce code est nécessaire pour améliorer l'interaction avec l'utilisateur et avoir une meilleure ergonomie. Prenons un exemple tout bête. Vous remplissez un formulaire avec par exemple votre numéro IBAN, vous êtes susceptibles de vous tromper dans la saisie. Sans javascript, le seul moyen de vérifier que votre saisie est correcte, c'est d'envoyer une requête POST au serveur web, qui va la passer à un programme, qui va faire le contrôle et renvoyer une page HTML avec écrit en gros, gras et rouge "IBAN invalide" si vous vous êtes trompé. Tout ceci prend du temps car on a fait un aller/retour avec le serveur qui est peut être à l'autre bout de la planète, et que lui même a du faire un échange réseau avec le programme chargé de valider la saisie. A l'inverse, si on peut embarquer un bout de programme (du code informatique) directement dans la page, il sera possible de vérifier votre saisie avant tout échange avec le serveur ; ainsi en cas d'erreur vous le saurez tout de suite au lieu d'attendre 2 ou 3 secondes et on aura économisé de la bande passante, de la CPU serveur etc.
C'est un exemple basique mais il y a des tas d'autres cas d'usage tels que la modification dynamique d'un formulaire de saisie en fonction de votre saisie (par exemple si vous indiquez "sexe masculin", on va enlever le champ "nom de jeune fille").
Avec ce qu'on a appelé le web 2.0 (ce qui au passage ne veut pas dire grand chose, c'est juste un terme marketing qui ne fait référence à aucune norme), les applications web ont énormément gagné en souplesse d'utilisation et en fonctionnalités ; tout ceci est dû pour l'essentiel au progrès des navigateurs en matière d'exécution de code javascript, et surtout au progrès des outils utilisés par les développeurs.
Etant donné la vocation grand public d'Internet, le langage Javascript a été conçu pour être "simple" et accessible à des non professionnels. Pour ma part, je suis plus que critique sur ce choix car il en résulte un langage truffé de défauts ; quoi qu'il en soit ce n'est que mon avis et de toute façon, on n'a pas le choix car c'est aujourd'hui un standard incontournable. Fort heureusement, les outils professionnel dédiés au développement javascript (éditeurs, librairies, frameworks, surcouches syntaxiques diverses) ont permis de largement améliorer les choses (maintenabilité, productivité du développement, testabilité).
Maintenant vous devez comprendre pourquoi désactiver le support du javascript dans votre navigateur est la dernière chose à faire ...
Le navigateur
Le navigateur est à la croisée des chemins. C'est lui qui permet le fonctionnement du Web en combinant l’utilisation de HTTP, HTML (et sa balise <a>) et URL.
Un navigateur est un logiciel sophistiqué qui combine de nombreuses fonctions :
- Le navigateur est un client HTTP. Il sait établir une connexion réseau (socket) avec un serveur HTTP (serveur web) et dialoguer avec lui. Il demande des fichiers et quand il les obtient il en fait l’usage qui convient ou éventuellement relaie un message d’erreur renvoyé par le serveur HTTP
- Le navigateur est un interpréteur HTML. Il est capable de comprendre les balises contenues dans les fichiers HTML renvoyés par le serveur HTTP et d’afficher la page HTML. C’est lui qui fait qu’un texte encadré par les balises <b> et </b> sera affiché en gras. C’est lui qui gère le fait de déclencher une requête http quand on clique sur un lien hypertexte (verbe GET du protocole HTTP). Bien sur, il comprend également le CSS
- Le navigateur gère des formulaires de saisie (balise HTML <form>) et la transmission dans la requête http des données saisie (verbe POST du protocole HTTP)
- Le navigateur est un interpréteur JavaScript. Il comprend et exécute les programmes javascript inclus dans une page (directement ou indirectement via une balise html), voire si tel est le cas les programmes javascript qu'il a téléchargé directement (sans passer par une page html)
- Le navigateur est capable d’afficher les images embarquées dans les pages par la balise <img> dans différents formats, de gérer un cache local des pages HTML pour éviter des appels au serveur (source de nombreux problèmes), de gérer un historique de navigation (source de nombreux problèmes), de lire directement des flux audio et vidéo (HTML 5), d'exécuter des plugins qui étendent ses fonctionnalités, et plein d'autres choses encore
L'image ci-après illustre son fonctionnement basique.
.
L'image ci-après illustre le fonctionnement quand il appelle un serveur web qui lui même appelle un programme pour traiter des données qui ont été envoyées.
Dans cet exemple, le programme dialogue avec une base de données (SBGDR = base de données). C'est le cas le plus fréquent (par exemple pour afficher la liste de produits dans un catalogue).
Plus de détail sur le navigateur
Le navigateur est donc un élément essentiel puisque sans lui le web n'existerait pas, il est à la croisée de tous les chemins. Du coup, ça vaut le coup de creuser un peu plus le sujet.
w3c
W3C, ou World Wide Web Consortium, est une organisation qui est en charge de rédiger les spécifications des normes qui permettent le fonctionnement du web, en particulier HTML, CSS, DOM (expliqué plus loin).
Les normes du w3c sont censées être respectées par les différents navigateurs.
Moteur de rendu HTML, DOM
Le moteur de rendu est un des composant majeurs du navigateur. Il est en charge d'interpréter le code HTML et d'afficher la page décrite par ce code.
Le traitement se passe en deux temps :
- analyse de la page HTML et élaboration d'une représentation mémoire sous forme d'un graphe d'objet (un objet est la description d'un élément de la page, comme un texte ou un lien), selon la norme DOM (Document Object Model).
- affichage du contenu du DOM (donc affichage de la page)
On voit donc que ce qui est affiché, ce n'est pas le HTML, mais l'interprétation qui en a été faite, à savoir un DOM. Ceci n'est pas un détail car c'est ce qui permet d'expliquer les techniques modernes popularisées par le web 2.0 ; ces techniques ont pour caractéristique (notamment) qu'elles permettent de mettre à jour ce qui est présenté à l'écran sans devoir recharger une nouvelle page, ce qui permet d'avoir des applications avec une ergonomie et une réactivité sans commune mesure avec ce qui existait à l'origine du web. En fait ces applications modifient directement le contenu du DOM (en javascript) et comme c'est le DOM qui est affiché, toute mise à jour du DOM entraîne une mise à jour de l'affichage.
Le moteur de rendu est un composant informatique qui existe indépendamment du navigateur et qui peut être utilisé dans d'autres contextes ; vous avez déjà remarqué sans doute qu'il n'y a pas que les navigateurs qui savent afficher du code HTML.Par exemple, un client de messagerie est capable d'afficher des mails au format HTML car il s'appuie, lui aussi, sur un composant "moteur de rendu html", parfois le même que le navigateur.
Il existe différents moteurs de rendu développés par différentes organisations, et ces moteurs s'améliorent continuellement. Tous les navigateurs n'utilisent pas le même moteur de rendu, ceci explique qu'une même page s'affichera différemment dans deux navigateurs différents, et que parfois deux navigateurs afficheront exactement la même chose (quand ils utilisent le même moteur de rendu).
Le navigateur Chrome utilise le moteur WebKit développé par Google (mais également les navigateurs Opera et Safari, et de nombreux navigateurs pour smartphones), le navigateur Firefox utilise le moteur Gecko développé par la fondation Mozilla, Internet Explorer a utilisé le moteur Trident (développé par Microsoft) jusque IE11 et utilise maintenant EdgeHTML avec son nouveau navigateur Edge (apparu avec Windows 10).
Les moteurs de rendu sont censés respecter de façon stricte les normes HTML, CSS et DOM. Le respect de ces normes est un critère important de qualité d'un moteur, avec sa vitesse d'affichage. Il existe des tests spécialisés qui permettent de vérifier la conformité d'un navigateur (en fait de son moteur de rendu HTML) à ces normes.
A ce jour, il est toujours très difficile pour les développeurs Web d'écrire des sites qui fonctionneront sur tous les navigateurs en raison des différences de comportement des différents moteurs ; ces différences sont dues soit à des interprétations différentes des normes w3c qui ne sont pas toujours assez précises, soit simplement à des bugs. Cependant, la situation s'est largement améliorée depuis 2 ou 3 ans et continue à s'améliorer.
Vous devez maintenant comprendre pourquoi quand un site ne fonctionne pas avec un navigateur, vous devez essayer avec un autre navigateur, et qu'il faut donc en avoir au moins deux ou trois sur votre PC.
Moteur d'exécution JavaScript
Le moteur d'exécution javascript est un autre composant informatique utilisé dans les navigateurs. Comme son nom l'indique, il est chargé d'exécuter les programmes javascript.
Le moteur d'exécution est un composant informatique qui existe indépendamment du navigateur et qui peut être utilisé dans d'autres contextes ; vous avez peut être déjà remarqué qu'il n'y a pas que les navigateurs qui savent exécuter du code javascript.
Il existe différents moteurs d'exécution développés par différentes organisations, et ces moteurs s'améliorent continuellement. Tous les navigateurs n'utilisent pas le même moteur, ceci explique qu'un même site fonctionnera différemment sur deux navigateurs (le plus souvent, il fonctionnera avec un moteur et ne fonctionnera pas avec un autre).
Le navigateur Chrome utilise le moteur V8 développé par Google, le navigateur Firefox utilise le moteur SpiderMonkey développé par la fondation Mozilla, Internet Explorer a utilisé le moteur Trident (développé par Microsoft) jusque IE8, puis Chakra depuis IE9.
Sans trop rentrer dans la technique, le langage javascript est un langage assez "rudimentaire" (il était destiné initialement à être aisé de prise en main par des non spécialistes) ce qui a diverses conséquences fâcheuses, et en particulier une nette propension à la lenteur et aux fuites mémoire : les programmes écrits en javascript sont plus lents que ceux écrits dans d'autres langages, et sont plus difficile à coder proprement pour ne pas gaspiller les ressources mémoire.
Fort heureusement, ces dernières années les interpréteurs javascript (moteurs d'exécution, c'est la même chose) ont fait des progrès spectaculaires (V8 de Google a lancé la danse, Microsoft a fait très fort avec la dernière version de Chakra utilisée dans Edge) ; et il était plus que temps car le web 2.0 fait un usage immodéré des technologies javascript pour offrir une ergonomie sophistiquée et modernes aux sites actuels, qui parfois n'ont plus grand chose à envier aux applications natives.
Les moteurs de rendu sont censés respecter de façon stricte la norme EcmaScript (en fait, javascript n'est qu'une implémentation de la norme EcmaScript ; il en existe d'autres mais c'est bel et bien javascript qui est employé aujourd'hui). Il existe des tests spécialisés qui permettent de vérifier la conformité d'un navigateur (en fait de son moteur js) à cette norme, ainsi que des tests de performance.
Vous devez maintenant comprendre pourquoi quand un site ne fonctionne pas avec un navigateur, vous devez essayer avec un autre navigateur, et qu'il faut donc en avoir au moins deux ou trois sur votre PC.
Plugins
Le terme plugin est assez générique en informatique, il désigne un logiciel facultatif qui vient compléter un logiciel principal et lui apporter des fonctionnalités supplémentaires. Le logiciel principal existe indépendamment de ses plugins dédiés et a été conçu pour être extensible par ce mécanisme de plugin. Le plugin quant à lui ne peux fonctionner dans un autre contexte que celui qui est fourni par le logiciel principal.
Les navigateurs sont donc conçus de façon a ce qu'on puisse y installer des plugins qui leur apportent des fonctionnalités supplémentaires, vous en utilisez tous les jours sans en avoir conscience :
- le plugin "lecteur pdf", souvent Acrobat Reader, permet de lire directement dans le navigateur des fichiers au format pdf
- le plugin Flash Player permet de lire des vidéos au format Flash directement dans le navigateur
Le support ou non de tel ou tel plugin par les navigateurs est important car il conditionne la capacité du navigateur à supporter certaines fonctions (lire un fichier pdf, diffuser une vidéo au format flash).
Le paysage en matière de plugins évolue fortement ces derniers temps, aussi nous faisons un focus sur ce point.
Flash vs HTML5 : Flash Player a été un standard de fait depuis très longtemps car c'était la principale solution qui permettait de diffuser de la vidéo dans les pages web, technique sans laquelle des sites comme youtube n'existeraient même pas. Cependant, ce produit ne répond à aucune spécification publique et officielle, le format est propriétaire (pas une norme w3c mais une technologie appartenant à une société privée). La situation a évolué avec la version 5 de la norme HTML qui standardise un format et des mécanismes de streaming vidéo ; une fois cette version largement implémentée par les navigateurs couramment utilisés (ce qui est le cas actuellement), la plupart des sites ont commencé à migrer vers ce nouveau format rendant Flash Player bien moins intéressant. Par ailleurs, Flash Player n'est pas supporté sur certaines smartphones (Iphone Apple, Windows Phone) pour diverses raisons (techniques ou politiques) et du coup Adobe (l'éditeur de Flash) a abandonné le support Android (système d'exploitation de très nombreux smartphones, à commencer par les Samsung). Le résultat de tout ceci est que cette technologie est en train de mourir et ne sera à terme plus supportée par les navigateurs.
Abandon du support NPAPI : Un autre changement important concerne l'abandon du support NPAPI par les principaux éditeurs de navigateurs (Microsoft depuis la sortie de Edge, Google pour Chrome depuis la mi 2015, et bientôt Mozilla pour Firefox). NPAPI était une interface de programmation datant de l'aube des navigateurs Internet (N vient de Netscape, l'ancêtre de tous les navigateurs). En gros, ça définit comment doit être écrit un plugin ; du coup tout plugin qui respecte ces règles peut s'exécuter dans tout navigateur qui supporte NPAPI, c'est à dire tous les navigateurs jusque il y a peu. Or, comme les éditeurs de navigateurs ont annoncé que leurs navigateurs ne supporteraient plus cette norme, tous les plugins écrits avec cette norme ne fonctionnent plus ou ne fonctionneront bientôt plus avec tous les principaux navigateurs. Les éditeurs de plugin ont toujours la possibilité de réécrire leurs plugins pour qu'ils supportent les nouvelles normes, mais il est peu probable que ça se fasse pour diverses raisons : déjà ça coûte cher et les plugins sont fournis gratuitement aux utilisateurs, ensuite il n'y a pas une API unique pour tous les navigateurs ce qui multiplie le nombre de développements à réaliser, certains navigateurs n'offrent même pas d'API pour plugin (Edge en particulier), et enfin les plugins indispensables (lecture pdf et flash dans une période intermédiaire) sont d'ores et déjà fournis directement par les éditeurs des navigateurs.
Le principal impact va donc être que tous les sites basés sur certains plugins largement utilisés à une période ne vont plus fonctionner et devront être réécrits... Si il ne sont pas réécrits, leurs utilisateurs n'auront d'autre alternative que d'utiliser d'anciens navigateurs (IE11 pour l'essentiel) qui supportent encore les vieux plugins. Or on ne peut rester longtemps avec un vieux navigateur sans problème, en particulier de sécurité. Les sites en question sont ceux qui font usage d'applets Java (composant développés dans la langage Java et exécuté par un moteur Java appelé par le navigateur), qui sont basés sur SilverLight (équivalent des Applets Java chez Microsoft), ou encore d'ActiveX (technologie Microsoft encore assez répandue). Les sites grands public font peu d'usage de ces technologies, par contre de nombreuses applications fournies par des éditeurs, ou applications en entreprise, sont encore basée sur ces technologies.Par exemple, l'interface d'administration de mon antivirus AVG est développée en SilverLight, AVG va devoir réecrire entièrement son outil, et je devrais me mettre à jour. Un site de régie de transports de Reims qui calcule des itinéraires en bus est développé avec des Applets, il ne fonctionnera bientôt plus. Etc.
Pour le fun : avant que le couple infernal HTML5/javascript ne s'impose définitivement comme plateforme de développement pour les années à venir, il y a eu une période récente (disons il y a 3 ou 4 ans) où l'industrie hésitait à s'orienter vers une solution basée sur une généralisation de l'usage de plugins évolués permettant d'offrir des applications modernes et ergonomiques au sein du navigateur. Ceux qui ont fait ce choix doivent aujourd'hui le regretter amèrement, et pourtant ils n'ont rien à se reprocher car la situation était tout sauf lisible. A titre personnel, j'ai vu une grande banque Française devoir mettre à la poubelle des années/homme de développements et de R&D suite à l'abandon de Flex (une évolution de Flash Player pour faire simple) par Adobe qui a décidé brutalement de se recentrer sur HTML5.
Fonctions cryptographiques
Le protocole http est un protocole non crypté, et en outre particulièrement simple.
Conséquence, le premier ado boutonneux venu peut s'amuser à sniffer des trames réseau (écouter les informations qui circulent sur Internet, comme on peut espionner des communications téléphoniques) et récupérer toutes sortes d'informations. Les outils pour faire ça sont largement accessibles, et si on peut considérer que le hacking est un passe temps largement préférable à la drogue, aux tournantes et courses sauvage avec la voiture volée à papa, j'en connais certains qui ont eu la mauvaise surprise de voir débouler la gendarmerie chez eux pour une perquisition et la saisie de tous leurs ordinateurs.
Plus sérieusement, le développement du Web comme plateforme pour le commerce électronique était impossible tant qu'on ne pouvait pas garantir un minimum de sécurité. Ceux qui se sont fait pirater leur CB une fois voient de quoi je veux parler.
Alors, je ne vais pas entrer dans le détail, ce serait un peu long, mais disons simplement que les navigateurs modernes embarquent divers algorithmes sophistiqués et des bases de certificats de sécurité (émis par les organismes de certifications). Tout ceci permet de faire fonctionner le protocole HTTPS. Le "S" en plus c'est pour dire SECURE http, et cette sécurisation s'appuie sur un cryptage du protocole http par une technologie appelée SSL (Secure Socket Layer) ou TLS (nouveau nom de SSL).
L'intérêt est que ce cryptage intervient sur la couche transport et est donc totalement transparent pour le protocole http lui même (qui est sur la couche application). Bon, si vous ne comprenez pas cette phrase ce n'est pas grave. Ce qu'il faut retenir c'est que rien ne change, hormis un peu de configuration au niveau des serveurs et un peu de travail administratif (achat et déploiement de certificats SSL auprès de tiers de confiance, aka organismes certificateurs). Par contre, pour les utilisateurs, tout est identique : simplement un petit cadenas apparaîtra dans le navigateur et l'url démarrera par HTTPS au lieu de HTTP.
Le seul souci est que dans la course aux armements entre missile et blindage, il est nécessaire de faire évoluer régulièrement les algorithmes de cryptographie utilisés, et d'autres éléments, au fur et à mesure que la NSA et autres groupes mafieux (non je ne peux pas blairer les yankees) arrivent à casser les codes.
Du coup, il est parfois requis de changer de navigateur, les navigateurs trop anciens étant insuffisamment sécurisés. C'est comme si vous rouliez avec un char en blindage de 30 quand Daech dispose de missiles qui percent du 40 : il vous faut prendre un char en blindage de 50.
Si les choses sont stables depuis un bon moment et que ce problème ne concerne que ceux qui tournent avec de très vieux systèmes, il va cependant revenir sur le devant de la scène en 2016:2017 suite à l'abandon de SHA-1 au profit de SHA-2 (des chercheurs en mathématique ont démontré que l'algo SHA-1 utilisé depuis des années était dépassé et pouvait être cassé sans nécessiter des moyens techniques hors de portée des groupes mafieux, et Snowden a balancé le fait que la NSA a dépensé les milliards requis pour pouvoir casser les cryptages actuels).
J'ai prévu, quand j'aurais un peu de courage, un article pour vulgariser les notions de base en cryptographie (mais là j'ai pas le temps, j'ai déjà une série à finir sur le montage d'un NAS maison et c'est du boulot, et pleins d'autres idées).
Plus de détail sur le reste ...
Ascii ?
Nous avons vu qu'on exprimait du texte en binaire en attribuant une valeur numérique décimale à chaque caractère et en exprimant cette valeur décimale en binaire.
Et la fameuse convention qui dit que la lettre "a" par exemple vaut la valeur 97 (01100001 en binaire), ben elle s'appelle Ascii (American Standard Code for Information Interchange, convention américaine pour l'échange d'information) et comme son nom l'indique elle est américaine ...
Du coup, quand on a voulu les traiter dans les systèmes informatiques initialement basés sur ce code Ascii ça a soulevé des tas de problèmes amusants avec lesquels on est encore en train de galérer 30 ans après (mais ça s'améliore grâce à une norme appelée Unicode qui prend en compte tous les caractères de tous les alphabets du monde).
Bref, je ferme cette parenthèse car il faudrait toute une série d'articles rien que pour expliquer tout ça en détail. Si vous ne comprenez pas, ne vous inquiétez pas, je connais des tas de gens avec des diplômes d'ingénieur en informatique et qui ne savent même pas ça :-(
Déjà, vous devez comprendre pourquoi les caractères accentués ne sont pas lisibles directement dans les URL (ils sont ré-encodés avec d'autres conventions), ou pourquoi il peut arriver que quand vous lisez des fichiers envoyés par un collègue étranger, certains caractères soient perdus et remplacés par d'autres.
Conclusion
A ce stade, vous savez déjà tout ce qu'il faut pour comprendre le fonctionnement du web, et même un peu plus.
Cependant, sur cette base, il est possible d'aller un peu plus loin pour ceux qui sont intéressés. Je prévois quelques articles davantage destinés aux étudiants en informatique ou aux débutants dans la profession d'informaticien. Je ne pourrais pas tout vulgariser car c'est un travail trop long et fastidieux compte tenu de tous les pré-requis mais je vais essayer de faire en sorte que ça reste accessible aux curieux.
A suivre donc !
A suivre donc !
Aucun commentaire:
Enregistrer un commentaire