diff options
| author | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:40:17 -0500 |
|---|---|---|
| committer | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:40:17 -0500 |
| commit | 33058f2b292b3a581333bdfb21b8f671898c5060 (patch) | |
| tree | 51c3e392513ec574331b2d3f85c394445ea803c6 /files/fr/web/http/basics_of_http | |
| parent | 8b66d724f7caf0157093fb09cfec8fbd0c6ad50a (diff) | |
| download | translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.gz translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.bz2 translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.zip | |
initial commit
Diffstat (limited to 'files/fr/web/http/basics_of_http')
8 files changed, 1351 insertions, 0 deletions
diff --git a/files/fr/web/http/basics_of_http/choisir_entre_les_urls_www_sans_www/index.html b/files/fr/web/http/basics_of_http/choisir_entre_les_urls_www_sans_www/index.html new file mode 100644 index 0000000000..fe94d1e4c9 --- /dev/null +++ b/files/fr/web/http/basics_of_http/choisir_entre_les_urls_www_sans_www/index.html @@ -0,0 +1,69 @@ +--- +title: Choisir entre les URLs avec ou sans www +slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www +tags: + - Guide + - HTTP + - URL +translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">Une question récurrente chez les propriétaires de sites web est de choisir entre utiliser des URLs qui débutent ou non par www. Cette page fournit quelques conseils sur la meilleure approche à envisager.</p> + +<h2 id="Que_sont_les_noms_de_domaines">Que sont les noms de domaines ?</h2> + +<p>Dans une URL HTTP, la première chaîne qui suit le schéma <code>http://</code> ou <code>https://</code> est appelé le nom de domaine. C'est le nom du site où le document est hébergé, ce site étant lui-même hébergé sur un serveur.</p> + +<p>Un serveur n'est pas nécessairement une machine physique : plusieurs serveurs peuvent cohabiter au sein d'une seule machine physique. Un serveur peut tout aussi bien être supporté par plusieurs machines, qui permettent de restituer l'ensemble de la réponse ou de pouvoir équilibrer la charge des requêtes entre elles. Le point clé est que, sémantiquement, <em>un nom de domaine représente un seul serveur</em>.</p> + +<h2 id="Donc_je_dois_choisir_l'un_ou_l'autre_pour_mon_site_web">Donc je dois choisir l'un ou l'autre pour mon site web ?</h2> + +<ul> + <li><u>Oui</u>, car vous avez besoin de faire une sélection et de vous y tenir. Vous être libre de choisir l'un ou l'autre pour déterminer votre domaine canonique mais une fois que vous avez effectué votre choix, vous devez le respecter. Votre site web gardera ainsi une structure consistante pour vos utilisateurs ainsi que les moteurs de recherche. Cela inclut la manière dont vous exposez des liens vers votre site, que ce soit au sein du site (auquel cas l'utilisation d'adresses relatives devrait simplifier le problème), ou bien lorsque vous partagez l'information à l'extérieur (courriel, réseaux sociaux, ...).</li> + <li><u>Non</u>, vous pouvez utiliser les deux à la fois. La seule chose importante est de rester cohérent au niveau du nom de domaine que vous utilisez de manière officielle. <strong>Ce domaine est appelé le nom de domaine <em>canonique</em>.</strong> L'ensemble de vos liens absolus doivent y référer. Vous pouvez, dans le même temps, bénéficier du second domaine. HTTP et HTML supportent deux techniques qui permettent à vos utilisateurs et aux moteurs de recherche de savoir simplement lequel des deux domaines constitue le domaine canonique, bien que l'autre domaine soit actif et serve des pages web.</li> +</ul> + +<p>Ainsi, choisissez un de vos domaines comme domaine canonique. Les deux techniques ci-dessous permettent de maintenir le domaine non-canonique en état de marche.</p> + +<h2 id="Techniques_pour_les_URLs_canoniques">Techniques pour les URLs canoniques</h2> + +<p>Il existe différentes manières de choisir le site web qui sera le site <em>canonique</em>.</p> + +<h3 id="Utiliser_la_redirection_via_HTTP_301">Utiliser la redirection via HTTP 301</h3> + +<p>Dans ce cas, vous devez configurer le serveur qui reçoit les requêtes HTTP (a priori, le serveur qui sert le domaine avec ou sans www est le même) pour qu'il réponde un statut HTTP {{HTTPStatus(301)}} pour chaque requête provenant du domaine non-canonique. Cela aura pour effet de rediriger le navigateur qui essaie d'accéder aux adresses non-canoniques vers leurs équivalents canoniques. Ainsi, si vous avez choisi d'utiliser un domaine qui ne démarre pas par www, vous devriez rediriger chaque URL débutant par www vers une URL sans www.</p> + +<p>Exemple :</p> + +<ol> + <li>Un serveur reçoit une requête pour <code>https://www.exemple.org/kadoc</code> (tandis que le domaine canonique est constitué par exemple.org)</li> + <li>Le serveur répond via un code {{HTTPStatus(301)}} contenant l'en-tête {{HTTPHeader("Location")}}<code>: https://exemple.org/kadoc</code>.</li> + <li>Le client émet une requête pour le domaine canonique : <code>https://exemple.org/kadoc</code></li> +</ol> + +<p>Le <a href="https://github.com/h5bp/html5-boilerplate">projet HTML5 boilerplate</a> contient un exemple sur <a href="https://github.com/h5bp/html5-boilerplate/blob/7a22a33d4041c479d0962499e853501073811887/.htaccess#L219-L258">la configuration d'un serveur Apache afin de rediriger un domaine vers un autre</a>.</p> + +<h3 id="Utiliser_<_link_relcanonical>">Utiliser <em><code>< link rel="canonical"></code></em></h3> + +<p>Il est possible d'ajouter un élément HTML spécifique {{HTMLElement("link")}} pour indiquer l'adresse canonique de la page. Cela n'a aucun impact sur la personne qui visite la page web, en revanche, elle permet aux robots des moteurs de recherche de connaître l'adresse effective de la page. De cette manière les moteurs de recherche n'indexent pas le contenu de façon répétée. Sans cet élément, ils pourraient penser que la page est dupliquée ou constitue du spam, ce qui entraînerait la disparition de la page dans les index des moteurs de recherche ou un mauvais classement.</p> + +<p>Lors de l'ajout de cet élément, vous servez le même contenu entre les deux domaines tout en indiquant aux moteurs de recherche lequel est canonique. Dans l'exemple précédent <code>https://www.exemple.org/kadoc</code> contiendrait le même contenu que <code>https://exemple.org/kadoc</code>, avec un élément {{htmlelement("link")}} supplémentaire dans l'en-tête :</p> + +<p><code>< link href="https://exemple.org/kadoc" rel="canonical"></code></p> + +<p>À l'inverse du cas précédent, les URLs débutant par www ou non seront alors considérées dans l'historique du navigateur comme des entrées distinctes.</p> + +<h2 id="Adapter_votre_page_aux_deux_cas">Adapter votre page aux deux cas</h2> + +<p>Grâce à ces techniques, vous pouvez configurer votre serveur pour répondre correctement à l'ensemble des cas (www ou non). Il s'agit d'une bonne démarche, étant donné qu'il est impossible de prédire ce qu'un utilisateur tapera dans sa barre d'adresse. Il faut simplement déterminer votre domaine canonique pour ensuite effectuer la redirection vers ce dernier.</p> + +<h2 id="Choisir_www_ou_non">Choisir www ou non</h2> + +<p class="entry-title">Il s'agit d'un sujet subjectif âprement débattu. S vous souhaitez approfondir, vous pouvez lire <a href="http://www.themezilla.com/should-you-use-www-in-your-url-or-not/">de nombreux</a> <a href="http://www.wpbeginner.com/beginners-guide/www-vs-non-www-which-is-better-for-wordpress-seo/">articles</a> sur ce sujet.</p> + +<h2 id="Voir_aussi">Voir aussi</h2> + +<ul> + <li><a href="https://www.chrisfinke.com/2011/07/25/what-do-people-type-in-the-address-bar/">Statistiques sur ce que les gens entrent dans la barre d'adresse</a> (2011)</li> +</ul> diff --git a/files/fr/web/http/basics_of_http/data_uris/index.html b/files/fr/web/http/basics_of_http/data_uris/index.html new file mode 100644 index 0000000000..418099cb90 --- /dev/null +++ b/files/fr/web/http/basics_of_http/data_uris/index.html @@ -0,0 +1,122 @@ +--- +title: URLs de données +slug: Web/HTTP/Basics_of_HTTP/Data_URIs +tags: + - Base64 + - Guide + - HTTP + - Intermédiaire + - URL +translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs +--- +<div>{{HTTPSidebar}}</div> + +<p><strong>Les URLs de données</strong>, les URLs préfixées par le schéma <code>data:</code>, permettent aux créateurs de contenu d'intégrer de petits fichiers dans des documents.</p> + +<div class="note"> +<p><strong>Remarque </strong>: Les URLs de données sont traitées comme des origines opaques uniques par les navigateurs modernes, ainsi, contrairement aux autres objets classiques, ces URLs n'héritent pas des propriétés de l'objet ayant mené à cette URL.</p> +</div> + +<h2 id="Syntaxe">Syntaxe</h2> + +<p>Les URLs de données sont composées de quatre parties : un préfixe (<code>data:</code>), un type MIME indiquant le type de donnée, un jeton facultatif encodé en <code>base64</code> dans le cas où il n'est pas textuel ainsi que les données elles-mêmes :</p> + +<pre class="syntaxbox">data:[<mediatype>][;base64],<data> +</pre> + +<p>Le <code>mediatype</code> est une chaîne de type MIME, telle que <code>'image/jpeg'</code> pour un fichier image JPEG. Si le format MIME n'est pas spécifié, la valeur par défaut sera <code>text/plain;charset=US-ASCII</code>.</p> + +<p>Si les données sont textuelles, vous pouvez simplement incorporer le texte (en utilisant les entités appropriées ou les échappements basés sur le type de document englobant). Sinon, vous pouvez spécifier <code>base64</code> pour intégrer des données binaires encodées en base64.</p> + +<p>Quelques exemples :</p> + +<dl> + <dt><code>data:,Hello%2C%20World!</code></dt> + <dd>Texte simple / Données brutes</dd> + <dt><code>data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D</code></dt> + <dd>Version encodée en base64 de ce qui précède</dd> + <dt><code>data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E</code></dt> + <dd>Un document HTML avec <code><h1>Hello, World!</h1></code></dd> + <dt><code>data:text/html,<script>alert('hi');</script></code></dt> + <dd>Un document HTML exécutant une alerte JavaScript. Notez que la balise fermante du script est requise.</dd> +</dl> + +<h2 id="Encodage_des_données_au_format_base64">Encodage des données au format base64</h2> + +<p>Il est possible de le faire très simplement via la ligne de commande <code>uuencode</code> pour les systèmes Linux et Mac OS X :</p> + +<pre>uuencode -m infile remotename +</pre> + +<p>Le paramètre <code>infile</code> est le nom du fichier que vous souhaitez encoder au format base64, <code>remotename</code> est le nom du fichier distant qui n'est pas réellement utilisé dans l'URL de type <code>data</code>.</p> + +<p>Le résultat devrait ressembler à :</p> + +<pre>begin-base64 664 test +YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK +==== +</pre> + +<p>L'URL de donnée pourra ainsi utiliser la donnée encodée après l'en-tête.</p> + +<h3 id="Dans_une_page_web_via_JavaScript">Dans une page web, via JavaScript</h3> + +<p>Les APIs web contiennent des méthodes pour encoder et décoder en base64 : <a href="/fr/docs/Web/API/WindowBase64/Base64_encoding_and_decoding">Décoder et encoder en base64</a>.</p> + +<h2 id="Problèmes_habituels">Problèmes habituels</h2> + +<p>Cette section décrit les problèmes qui apparaissent fréquemment lors de la création et de l'utilisation des URLs de type <code>data</code></p> + +<pre>data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val +</pre> + +<p>Cela représente une ressource HTML dont le contenu est le suivant :</p> + +<pre>beaucoup de texte...<p><a name="bottom">bottom</a>?arg=val +</pre> + +<dl> + <dt>Syntaxe</dt> + <dd>Le format pour les URLs de type <code>data</code> est très simple, mais il est aussi simple d'oublier la virgule qui précède le segment de données ou de mal encoder la donnée en base64.</dd> + <dt>Mise en forme HTML</dt> + <dd>Une URL de donnée expose un fichier dans un fichier, le fichier fourni peut éventuellement être bien plus gros que le fichier l'englobant. En tant qu'URL, une URL de donnée devrait pouvoir être mise en forme à l'aide de caractères d'espacement (retour chariot, tabulation ou espace), néanmoins, des limitations pratiques apparaissent lorsqu'il s'agit d'effectuer <a class="external" href="https://bugzilla.mozilla.org/show_bug.cgi?id=73026#c12">l'encodage en base64</a>.</dd> + <dt>Limitations sur la longueur</dt> + <dd>Bien que Firefox supporte les URLs de données ayant une taille virtuellement infinie, il est important de noter que les navigateurs ne sont pas obligés de supporter une longueur maximale de donnée. Ainsi dans Opera 11 les URLs ont une longueur maximale de 65535 caractères, limitant ainsi la longueur de la donnée utilisable dans les URLs de données à 65529 caractères si celle-ci est encodée.</dd> + <dt>Absence de gestion d'erreur</dt> + <dd>Les paramètres invalides dans le format MIME ou les coquilles lorsque l'on spécifie <code>'base64'</code>, sont ignorés mais aucune erreur n'est retournée.</dd> + <dt>Aucun support des requêtes via l'URL, etc</dt> + <dd> + <p>La donnée au sein de l'URL de donnée est opaque, ainsi toute tentative d'utiliser une chaîne de paramètres de recherche comme on le ferait avec une URL classique à l'aide de la syntaxe <code><url>?parameter-data</code>) avec une URL de donnée ne ferait qu'inclure les paramètres de l'URL au sein de la donnée.</p> + </dd> + <dt>Problèmes de sécurité</dt> + <dd>De nombreux problèmes de sécurité (comme le phishing) ont été associés au URLs de donnés et du fait qu'elle puisse avoir un accès direct au navigateur. Afin de réduire l'impact de ces problèmes, la navigation à la racine via des URLs de données <code>data://</code> a été bloquée dans Firefox 59+ (en version finale, Nightly/Beta bloquent à partir de la version 58). Nous espérons voir d'autres navigateurs nous emboîter le pas prochainement. <a href="https://blog.mozilla.org/security/2017/11/27/blocking-top-level-navigations-data-urls-firefox-58/">Voir Blocking Top-Level Navigations to data URLs for Firefox 58</a> pour plus de détails.</dd> +</dl> + +<h2 id="Spécifications">Spécifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Spécification</th> + <th scope="col">Titre</th> + </tr> + <tr> + <td>{{RFC("2397")}}</td> + <td>Le schéma d'URL "data"</td> + </tr> + </tbody> +</table> + +<h2 id="Compatibilité_des_navigateurs">Compatibilité des navigateurs</h2> + +<p>{{compat("http.data-url")}}</p> + +<h2 id="Voir_aussi">Voir_aussi</h2> + +<ul> + <li><a href="/fr/docs/Web/API/WindowBase64/Base64_encoding_and_decoding">Décoder et encoder en base64</a></li> + <li>{{domxref("WindowBase64.atob","atob()")}}</li> + <li>{{domxref("WindowBase64.btoa","btoa()")}}</li> + <li><a href="/fr/docs/Web/CSS/uri">CSS <code>url()</code></a></li> + <li><a href="/fr/docs/Glossary/URI">URI</a></li> +</ul> diff --git a/files/fr/web/http/basics_of_http/evolution_of_http/index.html b/files/fr/web/http/basics_of_http/evolution_of_http/index.html new file mode 100644 index 0000000000..fdda44f6a0 --- /dev/null +++ b/files/fr/web/http/basics_of_http/evolution_of_http/index.html @@ -0,0 +1,202 @@ +--- +title: L'évolution du protocole HTTP +slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +tags: + - Guide + - HTTP +translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +--- +<div>{{HTTPSidebar}} +<div> +<p><strong>Le protocole HTTP</strong> (HyperText Transfer Protocol) est le protocole qui sous-tend le World Wide Web. Conçu par Tim Berners-Lee et son équipe entre 1989 et 1991, HTTP a vécu de nombreux changements tout en conservant sa simplicité, étendant ainsi sa flexibilité. HTTP a évolué à partir d'un protocole sommaire d'échange de fichiers sur un réseau de confiance au sein d'un laboratoire jusqu'à devenir le labyrinthe moderne d'Internet permettant désormais le transport d'images, de vidéos en haute résolution et en 3D.</p> + +<h2 id="Linvention_du_World_Wide_Web">L'invention du World Wide Web</h2> + +<p>En 1989, alors qu'il travaillait au CERN, Tim Berners-Lee proposa la création d'un système hypertexte sur internet. Initialement nommé <em>Mesh, </em>il prit le nom de World Wide Web lors de sa mise en place en 1990. Bâti sur les protocoles existants TCP et IP, il consistait en quatre éléments de base :</p> + +<ul> + <li>Un format textuel pour représenter les documents hypertextes, l'<em><a href="/fr/docs/Web/HTML">HyperText Markup Language</a></em> (HTML).</li> + <li>Un protocole simple pour échanger ces documents, l'<em>HyperText Transfer Protocol </em>(HTTP).</li> + <li>Un logiciel client pour exposer (et modifier) ces documents, le premier navigateur web nommé <em>WorldWideWeb</em>.</li> + <li>Un serveur pour garantir l'accès au document, version initiale du <em>httpd</em>.</li> +</ul> + +<p>Ces quatre piliers étaient opératoires dès fin 1990, et les premiers serveurs extérieurs au CERN tournaient déjà début 1991. Le 6 août 1991, Tim Berners-Lee écrit un <a href="https://groups.google.com/forum/#!msg/alt.hypertext/eCTkkOoWTAY/urNMgHnS2gYJ">billet</a> sur le groupe de discussion public <em>alt.hypertext</em> : ce billet est dorénavant considéré comme point de départ officiel du World Wide Web en tant que projet public.</p> + +<p>Le protocole HTTP utilisé dans ces premières phases était très simple. Plus tard surnommé HTTP/0.9, il était aussi parfois surnommé le protocole <em>une ligne</em> - "the one-line protocol".</p> + +<h2 id="HTTP0.9_–_Le_protocole_une_ligne">HTTP/0.9 – Le protocole <em>une ligne</em></h2> + +<p>La version initiale de HTTP n'avait pas de numéro de version. Elle fut appelée 0.9 pour la différencier des versions ultérieures. HTTP/0.9 est extrêmement simple : la requête se compose d'une ligne unique et commence par la seule méthode possible {{HTTPMethod("GET")}}, suivie par le chemin pour accéder à la ressource (sans l'URL, puisque ni protocole, serveur ni port ne sont nécessaires quand on est connecté au serveur) :</p> + +<pre>GET /monfichier.html</pre> + +<p>La réponse est aussi extrêmement simple, il s'agit directement du fichier demandé :</p> + +<pre><HTML> +Une page HTML très simple +</HTML></pre> + +<p>Contrairement aux évolutions suivantes, il n'y avait pas d'en-tête HTTP. Cela signifie que seuls des fichiers HTML pouvaient être transmis, à l'exclusion de tout autre type de documents. Il n'existait pas de code d'erreur ou d'état : en cas de problème, un fichier HTML particulier, contenant la description du problème rencontré, était renvoyé afin d'être lu par l'utilisateur.</p> + +<h2 id="HTTP1.0_–_Mise_en_place_de_lextensibilité">HTTP/1.0 – Mise en place de l'extensibilité</h2> + +<p>HTTP/0.9 était très limité. Navigateurs et serveurs l'ont rapidement étendu vers des usages plus polyvalents.</p> + +<ul> + <li>Dans chaque requête figurent dorénavant les informations de version (<code>HTTP/1.0</code> est ajouté à la ligne <code>GET</code>).</li> + <li>Une ligne de code d'état est aussi envoyée au début de chaque réponse. Elle permet au navigateur de prendre connaissance du succès ou de l'échec de la requête, et de s'adapter en conséquence (avec une mise à jour, par exemple, ou en utilisant son cache local de manière spécifique).</li> + <li>La notion d'en-tête HTTP a été mise en place à la fois pour les requêtes et pour les réponses. Elle autorise la transmission de métadonnées, et rend le protocole très flexible et extensible.</li> + <li>Avec ces nouveaux en-têtes HTTP, il est désormais possible de transmettre d'autres documents que des fichiers HTML bruts (grâce à l'en-tête {{HTTPHeader("Content-Type")}}.</li> +</ul> + +<p>Une requête typique ressemblait ainsi à :</p> + +<pre>GET /pamage.html HTTP/1.0 +User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) + +200 OK +Date: Tue, 15 Nov 1994 08:12:31 GMT +Server: CERN/3.0 libwww/2.17 +Content-Type: text/html +<HTML> +Une page avec une image + <IMG SRC="/monimage.gif"> +</HTML></pre> + +<p>Suivie d'une seconde connexion-requête pour le transfert de l'image :</p> + +<pre>GET /monimage.gif HTTP/1.0 +User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) + +200 OK +Date: Tue, 15 Nov 1994 08:12:32 GMT +Server: CERN/3.0 libwww/2.17 +Content-Type: text/gif +<em>(contenu de l'image)</em></pre> + +<p>Ces innovations n'ont pas été mises en place à la suite d'un effort concerté, mais par une approche expérimentale couvrant les années 1991-1995. Un serveur ou un navigateur ajoutaient une fonctionnalité pour voir si elle suscitait l'intérêt escompté. Nombre de problèmes d'interopérabilité relevaient du lot commun. Pour répondre à ces désagréments, un document d'information décrivant les pratiques communes a été publié en novembre 1996, {{RFC(1945)}}. Cela correspondait à la définition de HTTP/1.0. Mais rigoureusement parlant, il convient de noter qu'il ne possède pas l'état de standard officiel.</p> + +<h2 id="HTTP1.1_–_Le_protocole_standardisé">HTTP/1.1 – Le protocole standardisé</h2> + +<p>Parallèlement aux usages quelque peu chaotiques des différentes applications HTTP/1.0, dès 1995 c'est-à-dire bien avant la publication du document HTTP/1.0 l'année suivante, une standardisation appropriée se trouvait sur les rails. HTTP/1.1, première version standardisée de HTTP, fut publié début 1997, seulement quelques mois après HTTP/1.0.</p> + +<p>HTTP/1.1 dissipait des ambiguïtés et introduisait de nombreuses améliorations.</p> + +<ul> + <li>Connexion pouvant être ré-utilisée : économie du temps qu'il faudrait pour en ouvrir plusieurs dans le but de présenter les ressources constituant le document original récupéré.</li> + <li>Ajout du <em>pipelining</em> : permet d'envoyer une seconde requête avant que la réponse de la première ne soit complètement transmise, diminuant le temps de latence de la communication.</li> + <li>Désormais les réponses par morceau sont aussi supportées.</li> + <li>Mise en place de mécanismes de contrôle de caches additionnels.</li> + <li>Mise en place de la négociation de contenu pour le langage, l'encodage et le type : le client et le serveur peuvent ainsi se mettre d'accord sur le contenu le plus adéquat à échanger.</li> + <li>Grâce à l'en-tête {{HTTPHeader("Host")}}, la capacité à héberger différents domaines sur la même adresse IP autorise désormais une colocation de serveurs.</li> +</ul> + +<p>Une suite typique de requêtes, toutes via la même connexion, ressemble dès lors à ceci :</p> + +<pre>GET /fr/docs/Glossary/Simple_header HTTP/1.1 +Host: developer.mozilla.org +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate, br +Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header + +200 OK +Connection: Keep-Alive +Content-Encoding: gzip +Content-Type: text/html; charset=utf-8 +Date: Wed, 20 Jul 2016 10:55:30 GMT +Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a" +Keep-Alive: timeout=5, max=1000 +Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT +Server: Apache +Transfer-Encoding: chunked +Vary: Cookie, Accept-Encoding + +<em>(contenu)</em> + + +GET /static/img/header-background.png HTTP/1.1 +Host: developer.cdn.mozilla.net +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 +Accept: */* +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate, br +Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header + +200 OK +Age: 9578461 +Cache-Control: public, max-age=315360000 +Connection: keep-alive +Content-Length: 3077 +Content-Type: image/png +Date: Thu, 31 Mar 2016 13:34:46 GMT +Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT +Server: Apache + +<em>(contenu comprenant une image sur 3077 octets)</em></pre> + +<p>HTTP/1.1 a été publié pour la première fois en tant que {{rfc(2068)}} en janvier 1997.</p> + +<h2 id="Plus_de_quinze_années_dextension">Plus de quinze années d'extension</h2> + +<p>Grâce à son extensibilité (création aisée de nouvelles en-têtes et méthodes) et bien que le protocole HTTP/1.1 ait été amélioré par deux révisions - {{RFC("2616")}} publiée en juin 1999, et les séries {{RFC("7230")}}-{{RFC("7235")}} publiées en juin 2014, en prévision de la publication de HTTP/2 - ce protocole s'est montré extrêmement stable pendant plus de quinze ans.</p> + +<h3 id="HTTP_pour_des_transmissions_sécurisées">HTTP pour des transmissions sécurisées</h3> + +<p>La modification principale du protocole HTTP a été faite vers la fin de l'année 1994. Au lieu d'envoyer HTTP vers une pile TCP/IP basique, Netscape Communication avait ajouté une couche additionnelle de transmission chiffrée : SSL. SSL 1.0 n'est jamais paru en-dehors des entreprises, mais SSL 2.0 et ses successeurs SSL 3.0 et SSL 3.1 ont permis aux sites web e-commerce, grâce au chiffrement, de garantir l'authenticité des messages échangés entre serveur et client. Le SSL a pris place dans les standards internationaux et est finalement devenu TLS. Ses versions 1.0, 1.1 et 1.2 sont apparues pour successivement mettre fin à des vulnérabilités. TLS 1.3 est actuellement en phase d'élaboration.</p> + +<p>Dans le même temps, le besoin d'une couche de transport chiffrée s'est avéré de plus en plus nécessaire. Le Web avait perdu de la fiabilité relative d'un réseau principalement académique, pour devenir une jungle où publicitaires, individus problématiques aussi bien que criminels, rivalisent pour obtenir le maximum de données privées concernant les utilisateurs, tenter d'usurper leur identité, et même de remplacer les données transmises par des données altérées. Alors que les applications créées avec HTTP gagnaient en puissance, accédant à un nombre croissant de données privées - telles que listes de contacts, e-mail ou position géographique de l'utilisateur - le besoin d'obtenir TLS est devenu omniprésent, au-delà même des cas d'e-commerce.</p> + +<h3 id="Utilisation_de_HTTP_dans_des_applications_complexes">Utilisation de HTTP dans des applications complexes</h3> + +<p>La vision initiale du Web de Tim Berners-Lee ne se limitait pas uniquement à consulter des pages. Il imaginait un Web où tout un chacun pourrait ajouter et déplacer des documents à distance tel un système de fichiers distribué. Aux environs de 1996, HTTP a été étendu pour permettre l'édition. Un standard, appelé WebDAV fût alors créé. Il fut ensuite étendu à des applications spécifiques telles CardDAV pour gérer un répertoire d'adresses ou CalDAV pour gérer des calendriers. Toutes ces extensions se finissant par DAV avait une faiblesse : elles devaient être implémentées par le serveur pour pouvoir fonctionner, ce qui ne coulait pas de source. Leur utilisation au sein du Web est restée minimale.</p> + +<p>En 2000, un nouveau modèle pour utiliser HTTP fût conçu : {{glossary("REST", "representational state transfer")}} (ou REST). Les actions induites par l'API n'étaient plus transmises par de nouvelles extensions de HTTP mais uniquement en accédant à des URIs à l'aides des méthodes HTTP/1.1 de base. Cela permettait à toute application web de fournir une API à partir de laquelle on autorisait la lecture ou l'écriture des données sans avoir à mettre à jour son serveur ou son navigateur web : tout ce dont on avait besoin était présent dans les fichiers transmis via les méthodes HTTP/1.1. L'inconvénient de l'approche REST étant que chaque site web définit son API REST non-standard et exerce un contrôle total à l'inverse des extensions *DAV ou les clients et les serveurs étaient interopérables. Les API REST sont devenues omniprésentes dans les années 2010.</p> + +<p>Depuis 2005, le nombre d'APIs ouvertes sur des pages a énormément augmenté. Certaines APIs ont d'ailleurs étendu HTTP via des en-têtes HTTP spécifiques afin de répondre à des besoins particuliers tels que:</p> + +<ul> + <li><a href="/fr/docs/Web/API/Server-sent_events">Évènements générés par le serveur</a>, le serveur peut éventuellement pousser des messages au navigateur.</li> + <li><a href="/fr/docs/Web/API/WebSocket_API">WebSocket</a>, un nouveau protocole qui peut être utilisé en passant à une version récente de HTTP.</li> +</ul> + +<h3 id="Relâcher_les_contraintes_du_modèle_de_sécurité_du_Web">Relâcher les contraintes du modèle de sécurité du Web</h3> + +<p>HTTP est indépendant du modèle de sécurité du Web, principalement créé via la <em><a href="/fr/docs/Web/Security/Same-origin_policy">same-origin policy</a></em>. En réalité le modèle de sécurité du Web s'est développé après la création de HTTP. D'années en années, il s'est avéré utile de devenir plus tolérant en termes d'origine de contenu, en supprimant certaines restrictions, sous certaines conditions. L'étendue des restrictions levées ainsi que l'application est transmise au client à l'aide d'en-têtes HTTP. Ces en-têtes sont définis au travers des spécifications <a href="/fr/docs/Glossary/CORS">Cross-Origin Resource Sharing</a> (CORS) ou <a href="/fr/docs/Web/Security/CSP">Content Security Policy</a> (CSP).</p> + +<p>D'autres extensions de HTTP sont apparues, parfois de manière expérimentale. On mentionnera par exemple les en-têtes connus tels : Do Not Track (Ne pas me pister) ({{HTTPHeader("DNT")}}) permettant de contrôler la vie privée, {{HTTPHeader("X-Frame-Options")}}, ou {{HTTPHeader('Upgrade-Insecure-Requests')}} même s'il en existe beaucoup d'autres.</p> + +<h2 id="HTTP2_–_Un_protocole_pour_plus_de_performances">HTTP/2 – Un protocole pour plus de performances</h2> + +<p>Au fur et à mesure, les pages web sont devenues de plus en plus complexes quitte à devenir des applications à part entière. La quantité de contenu multimédia ainsi que le nombre de scripts permettant plus d'interactivité ont aussi augmenté, ainsi de plus en plus de données sont transférées via des requêtes HTTP. Les connexions HTTP/1.1 nécessite un ordre séquentiel pour être correctement gérées. En théorie, il est possible d'utiliser plusieurs connexions en parallèle (généralement entre 5 et 8), néanmoins, cela implique beaucoup d'adaptation et apporte énormément de complexité. Ainsi, le <em>pipelining</em> HTTP s'est révélé être un fardeau dans le monde du développement web.</p> + +<p>Dans la première moitié des années 2010, Google a montré qu'il était possible d'utiliser une manière différente de communication entre un serveur et un navigateur, ce protocole expérimental porte le nom de SPDY. Cela a intéressé bon nombre de développeurs, que ce soit au niveau des serveurs ou des navigateurs. En augmentant la réactivité et en éliminant la duplication des données transmises, SPDY posa les bases du protocole HTTP/2.</p> + +<p>Le protocole HTTP/2 diffère de HTTP/1.1 sur plusieurs aspects:</p> + +<ul> + <li>Il est encodé en binaire plutôt qu'en texte. Il ne peut donc plus être lu ou écrit à la main. Malgré cette difficulté, il est désormais possible d'implémenter des techniques d'optimisation avancée.</li> + <li>C'est un protocole multiplexé. Plusieurs requêtes en parallèle peuvent être gérées au sein de la même connexion, supprimant ainsi la limitation séquentielle de HTTP/1.x.</li> + <li>HTTP/2 compresse les en-têtes, étant donné que des en-têtes similaires sont échangés lors d'une suite de requêtes, on supprime ainsi la duplication et l'échange inutiles des données similaires.</li> + <li>Il permet au serveur de remplir le cache du client avant qu'il ne soit demandé par ce dernier, on parle alors d'évènements générés par le serveur.</li> +</ul> + +<p>Devenu un standard officiel en mai 2015, HTTP/2 a rencontré un large succès. En janvier 2018, 23.9% des sites web utilisent HTTP/2 (8.7% en 2016)<sup><a href="https://w3techs.com/technologies/details/ce-http2/all/all">[1]</a></sup>. Ce qui représentait en 2015 plus de 68% des requêtes<sup><a href="https://www.keycdn.com/blog/http2-statistics/">[2]</a></sup>. Les sites web générant beaucoup de trafic montre un taux d'adoption très rapide, ce qui s'explique par le gain de bande passante et les économies ainsi générées.</p> + +<p>Cette adoption fulgurante de HTTP/2 s'explique probablement par le fait que cette nouvelle version ne nécessite pas de mise à jour des sites web et des applications, l'utilisation de HTTP/1.x ou HTTP/2 étant transparente. Il suffit qu'un serveur à jour et un navigateur moderne communiquent pour que cela fonctionne. La traction générée par les premiers utilisateurs ainsi que le renouvellement des serveurs devenant obsolètes entraînent la croissance de HTTP/2 sans que cela requiert des efforts supplémentaires.</p> + +<h2 id="Après_HTTP2">Après HTTP/2</h2> + +<p>HTTP n'a pas cessé d'évoluer depuis la parution de HTTP/2, de la même manière que pour HTTP/1.x, la modularité de HTTP permet toujours de lui ajouter de nouvelles fonctionnalités. Il est ainsi possible de mentionner les en-têtes suivants apparus en 2016 :</p> + +<ul> + <li>Prise en charge de {{HTTPHeader("Alt-Svc")}} qui permet de dissocier l'identification d'une ressource de son emplacement, permettant une optimisation du cache {{Glossary("CDN")}}.</li> + <li>L'apparition de {{HTTPHeader("Client-Hints")}} qui permet au navigateur ou client de transmettre directement au serveur des informations relatives à ses contraintes matérielles propres.</li> + <li>L'apparition de préfixes liés à la sécurité dans l'en-tête {{HTTPHeader("Cookie")}} permet désormais de s'assurer qu'un cookie sécurisé n'a pas été modifié</li> +</ul> + +<p>Cette évolution de HTTP montre sa modularité ainsi que sa simplicité, permettant la création d'applications et l'adoption du protocole. L'environnement au sein duquel HTTP évolue à l'heure actuelle est sensiblement différent de celui dans lequel il a été créé au début des années 1990. La conception de HTTP s'avère aujourd'hui être un véritable chef-d’œuvre, elle a permis au Web d'évoluer sur un quart de siècle sans créer de scissions. En corrigeant les failles et en continuant à supporter le caractère extensible du protocole, HTTP/2 laisse présager d'un avenir brillant pour ce protocole.</p> +</div> +</div> diff --git a/files/fr/web/http/basics_of_http/identifier_des_ressources_sur_le_web/index.html b/files/fr/web/http/basics_of_http/identifier_des_ressources_sur_le_web/index.html new file mode 100644 index 0000000000..0265a81829 --- /dev/null +++ b/files/fr/web/http/basics_of_http/identifier_des_ressources_sur_le_web/index.html @@ -0,0 +1,169 @@ +--- +title: Identifier des ressources sur le Web +slug: Web/HTTP/Basics_of_HTTP/Identifier_des_ressources_sur_le_Web +tags: + - HTTP +translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">La cible d'une requête HTTP est appelée une "ressource", elle ne possède pas de type particulier. Il peut s'agir d'un document, d'une photo ou de n'importe quoi d'autre. Chaque ressource est identifiée à l'aide d'une <em>Uniform Resource Identifier</em> ({{Glossary("URI")}}) utilisé au sein de HTTP pour identifier les ressources.</p> + +<p>L'identité et l'emplacement d'une ressource sur le Web sont souvent déterminées via une URL (<em>Uniform Resource Locator</em>° un type d'URI. Il existe des cas valides où l'identité et l'emplacement d'une ressource ne sont pas obtenus par la même URI comme lorsque l'en-tête {{HTTPHeader("Alt-Svc")}} est utilisé. La ressource requise par le client doit alors être récupérée à partir d'un emplacement différent.</p> + +<h2 id="URLs_et_URNs">URLs et URNs</h2> + +<h3 id="URLs">URLs</h3> + +<p>La forme la plus commune des URI est l'URL (<em>Uniform Resource Locator</em> ({{Glossary("URL")}})) que l'on connaît sous le nom d'adresse web.</p> + +<pre>https://developer.mozilla.org +https://developer.mozilla.org/fr/docs/Learn/ +https://developer.mozilla.org/fr/search?q=URL</pre> + +<p>Vous pouvez entrer chacune de ces URLs dans votre navigateur pour lui demander de charger la page associée (il s'agit ici de la ressource).</p> + +<p>Une URL est composée de différentes parties, certaines obligatoires et d'autres facultatives. Voici un exemple plus complet :</p> + +<pre>http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument</pre> + +<h3 id="URNs">URNs</h3> + +<p>Une URN ou <em>Uniform Resource Name</em> est une URI qui identifie une ressource à l'aide d'un nom dans un espace de noms (namespace) particulier.</p> + +<pre>urn:isbn:9780141036144 +urn:ietf:rfc:7230 +</pre> + +<p>Ces deux URNs correspondent :</p> + +<ul> + <li>au livre 1984 de George Orwell,</li> + <li>La spécification IETF 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing.</li> +</ul> + +<h2 id="Syntaxe_des_URIs_(Uniform_Resource_Identifiers)">Syntaxe des URIs (Uniform Resource Identifiers)</h2> + +<h3 id="Schéma_ou_protocole">Schéma ou protocole</h3> + +<dl> + <dt><img alt="Protocole" src="https://mdn.mozillademos.org/files/8013/mdn-url-protocol@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>http://</code> constitue le protocole, il indique le protocole qui doit être utilisé par le navigateur. Il s'agit généralement de HTTP ou de sa variante sécurisée HTTPS. Le Web nécessite l'un ou l'autre de ces protocoles néanmoins, les navigateurs sont capables de gérer d'autres protocoles tels que <code>mailto:</code> (pour ouvrir un client mail) or <code>ftp:</code> pour gérer un transfert de fichier. Essayez, lorsque vous naviguez, d'identifier les protocoles utilisés. Les schémas usuels sont :</dd> +</dl> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Schéma</th> + <th scope="col">Description</th> + </tr> + </thead> + <tbody> + <tr> + <td>data</td> + <td><a href="/fr/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">URIs de données</a></td> + </tr> + <tr> + <td>file</td> + <td>Fichiers du système hôte sur lequel est installé le navigateur</td> + </tr> + <tr> + <td>ftp</td> + <td><a href="/fr/docs/Glossary/FTP">File Transfer Protocol</a></td> + </tr> + <tr> + <td>http/https</td> + <td><a href="/fr/docs/Glossary/HTTP">Hyper text transfer protocol (sécurisé)</a></td> + </tr> + <tr> + <td>mailto</td> + <td>Adresse électronique</td> + </tr> + <tr> + <td>ssh</td> + <td>Secure shell</td> + </tr> + <tr> + <td>tel</td> + <td>téléphone</td> + </tr> + <tr> + <td>urn</td> + <td>Uniform Resource Names</td> + </tr> + <tr> + <td>view-source</td> + <td>code source de la ressource</td> + </tr> + <tr> + <td>ws/wss</td> + <td>connexions (chiffrées) <a href="/fr/docs/Web/API/WebSockets_API">WebSocket</a></td> + </tr> + </tbody> +</table> + +<h3 id="Autorité">Autorité</h3> + +<dl> + <dt><img alt="Nom de domaine" src="https://mdn.mozillademos.org/files/8015/mdn-url-domain@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>www.exemple.com</code> est le nom de domaine ou l'autorité qui gère cet espace de noms. Il indique quel serveur Web est appelé. Il est aussi possible d'utiliser directement une adresse IP ({{Glossary("IP address")}}), néanmoins elles sont moins pratiques à manipuler pour des humains et sont donc moins fréquemment utilisées pour accéder à une ressource sur le Web.</dd> +</dl> + +<h3 id="Port">Port</h3> + +<dl> + <dt><img alt="Port" src="https://mdn.mozillademos.org/files/8017/mdn-url-port@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>:80</code> constitue le port. Il indique la "porte" technique à utiliser pour accéder à une ressource sur un serveur web. Il est généralement omis puisque le serveur web utilisera par défaut les ports standards pour HTTP (port 80 pour HTTP et 443 pour HTTPS) pour permettre l'accès aux ressources qu'il héberge. Dans le cas où le port par défaut n'est pas celui utilisé, il est obligatoire de le spécifier.</dd> +</dl> + +<h3 id="Chemin">Chemin</h3> + +<dl> + <dt><img alt="Chemin d'accès au fichier" src="https://mdn.mozillademos.org/files/8019/mdn-url-path@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>/chemin/du/fichier.html</code> constitue le chemin d'accès à la ressource sur le serveur web. Au début du Web, le chemin représentait un emplacement physique où le fichier était stocké, à l'heure actuelle il s'agit d'une abstraction gérée par le serveur web sans réelle existence physique..</dd> +</dl> + +<h3 id="Requête">Requête</h3> + +<dl> + <dt><img alt="Paramètre" src="https://mdn.mozillademos.org/files/8021/mdn-url-parameters@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>?key1=value1&key2=value2</code> sont des paramètres additionnels fournis au serveur web. Ces paramètres sont un ensemble de clés/valeurs séparé par le symbole <code>&</code>. Le serveur web peut utiliser ces paramètres pour effectuer des tâches avant de retourner une ressource au client. Chaque serveur web possède ses propres règles en ce qui concerne la gestion des paramètres.</dd> +</dl> + +<h3 id="Fragment">Fragment</h3> + +<dl> + <dt><img alt="Ancre" src="https://mdn.mozillademos.org/files/8023/mdn-url-anchor@x2.png" style="height: 70px; width: 440px;"></dt> + <dd><code>#QuelquePartDansLeDocument</code> est une ancre vers un morceau de la ressource en particulier, elle constitue une sorte de marque-page à l'intérieur de la ressource. Cela permet au navigateur de savoir où aller pour afficher le contenu à l'emplacement de l'ancre. Au sein d'une page HTML par exemple, le navigateur défilera jusqu'à ce point. Pour un document vidéo ou audio, le navigateur essaiera d'accéder au temps indiqué par l'ancre. On notera que la partie située après le caractère #, aussi appelé le fragment, n'est jamais envoyé au serveur avec la requête.</dd> +</dl> + +<h2 id="Exemples">Exemples</h2> + +<pre>https://developer.mozilla.org/en-US/docs/Learn +tel:+1-816-555-1212 +git@github.com:mdn/browser-compat-data.git +ftp://example.org/resource.txt +urn:isbn:9780141036144 +</pre> + +<h2 id="Spécifications">Spécifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Spécification</th> + <th scope="col">Titre</th> + </tr> + <tr> + <td>{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> + </tr> + </tbody> +</table> + +<h2 id="Voir_aussi">Voir aussi</h2> + +<ul> + <li><a href="/fr/docs/Learn/Common_questions/What_is_a_URL">Qu'est-ce qu'une URL ?</a></li> + <li><a href="https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">La liste des différents schémas des URIs, maintenue par l'IANA</a></li> +</ul> diff --git a/files/fr/web/http/basics_of_http/index.html b/files/fr/web/http/basics_of_http/index.html new file mode 100644 index 0000000000..0276210a16 --- /dev/null +++ b/files/fr/web/http/basics_of_http/index.html @@ -0,0 +1,48 @@ +--- +title: L'essentiel de HTTP +slug: Web/HTTP/Basics_of_HTTP +tags: + - Aperçu + - HTTP +translation_of: Web/HTTP/Basics_of_HTTP +--- +<div>{{HTTPSidebar}}</div> + +<p>HTTP est un protocole extensible. Il s'appuie sur quelques concepts basiques comme la notion de ressources et d'URI, une structure de messages simple et une structure client-serveur pour le flux de communication. En plus de ces concepts basiques, de nombreuses extensions du protocole sont apparues au fil des ans, ajoutant de nouvelles fonctionnalités et de nouvelle syntaxes en créant de nouvelles méthodes ou en-têtes HTTP.</p> + +<h2 id="Articles">Articles</h2> + +<dl> + <dt><a href="/fr/docs/Web/HTTP/Overview">Vue d'ensemble de HTTP</a></dt> + <dd>Décrit ce qu'est HTTP et son rôle dans l'architecture du Web ainsi que sa position dans la pile de protocoles.</dd> + <dt><a href="/fr/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Évolution de HTTP</a></dt> + <dd>HTTP a été créé au début des années 1990 et a été étendu plusieurs fois. Cet article relate son histoire et décrit HTTP/0.9, HTTP/1.0, HTTP/1.1, et le récent HTTP/2. Les nouveautés mineures introduites au fil des ans sont aussi présentées.</dd> + <dt><strong>Négocier une version HTTP</strong></dt> + <dd>Explique comment un client et un serveur peuvent négocier une version HTTP spécifique pour pouvoir utiliser une version plus récente du protocole.</dd> + <dt><a href="/fr/docs/Web/HTTP/Resources_and_URIs">Ressources et URIs</a></dt> + <dd>Une brève introduction à la notion de ressources, d'identifiants, et de localisations sur le web.</dd> + <dt><a href="/fr/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identifier des ressources sur le web</a></dt> + <dd>Décrit comment les ressources web sont référencées et comment les localiser.</dd> + <dt><a href="/fr/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">URIs de données</a></dt> + <dd>Un type d'URIs spécifique qui intègre directement la ressource qu'il représente. Les URIs de données sont très commodes mais s'accompagnent de quelques mises en garde.</dd> + <dt>URLs de ressources</dt> + <dd>Les URLs de ressources, qui sont préfixées par le schéma <code>resource:</code> sont utilisées par Firefox et les extensions de Firefox pour charger des ressources de façon interne, néanmoins une partie de l'information est exposée aux sites web lorsque le navigateur s'y connecte.</dd> + <dt>Séparer l'identité et la localisation d'une ressource : l'en-tête HTTP Alt-Svc (Alternative Service)</dt> + <dd>La plupart du temps, l'identité et la localisation d'une ressource web sont associées. Cela peut être modifié avec l'en-tête {{HTTPHeader("Alt-Svc")}}.</dd> + <dt><a href="/fr/docs/Web/HTTP/Basics_of_HTTP/MIME_types">Types MIME</a></dt> + <dd>Depuis HTTP/1.0, différents types de contenus peuvent être transmis. Cet article explique comment cela est fait via l'utilisation de l'en-tête {HTTPHeader("Content-Type")}} et le standard MIME.</dd> + <dt><a href="/fr/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs">Choisir entre des URL de type www ou non</a></dt> + <dd>Conseil sur l'utilisation d'un domaine préfixé ou non par www. Cet article explique les conséquences de ce choix aussi que les facteurs à considérer lors du choix.</dd> + <dt>Flux d'une session HTTP</dt> + <dd>Cet article fondamental décrit une session HTTP typique ; c'est-à-dire ce qui se passe "sous le capot" quand vous cliquez sur un lien dans votre navigateur ...</dd> + <dt><a href="/fr/docs/Web/HTTP/Messages">Messages HTTP</a></dt> + <dd>Les messages HTTP transmis pendant les requêtes ou les réponses ont une structure très claire. Cet article d'introduction décrit cette structure, son but et les possibilités qu'elle offre.</dd> + <dt>Trame et structure de message en HTTP/2</dt> + <dd>HTTP/2 représente les messages HTTP/1.x par une trame binaire. Cet article explique la structure de la trame, son but et la manière dont elle est encodée.</dd> + <dt><a href="/fr/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Gestion des connexions en HTTP/1.x</a></dt> + <dd>HTTP/1.1 était la première version d'HTTP à supporter les connexions persistantes et la combinaison de requêtes dans une seule connexion. Cet article explique ces deux concepts.</dd> + <dt>Gestion des connexions en HTTP/2</dt> + <dd>HTTP/2 a complètement revisité la manière dont les connexions sont créées et maintenues. Cet article explique comment les trames HTTP permettent le multiplexage et résolvent le problème de la trame bloquante ('head-of-line' blocking) des précédentes versions.</dd> + <dt><a href="/fr/docs/Web/HTTP/Content_negotiation">Négociation du contenu</a></dt> + <dd>HTTP introduit une série d'en-têtes commençant par <code>Accept-</code> permettant a un navigateur d'annoncer le format, la langue ou l'encodage qu'il préfère. Cet article explique comment cette préférence est déclarée, quelle réaction est attendue de la part du serveur et comment celui-ci choisit la réponse la plus adéquate possible.</dd> +</dl> diff --git a/files/fr/web/http/basics_of_http/mime_types/common_types/index.html b/files/fr/web/http/basics_of_http/mime_types/common_types/index.html new file mode 100644 index 0000000000..0fd192adb2 --- /dev/null +++ b/files/fr/web/http/basics_of_http/mime_types/common_types/index.html @@ -0,0 +1,356 @@ +--- +title: Liste des types MIME communs +slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +tags: + - Audio + - HTTP + - Reference + - Types MIME + - Video +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +--- +<div>{{HTTPSidebar}}</div> + +<p>Voici une liste de types MIME, associés par type et ordonnée par extension.</p> + +<p>Il existe deux types MIME principaux qui jouent un rôle important en terme de types par défaut :</p> + +<ul> + <li><code>text/plain</code> est le type MIME par défaut pour les fichiers texte. Un fichier texte doit pouvoir être lu par un utilisateur et ne pas contenir de données binaires.</li> + <li><code>application/octet-stream</code> est le type MIME par défaut dans tous les autres cas. Un fichier de type inconnu doit être associé à ce type MIME. Les navigateurs traiteront les fichiers associés à ce type MIME de façon particulière pour protéger au maximum l'utilisateur des éventuels risques de sécurité.</li> +</ul> + +<p>L'IANA constitue le registre officiel pour l'ensemble des types MIME et maintient une liste exhaustive à l'adresse suivante : <a href="https://www.iana.org/assignments/media-types/media-types.xhtml">https://www.iana.org/assignments/media-types/media-types.xhtml</a>. La table ci-dessous se focalise sur les types MIME importants dans le cadre du Web, <strong>elle n'est donc pas exhaustive :</strong></p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Extension</th> + <th scope="col">Type de document</th> + <th scope="col">Type MIME</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>.aac</code></td> + <td>fichier audio AAC</td> + <td><code>audio/aac</code></td> + </tr> + <tr> + <td><code>.abw</code></td> + <td>document <a href="https://fr.wikipedia.org/wiki/AbiWord">AbiWord</a></td> + <td><code>application/x-abiword</code></td> + </tr> + <tr> + <td><code>.arc</code></td> + <td>archive (contenant plusieurs fichiers)</td> + <td><code>application/octet-stream</code></td> + </tr> + <tr> + <td><code>.avi</code></td> + <td>AVI : Audio Video Interleave</td> + <td><code>video/x-msvideo</code></td> + </tr> + <tr> + <td><code>.azw</code></td> + <td>format pour eBook Amazon Kindle</td> + <td><code>application/vnd.amazon.ebook</code></td> + </tr> + <tr> + <td><code>.bin</code></td> + <td>n'importe quelle donnée binaire</td> + <td><code>application/octet-stream</code></td> + </tr> + <tr> + <td><code>.bmp</code></td> + <td>Images bitmap Windows OS/2</td> + <td><code>image/bmp</code></td> + </tr> + <tr> + <td><code>.bz</code></td> + <td>archive BZip</td> + <td><code>application/x-bzip</code></td> + </tr> + <tr> + <td><code>.bz2</code></td> + <td>archive BZip2</td> + <td><code>application/x-bzip2</code></td> + </tr> + <tr> + <td><code>.csh</code></td> + <td>script C-Shell</td> + <td><code>application/x-csh</code></td> + </tr> + <tr> + <td><code>.css</code></td> + <td>fichier Cascading Style Sheets (CSS)</td> + <td><code>text/css</code></td> + </tr> + <tr> + <td><code>.csv</code></td> + <td>fichier Comma-separated values (CSV)</td> + <td><code>text/csv</code></td> + </tr> + <tr> + <td><code>.doc</code></td> + <td>Microsoft Word</td> + <td><code>application/msword</code></td> + </tr> + <tr> + <td><code>.docx</code></td> + <td>Microsoft Word (OpenXML)</td> + <td><code>application/vnd.openxmlformats-officedocument.wordprocessingml.document</code></td> + </tr> + <tr> + <td><code>.eot</code></td> + <td>police MS Embedded OpenType</td> + <td><code>application/vnd.ms-fontobject</code></td> + </tr> + <tr> + <td><code>.epub</code></td> + <td>fichier Electronic publication (EPUB)</td> + <td><code>application/epub+zip</code></td> + </tr> + <tr> + <td><code>.gif</code></td> + <td>fichier Graphics Interchange Format (GIF)</td> + <td><code>image/gif</code></td> + </tr> + <tr> + <td><code>.htm<br> + .html</code></td> + <td>fichier HyperText Markup Language (HTML)</td> + <td><code>text/html</code></td> + </tr> + <tr> + <td><code>.ico</code></td> + <td>icône</td> + <td><code>image/x-icon</code></td> + </tr> + <tr> + <td><code>.ics</code></td> + <td>élément iCalendar</td> + <td><code>text/calendar</code></td> + </tr> + <tr> + <td><code>.jar</code></td> + <td>archive Java (JAR)</td> + <td><code>application/java-archive</code></td> + </tr> + <tr> + <td><code>.jpeg</code><br> + <code>.jpg</code></td> + <td>image JPEG</td> + <td><code>image/jpeg</code></td> + </tr> + <tr> + <td><code>.js</code></td> + <td>JavaScript (ECMAScript)</td> + <td><code>application/javascript</code></td> + </tr> + <tr> + <td><code>.json</code></td> + <td>donnée au format JSON</td> + <td><code>application/json</code></td> + </tr> + <tr> + <td><code>.mid</code><br> + <code>.midi</code></td> + <td>fichier audio Musical Instrument Digital Interface (MIDI)</td> + <td><code>audio/midi</code></td> + </tr> + <tr> + <td><code>.mpeg</code></td> + <td>vidéo MPEG</td> + <td><code>video/mpeg</code></td> + </tr> + <tr> + <td><code>.mpkg</code></td> + <td>paquet Apple Installer</td> + <td><code>application/vnd.apple.installer+xml</code></td> + </tr> + <tr> + <td><code>.odp</code></td> + <td>présentation OpenDocument</td> + <td><code>application/vnd.oasis.opendocument.presentation</code></td> + </tr> + <tr> + <td><code>.ods</code></td> + <td>feuille de calcul OpenDocument</td> + <td><code>application/vnd.oasis.opendocument.spreadsheet</code></td> + </tr> + <tr> + <td><code>.odt</code></td> + <td>document texte OpenDocument</td> + <td><code>application/vnd.oasis.opendocument.text</code></td> + </tr> + <tr> + <td><code>.oga</code></td> + <td>fichier audio OGG</td> + <td><code>audio/ogg</code></td> + </tr> + <tr> + <td><code>.ogv</code></td> + <td>fichier vidéo OGG</td> + <td><code>video/ogg</code></td> + </tr> + <tr> + <td><code>.ogx</code></td> + <td>OGG</td> + <td><code>application/ogg</code></td> + </tr> + <tr> + <td><code>.otf</code></td> + <td>police OpenType</td> + <td><code>font/otf</code></td> + </tr> + <tr> + <td><code>.png</code></td> + <td>fichier Portable Network Graphics</td> + <td><code>image/png</code></td> + </tr> + <tr> + <td><code>.pdf</code></td> + <td>Adobe Portable Document Format (PDF)</td> + <td><code>application/pdf</code></td> + </tr> + <tr> + <td><code>.ppt</code></td> + <td>présentation Microsoft PowerPoint</td> + <td><code>application/vnd.ms-powerpoint</code></td> + </tr> + <tr> + <td><code>.pptx</code></td> + <td>présentation Microsoft PowerPoint (OpenXML)</td> + <td><code>application/vnd.openxmlformats-officedocument.presentationml.presentation</code></td> + </tr> + <tr> + <td><code>.rar</code></td> + <td>archive RAR</td> + <td><code>application/x-rar-compressed</code></td> + </tr> + <tr> + <td><code>.rtf</code></td> + <td>Rich Text Format (RTF)</td> + <td><code>application/rtf</code></td> + </tr> + <tr> + <td><code>.sh</code></td> + <td>script shell</td> + <td><code>application/x-sh</code></td> + </tr> + <tr> + <td><code>.svg</code></td> + <td>fichier Scalable Vector Graphics (SVG)</td> + <td><code>image/svg+xml</code></td> + </tr> + <tr> + <td><code>.swf</code></td> + <td>fichier <a href="https://fr.wikipedia.org/wiki/Small_Web_Format">Small web format</a> (SWF) ou Adobe Flash</td> + <td><code>application/x-shockwave-flash</code></td> + </tr> + <tr> + <td><code>.tar</code></td> + <td>fichier d'archive Tape Archive (TAR)</td> + <td><code>application/x-tar</code></td> + </tr> + <tr> + <td><code>.tif<br> + .tiff</code></td> + <td>image au format Tagged Image File Format (TIFF)</td> + <td><code>image/tiff</code></td> + </tr> + <tr> + <td><code>.ts</code></td> + <td>fichier Typescript</td> + <td><code>application/typescript</code></td> + </tr> + <tr> + <td><code>.ttf</code></td> + <td>police TrueType</td> + <td><code>font/ttf</code></td> + </tr> + <tr> + <td><code>.vsd</code></td> + <td>Microsoft Visio</td> + <td><code>application/vnd.visio</code></td> + </tr> + <tr> + <td><code>.wav</code></td> + <td>Waveform Audio Format</td> + <td><code>audio/x-wav</code></td> + </tr> + <tr> + <td><code>.weba</code></td> + <td>fichier audio WEBM</td> + <td><code>audio/webm</code></td> + </tr> + <tr> + <td><code>.webm</code></td> + <td>fichier vidéo WEBM</td> + <td><code>video/webm</code></td> + </tr> + <tr> + <td><code>.webp</code></td> + <td>image WEBP</td> + <td><code>image/webp</code></td> + </tr> + <tr> + <td><code>.woff</code></td> + <td>police Web Open Font Format (WOFF)</td> + <td><code>font/woff</code></td> + </tr> + <tr> + <td><code>.woff2</code></td> + <td>police Web Open Font Format (WOFF)</td> + <td><code>font/woff2</code></td> + </tr> + <tr> + <td><code>.xhtml</code></td> + <td>XHTML</td> + <td><code>application/xhtml+xml</code></td> + </tr> + <tr> + <td><code>.xls</code></td> + <td>Microsoft Excel</td> + <td><code>application/vnd.ms-excel</code></td> + </tr> + <tr> + <td><code>.xlsx</code></td> + <td>Microsoft Excel (OpenXML)</td> + <td><code>application/vnd.openxmlformats-officedocument.spreadsheetml.sheet</code></td> + </tr> + <tr> + <td><code>.xml</code></td> + <td><code>XML</code></td> + <td><code>application/xml</code></td> + </tr> + <tr> + <td><code>.xul</code></td> + <td>XUL</td> + <td><code>application/vnd.mozilla.xul+xml</code></td> + </tr> + <tr> + <td><code>.zip</code></td> + <td>archive ZIP</td> + <td><code>application/zip</code></td> + </tr> + <tr> + <td><code>.3gp</code></td> + <td>conteneur audio/vidéo <a href="https://fr.wikipedia.org/wiki/3GP">3GPP</a></td> + <td><code>video/3gpp</code><br> + <code>audio/3gpp</code> dans le cas où le conteneur ne comprend pas de vidéo</td> + </tr> + <tr> + <td><code>.3g2</code></td> + <td>conteneur audio/vidéo <a href="https://fr.wikipedia.org/wiki/3GP">3GPP2</a></td> + <td><code>video/3gpp2</code><br> + <code>audio/3gpp2</code> dans le cas où le conteneur ne comprend pas de vidéo</td> + </tr> + <tr> + <td><code>.7z</code></td> + <td>archive <a href="https://fr.wikipedia.org/wiki/7-Zip">7-zip</a></td> + <td><code>application/x-7z-compressed</code></td> + </tr> + </tbody> +</table> diff --git a/files/fr/web/http/basics_of_http/mime_types/index.html b/files/fr/web/http/basics_of_http/mime_types/index.html new file mode 100644 index 0000000000..e114c7584f --- /dev/null +++ b/files/fr/web/http/basics_of_http/mime_types/index.html @@ -0,0 +1,318 @@ +--- +title: Types MIME +slug: Web/HTTP/Basics_of_HTTP/MIME_types +tags: + - Content-Type + - Guide + - HTTP + - Types MIME +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types +--- +<div>{{HTTPSidebar}}</div> + +<p>Le <strong>type Multipurpose Internet Mail Extensions (type MIME)</strong> est un standard permettant d'indiquer la nature et le format d'un document. Il est défini au sein de la <a href="https://tools.ietf.org/html/rfc6838">RFC 6838</a>. L'<a href="https://www.iana.org/">Internet Assigned Numbers Authority (IANA)</a> est l'organisme officiel responsable du suivi de l'ensemble des types MIME officiels existants. Une liste exhaustive et maintenue est consultable sur la <a href="https://www.iana.org/assignments/media-types/media-types.xhtml">page Media Types de l'IANA</a>.</p> + +<p>Les navigateurs utilisent le plus souvent le type MIME et non l'extension d'un fichier pour déterminer la façon dont ils vont traiter ou afficher un document. Il est donc important que les serveurs puissent correctement attacher le type MIME dans l'en-tête de la réponse qu'ils renvoient.</p> + +<h2 id="Syntaxe">Syntaxe</h2> + +<h3 id="Structure_générale">Structure générale</h3> + +<pre class="syntaxbox">type/sous-type</pre> + +<p>La structure d'un type MIME est simple, elle est composée d'un type et d'un sous-type. Les deux chaînes de caractères sont séparées par un <code>'/'</code>. Les caractères d'espacement ne sont pas autorisés. Le <em>type</em> représente la catégorie et peut être <em>particulier</em> ou <em>composé</em> lorsqu'il regroupe plusieurs formats. Le <em>sous-type</em> est spécifique à chaque type.</p> + +<p>Un type MIME est insensible à la casse mais il s'écrit usuellement en minuscule.</p> + +<h3 id="Types_particuliers">Types particuliers</h3> + +<pre class="syntaxbox">text/plain +text/html +image/jpeg +image/png +audio/mpeg +audio/ogg +audio/* +video/mp4 +application/octet-stream +…</pre> + +<p>Les types <em>particuliers</em> indiquent la catégorie d'un document. Les valeurs possibles sont :</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Type</th> + <th scope="col">Description</th> + <th scope="col">Exemple de sous-type communément associé</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>text</code></td> + <td>Représente n'importe quel document contenant du texte et qui est théoriquement lisible par un utilisateur.</td> + <td><code>text/plain</code>, <code>text/html</code>, <code>text/css, text/javascript</code></td> + </tr> + <tr> + <td><code>image</code></td> + <td>Représente n'importe quelle image. Les vidéos ne font pas partie de ce type bien que les images animées tels les GIFs animés) font partie de ce type.</td> + <td><code>image/gif</code>, <code>image/png</code>, <code>image/jpeg</code>, <code>image/bmp</code>, <code>image/webp</code></td> + </tr> + <tr> + <td><code>audio</code></td> + <td>Représente n'importe quel fichier audio.</td> + <td><code>audio/midi</code>, <code>audio/mpeg, audio/webm, audio/ogg, audio/wav</code></td> + </tr> + <tr> + <td><code>video</code></td> + <td>Représente n'importe quel fichier vidéo.</td> + <td><code>video/webm</code>, <code>video/ogg</code></td> + </tr> + <tr> + <td><code>application</code></td> + <td>Représente n'importe quelle donnée binaire.</td> + <td><code>application/octet-stream</code>, <code>application/pkcs12</code>, <code>application/vnd.mspowerpoint</code>, <code>application/xhtml+xml</code>, <code>application/xml</code>, <code>application/pdf</code></td> + </tr> + </tbody> +</table> + +<p><code>text/plain</code> doit être utilisé pour tous les documents texte sans sous-type spécifique. De la même façon, les documents binaires sans sous-type ou dont le sous-type est inconnu doivent utiliser <code>application/octet-stream</code>.</p> + +<h3 id="Types_composés_ou_multipart">Types composés ou <em>multipart</em></h3> + +<pre class="syntaxbox">multipart/form-data +multipart/byteranges</pre> + +<p id="sect1">Les types composés, aussi appelés types <em>multipart</em> indiquent une catégorie de document qui sont constitués de différents éléments. A l'exception de <code>multipart/form-data</code>, utilisé en association avec des <a href="/fr/docs/Web/Guide/HTML/Forms">formulaires HTML</a> et la méthode {{HTTPMethod("POST")}} et de <code>multipart/byteranges</code>, utilisé avec le statut HTTP {{HTTPStatus("206")}} <code>Partial Content</code> renvoyant uniquement une sous-partie du document ce qui entraînera vraisemblablement l'apparition d'une fenêtre "Enregistrer sous" étant donné que HTTP ne gère pas ces documents de manière différente et que le navigateur ne saura pas commment afficher ce document incomplet.</p> + +<h2 id="Types_MIME_utiles_pour_les_développeurs_web">Types MIME utiles pour les développeurs web</h2> + +<h3 id="applicationoctet-stream"><code>application/octet-stream</code></h3> + +<p>Il s'agit de la valeur par défaut pour un fichier binaire. Etant donné qu'il signifie <em>fichier binaire inconnu</em> il est probable que les navigateurs ne l'exécutent pas automatiquement et que l'utilisateur ne puisse pas l'exécuter directement dans le navigateur. Le comportement sera alors le même que si l'en-tête {{HTTPHeader("Content-Disposition")}} était présente avec la valeur <code>attachment</code> et proposera une invite "Enregistrer sous".</p> + +<h3 id="textplain"><code>text/plain</code></h3> + +<p>Il s'agit de la valeur par défaut pour les fichiers texte. Bien qu'il signifie fichier texte de format inconnu, les navigateurs prendront pour hypothèse qu'ils peuvent l'afficher.</p> + +<div class="note"> +<p>Il est important de noter que <code>text/plain</code> ne signifie pas <em>tous les formats de fichiers textuels</em>. Si le client s'attend à recevoir un format particulier de données textuelles, il est vraisemblable que le type <code>text/plain</code> ne soit pas considéré comme valide à la réception. Par exemple, si le client télécharge un fichier <code>text/plain</code> à partir d'un {{HTMLElement("link")}} déclarant des fichiers CSS, ce dernier ne sera pas considéré comme un CSS, le type MIME à utiliser étant <code>text/css</code>.</p> +</div> + +<h3 id="textcss"><code>text/css</code></h3> + +<p>N'importe quel fichier CSS qui doit être interprété comme pour servir une page web <strong> doit</strong> être de type <code>text/css</code>. Bien souvent, les serveurs ne sont pas en mesure de reconnaître les fichiers ayant l'extension <code>.css</code> comme étant des fichiers CSS, ces derniers sont donc transmis avec le type MIME <code>text/plain</code> ou <code>application/octet-stream</code>. Dès lors, les navigateurs ne les considèreront pas comme des fichiers CSS et ils seront ignorés. Il est donc important de servir les fichiers CSS à l'aide du type approprié.</p> + +<h3 id="texthtml"><code>text/html</code></h3> + +<p>L'ensemble du contenu HTML doit être renvoyé à l'aide de ce type. Les types MIME pour XHTML (comme <code>application/xml+html)</code> ne sont actuellement plus utilisés (HTML5 ayant unifié ces formats).</p> + +<h3 id="Formats_dimages">Formats d'images</h3> + +<p>Seuls quelques types MIME associés à des images sont largement reconnus et considérés comme pouvant être utilisé sans risque sur le Web, on peut donc directement les intégrer dans une page web :</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Type MIME</th> + <th scope="col">Format d'image</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>image/gif</code></td> + <td>images GIF (compression sans perte, remplacé par PNG)</td> + </tr> + <tr> + <td><code>image/jpeg</code></td> + <td>images JPEG</td> + </tr> + <tr> + <td><code>image/png</code></td> + <td>images PNG</td> + </tr> + <tr> + <td><code>image/svg+xml</code></td> + <td>images SVG (images vectorielles)</td> + </tr> + </tbody> +</table> + +<p>Il y a un débat quant à l'ajout de WebP (<code>image/webp</code>) à cette liste. En effet l'ajout d'un nouveau format mènerait à une augmentation du nombre de cas à gérer et pourrait introduire des problématiques de sécurité, pour ces raisons les constructeurs de navigateurs font preuve de précaution avant de l'intégrer.</p> + +<p>D'autres formats d'images peuvent constituer un document web. Par exemple, la plupart des navigateurs web supportent les types des images favicon, le format ICO étant pris en charge à l'aide du type MIME <code>image/x-icon</code>.</p> + +<h3 id="Formats_audios_et_vidéos">Formats audios et vidéos</h3> + +<p>Comme pour les images, HTML ne définit pas de liste de formats supportés pour les éléments {{HTMLElement("audio")}} et {{HTMLElement("video")}}. Dès lors, seul un ensemble restreint de formats est en mesure d'être utilisé sur le Web. La page <a href="/fr/docs/Web/HTML/Supported_media_formats">Formats pris en charge par les balises audio et video</a> détaille les codecs et les formats qui peuvent être employés.</p> + +<p>Le format MIME de ces fichiers représente généralement le format du conteneur contenant le fichier. Dans le cas du Web, les formats les plus courants sont :</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Type MIME</th> + <th scope="col">Format audio et vidéo</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>audio/wave</code><br> + <code>audio/wav</code><br> + <code>audio/x-wav</code><br> + <code>audio/x-pn-wav</code></td> + <td>Un fichier audio WAVE. Le codec audio PCM (WAVE codec "1") est souvent pris en charge tandis que les autres codecs offrent une prise en charge moindre (lorsqu'elle existe).</td> + </tr> + <tr> + <td><code>audio/webm</code></td> + <td>Un fichier audio WebM. Les codecs les plus fréquemment associés sont Vorbis et Opus.</td> + </tr> + <tr> + <td><code>video/webm</code></td> + <td>Un fichier vidéo, pouvant contenir de l'audio, au format WebM. Les codecs vidéos VP8 et VP9 sont les plus communs tandis que Vorbis and Opus constituent les codecs audios les plus fréquents.</td> + </tr> + <tr> + <td><code>audio/ogg</code></td> + <td>Un fichier audio au format OGG. Vorbis est le codec audio le plus utilisé pour traiter ce genre de format conteneur.</td> + </tr> + <tr> + <td><code>video/ogg</code></td> + <td>Un fichier vidéo, pouvant contenir de l'audio, au format OGG. Theora est le codec vidéo habituel pour ce genre de conteneur tandis que Vorbis est utilisé pour l'audio.</td> + </tr> + <tr> + <td> + <p><code>application/ogg</code></p> + </td> + <td> + <p>Un fichier audio ou vidéo au format OGG. Theora et Vorbis constituent respectivement les codecs vidéo et audio souvent utilisés.</p> + </td> + </tr> + </tbody> +</table> + +<h3 id="multipartform-data"><code>multipart/form-data</code></h3> + +<p>Le type <code>multipart/form-data</code> peut être utilisé lors de l'envoi du contenu d'un <a href="/fr/docs/Web/Guide/HTML/Forms">formulaire HTML</a> du navigateur vers le serveur. En tant que document composé ou <em>multipart</em> il est constitué de différentes parties délimitées par une frontière (une chaîne de caractères débutant par un tiret double <code>'--'</code>). Chaque partie est une entité propre qui possède ses propres en-têtes {{HTTPHeader("Content-Disposition")}} et {{HTTPHeader("Content-Type")}} lorsqu'il s'agit d'un champ permettant de téléverser un fichier. L'en-tête ({{HTTPHeader("Content-Length")}} est ignorée puisque la limite est assurée par la frontière.</p> + +<pre class="syntaxbox">Content-Type: multipart/form-data; boundary=aChaineDeDélimitation +(en-têtes divers associés à l'ensemble du document) + +--aChaineDeDélimitation +Content-Disposition: form-data; name="monFichier"; filename="img.jpg" +Content-Type: image/jpeg + +(données) +--aChaineDeDélimitation +Content-Disposition: form-data; name="monChamp" + +(données) +--aChaineDeDélimitation +(éléments additionnels) +--aChaineDeDélimitation-- + +</pre> + +<p>Le formulaire suivant :</p> + +<pre class="brush: html"><form action="http://localhost:8000/" method="post" enctype="multipart/form-data"> + <input type="text" name="monChampTexte"> + <input type="checkbox" name="maCheckBox">Check</input> + <input type="file" name="monFichier"> + <button>Envoyer le fichier</button> +</form></pre> + +<p>enverra le message suivant :</p> + +<pre>POST / HTTP/1.1 +Host: localhost:8000 +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate +Connection: keep-alive +Upgrade-Insecure-Requests: 1 +Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498 +Content-Length: 465 + +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="monChampTexte" + +Test +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="maCheckBox" + +sur +-----------------------------8721656041911415653955004498 +Content-Disposition: form-data; name="monFichier"; filename="test.txt" +Content-Type: text/plain + +un fichier simple. +-----------------------------8721656041911415653955004498-- + +</pre> + +<h3 id="multipartbyteranges"><code>multipart/byteranges</code></h3> + +<p>Le type MIME <code>multipart/byteranges</code> est utilisé lors qu'il s'agit d'envoyer une réponse partielle au navigateur. Lorsque le statut {{HTTPStatus("206")}} <code>Partial Content</code> est envoyé, ce type MIME sert pour indiquer que le document est constitué de plusieurs parties. Comme les types composés, l'en-tête {{HTTPHeader("Content-Type")}} utilise la directive <code>boundary</code> pour définir une chaîne de délimitation. Chaque partie possède son en-tête {{HTTPHeader("Content-Type")}} ainsi que {{HTTPHeader("Content-Range")}} qui spécifie le morceau que cette partie représente.</p> + +<pre><code>HTTP/1.1 206 Partial Content +Accept-Ranges: bytes +Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5 +Content-Length: 385 + +--3d6b6a416f9b5 +Content-Type: text/html +Content-Range: bytes 100-200/1270 + +eta http-equiv="Content-type" content="text/html; charset=utf-8" /> + <meta name="vieport" content +--3d6b6a416f9b5 +Content-Type: text/html +Content-Range: bytes 300-400/1270 + +-color: #f0f0f2; + margin: 0; + padding: 0; + font-family: "Open Sans", "Helvetica +--3d6b6a416f9b5--</code></pre> + +<h2 id="De_limportance_de_définir_correctement_un_type_MIME">De l'importance de définir correctement un type MIME</h2> + +<p>La plupart des serveurs envoient des ressources de format inconnu et donc utilisent le type par défaut <code>application/octet-stream</code>. Pour des considérations de sécurité, les navigateurs n'effectuent pas d'action par défaut pour les ressources de ce type, ce qui oblige l'utilisateur à stocker le fichier sur son dique pour l'utiliser. Voici les erreurs communes de configuration côté serveur pour les formats suivants :</p> + +<ul> + <li> + <p>Les fichiers RAR. Idéalement il faudrait définir le type MIME associé aux fichiers contenus. Ce n'est généralement pas possible étant donné que le type de ces fichiers est vraisemblablement inconnu du serveur, d'autre part, il est possible que plusieurs formats soient présents dans le fichier RAR. On pourra alors configurer le serveur pour envoyer le type MIME <code>application/x-rar-compressed</code> bien qu'il soit probable qu'aucune action par défaut pour ce type MIME n'ait été définie côté utilisateur.</p> + </li> + <li> + <p>Fichiers audios et vidéos. Seules les ressources associées à un type MIME approprié seront reconnues et lues dans les éléments {{ HTMLElement("video")}} ou {{HTMLElement("audio")}}. Vérifiez que vous utilisez <a href="/fr/docs/Web/HTML/Supported_media_formats">un format correct pour les fichiers audios et vidéos</a>.</p> + </li> + <li> + <p>Les fichiers au format propriétaire. Il est nécessaire d'être vigilent lorsque l'on sert des fichiers propriétaires. Evitez autant que possible l'utilisation de <code>application/octet-stream</code> puisque ce type générique ne permet pas une gestion appropriée de la ressource.</p> + </li> +</ul> + +<h2 id="Détection_de_type_MIME">Détection de type MIME</h2> + +<p>Lorsque le type MIME est absent ou lorsque le client détecte que le type MIME a été mal associé, les navigateurs peuvent pratiquer la détection de type MIME via l'analyse de la ressource. Chaque navigateur implémente cette technique différemment et l'utilise dans des contextes différents. Il existe des problématiques de sécurité, étant donné que certaines ressources sont des fichiers exécutables et d'autres non. Les serveurs peuvent empêcher la détection de type MIME par le navigateur en envoyant l'en-tête {{HTTPHeader("X-Content-Type-Options")}} associé à {{HTTPHeader("Content-Type")}}.</p> + +<h2 id="Autres_méthodes_pour_transporter_le_format_dun_document">Autres méthodes pour transporter le format d'un document</h2> + +<p>Les types MIME ne sont pas la seule façon existante pour gérer le format d'un document :</p> + +<ul> + <li>Les extensions de fichiers sont parfois utilisées, comme sur les systèmes d'exploitation Microsoft Windows. Tous les systèmes d'exploitation ne considèrent pas l'extension comme signifiante (en particulier Linux et Mac OS). De la même manière que pour les types MIME externes, il n'est pas garanti que le contenu soit effectivement du type correspondant à l'extension du document.</li> + <li>Nombres magiques : La syntaxe de différents fichiers permet de déterminer le fichier en analysant son contenu, ainsi les fichiers GIF commencent par les valeurs hexadécimales 47 49 46 38 soit [GIF89], les fichiers PNG quant à eux commencent par 89 50 4E 47 soit [.PNG]. Néanmoins, tous les types de fichiers ne permettent pas d'utiliser des nombres magiques, il ne s'agit donc pas d'une technique infaillible.</li> +</ul> + +<h2 id="Voir_aussi">Voir aussi</h2> + +<ul> + <li><a href="/fr/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types">Configurer proprement les types MIME côté serveur</a></li> + <li> + <p><a href="/fr/docs/Web/HTML/Supported_media_formats">Formats multimédias supportés pour les éléments HTML audio et vidéo</a></p> + </li> + <li> + <p><a href="https://www.iana.org/assignments/media-types/application/json">https://www.iana.org/assignments/media-types/application/json</a></p> + </li> +</ul> diff --git a/files/fr/web/http/basics_of_http/urls_de_type_ressource/index.html b/files/fr/web/http/basics_of_http/urls_de_type_ressource/index.html new file mode 100644 index 0000000000..4f38214e57 --- /dev/null +++ b/files/fr/web/http/basics_of_http/urls_de_type_ressource/index.html @@ -0,0 +1,67 @@ +--- +title: URLs de type ressource +slug: Web/HTTP/Basics_of_HTTP/URLs_de_type_ressource +tags: + - Guide + - HTTP + - Intermédiaire + - Ressource +translation_of: Web/HTTP/Basics_of_HTTP/Resource_URLs +--- +<div>{{HTTPSidebar}}</div> + +<p>Les URLs de type ressource sont les URLs préfixées à l'aide du schéma <code>resource:</code>. Elles sont utilisées par Firefox ainsi que les modules complémentaires pour charger des ressources de manière interne, néanmoins, certaines informations associées sont disponibles pour les sites auxquels le navigateur accède.</p> + +<h2 id="Syntaxe">Syntaxe</h2> + +<p>Les URLs de type ressource sont composées de deux parties, un préfixe (<code>resource:</code>) et l'URL qui dirige vers la ressource que l'on souhaite charger :</p> + +<pre class="syntaxbox">resource://<url></pre> + +<p>Voici un exemple :</p> + +<pre>resource://gre/res/svg.css</pre> + +<p>Pour plus de détails, vous pouvez consulter <a href="/fr/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identifier des ressources sur le Web</a>.</p> + +<p>Dans cet article, nous abordons les URIs ressources qui sont utilisées par Firefox pour pointer vers des ressources internes.</p> + +<h2 id="Menaces">Menaces</h2> + +<p>Étant donné que les informations partagées par les URLs <code>resource:</code> sont accessibles par les sites web, une page web pourrait être en mesure d'exécuter un script pour inspecter les ressources internes à Firefox telles que les préférences par défaut, ce qui pourrait constituer un problème important de confidentialité et de sécurité.</p> + +<p>Par exemple, <a href="https://www.browserleaks.com/firefox">ce script sur Browserleaks</a> détaille les éléments accessibles de Firefox lorsque l'on appelle l'URL ressource. Le code de ce script est accessible à l'adresse <a href="https://browserleaks.com/firefox#more">https://browserleaks.com/firefox#more</a>.</p> + +<p>Le fichier <a href="https://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/browser/app/profile/firefox.js#575">firefox.js</a> passe les noms des préférences et leurs valeurs à la fonction <code>pref()</code>.</p> + +<p>Les sites web peuvent aisément récupérer les préférences par défaut de Firefox en contournant la fonction <code>pref()</code> et en utilisant le script <code>resource:///defaults/preferences/firefox.js</code>.</p> + +<p>De plus, certaines valeurs par défaut diffèrent selon les versions ou les installations, parmi lesquelles le système d'exploitation ou la langue d'utilisation, il est donc possible d'identifier les utilisateurs de manière distincte.</p> + +<h2 id="Solution">Solution</h2> + +<p>Afin de résoudre ce problème, Mozilla a modifié le comportement du chargement des URLs ressource via {{bug(863246)}}, rendu disponible à partir de Firefox 57 (Quantum).</p> + +<p>Auparavant, les sites web étaient capables d'accéder à n'importe quelle URI <code>resource:</code>, celles de Firefox mais aussi celles des modules complémentaires. Ce comportement est désormais interdit par défaut.</p> + +<p>Firefox nécessite néanmoins le chargement des ressources au sein d'un contenu web dans certains cas. Ainsi lorsque l'on souhaite accéder au code source d'une page à l'aide de "Code source de la page", un appel à <code>viewsource.css</code> via une URI <code>resource:</code> est nécessaire. Les ressources auxquelles le contenu web a besoin d'accéder ont été déplacées sous <code>resource://content-accessible/</code>, une partie isolée et ne contenant que des ressources n'étant pas confidentielles. De cette manière, il est possible d'exposer des ressources tout en réduisant la plupart des menaces.</p> + +<div class="note"> +<p><strong>Note</strong> : Il est recommandé de ne plus utiliser les URLs de type ressource lors du développement web ou de celui d'un module. Leur utilisation était peu fiable et la plupart ne fonctionnent plus.</p> +</div> + +<h2 id="Spécifications">Spécifications</h2> + +<p><code>resource:</code> n'est pas défini dans une spécification RFC.</p> + +<h2 id="Compatibilité_des_navigateurs">Compatibilité des navigateurs</h2> + +<p>resource: est disponible uniquement dans Firefox.</p> + +<h2 id="Voir_aussi">Voir aussi</h2> + +<ul> + <li><a href="/fr/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identifier des ressources sur le Web</a></li> + <li><a href="/fr/docs/Learn/Common_questions/What_is_a_URL">Qu'est-ce qu'une URL ?</a></li> + <li><a href="https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">Liste des schémas URI maintenue par l'IANA</a> (<code>resource:</code> est <a href="https://www.iana.org/assignments/uri-schemes/prov/resource">définie ici</a>)</li> +</ul> |