From: Lucien Gentis Date: Tue, 30 Jun 2026 16:03:48 +0000 (+0000) Subject: fr doc XML files updates. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a6cbbb5c79f5b63d64accebd6a2b57164af3952f;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML files updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1935750 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/http2.xml.fr b/docs/manual/howto/http2.xml.fr index bbf13fc6f7..25e841ec34 100644 --- a/docs/manual/howto/http2.xml.fr +++ b/docs/manual/howto/http2.xml.fr @@ -1,7 +1,7 @@ - + @@ -43,49 +43,48 @@ plus efficace des ressources réseau. Il ne modifie pas les aspects fondamentaux de HTTP (sa sémantique). Entre autres, il y a toujours des requêtes, des réponses et des en-têtes. Par conséquent, si vous connaissez - HTTP/1, vous connaissez déjà 95% de HTTP/2.

-

Beaucoup a déjà été écrit à propos de HTTP/2 et de son fonctionnement. La - documentation la plus officielle est bien entendu sa 7540 (ou cette version au format plus - lisible : YMMV (7540). Vous trouverez ici une description des rouages de HTTP/2 dans - leurs moindres détails.

-

Le premier document à lire lorsqu'on ne connaît pas un mécanisme n'est - cependant pas sa RFC. Il est préférable de comprendre tout d'abord ce - que ce mécanisme est censé faire, et seulement ensuite de lire sa RFC - pour comprendre comment il fonctionne. http2 explained de Daniel Stenberg - (l'auteur de curl) - est un bien meilleur document pour démarrer l'étude de HTTP/2. En outre, de - nouveaux langages s'ajoutent régulièrement à sa liste de traductions - disponibles !

-

Si vous n'avez pas envie de le lire parce que vous le trouvez trop long, - voici certains pièges à éviter et nouveaux termes à connaître avant de lire - ce document :

+ HTTP/1, vous connaissez déjà 95% deHTTP/2.

+ +

Le protocole est définii dans la 9113 (qui rend obsolète la + 7540 originale). Pour une approche plus abordable, voir le + document http2 explained par Daniel + Stenberg, l’auteur de curl. Il couvre les + but et conception de HTTP/2 sans nécessiter d’analyse de la notation RFC + préalable.

+ +

En bref, il y a quelques nouveaux termes et pièges à éviter que vous + devez garder à l’esprit lors de la lecture de ce document :

+ @@ -93,14 +92,15 @@ HTTP/2 dans Apache httpd

Le protocole HTTP/2 est implémenté dans Apache httpd via un module propre, pertinemment nommé mod_http2. Ce - module implémente toutes les fonctionnalités décrites par la RFC 7540 et + module implémente toutes les fonctionnalités décrites par la RFC 9113 et supporte les connexions en texte pur (http:), ou sécurisées (https:). La variante texte pur se nomme 'h2c', et la variante sécurisée 'h2'. h2c peut être en mode direct ou Upgrade: via une requête initiale en HTTP/1.

-

Server Push est une nouvelle fonctionnalité offerte - aux développeurs web par HTTP/2. La section correspondante de ce document - vous indiquera comment votre application peut en tirer parti.

+

Server Push était une nouvelle fonctionnalité offerte + aux développeurs web par HTTP/2, mais elle est maintenant obsolète. Voir la + section EarlyHints pour l’alternative + recommandée.

@@ -135,36 +135,43 @@

Maintenant que vous disposez d'un binaire httpd compilé avec le module mod_http2, l'activation de ce dernier nécessite un minimum de configuration supplémentaire. En premier lieu, comme pour tout - module Apache, vous devez le charger :

- + module de httpd, vous devez le charger :

+ + LoadModule http2_module modules/mod_http2.so - + +

La seconde directive que vous devez ajouter à votre fichier de configuration est

- + + Protocols h2 http/1.1 +

Ceci permet de définir h2, la variante sécurisée, comme le protocole préféré pour les connexions à votre serveur. Si vous souhaitez que toutes les variantes soient disponibles, utilisez la directive suivante :

- + + Protocols h2 h2c http/1.1 -

Selon l'endroit où vous placez cette directive, elle affectera l'ensemble - de votre serveur, ou seulement un ou plusieurs serveurs virtuels. Vous + +

Selon l'endroit où vous placez cette directive, elle affectera toute les + connexions, ou seulement celles vers un serveur virtuel spécifique. Vous pouvez aussi l'imbriquer comme dans l'exemple suivant :

- + + Protocols http/1.1 <VirtualHost ...> - ServerName test.example.org - Protocols h2 http/1.1 +ServerName test.example.org +Protocols h2 http/1.1 </VirtualHost> + -

Seules les connexions en HTTP/1 seront alors permises, sauf pour le serveur - virtuel test.example.org qui acceptera aussi les connexions SSL - en HTTP/2.

+

Seules les connexions en HTTP/1 seront alors permises, sauf pour les + connexions SSL vers test.example.org qui propose aussi HTTP/2.

Utilisez une chaîne d'algorithmes de chiffrement forte

La directive SSLCipherSuite doit être définie avec une chaîne d'algorithmes de chiffrement TLS forte. Même si @@ -182,25 +189,32 @@ Protocols http/1.1

L'ordre des protocoles indiqués est aussi important. Par défaut, le premier sera le protocole préféré. Lorsqu'un client offre plusieurs choix, c'est le plus à gauche qui sera sélectionné. Dans

- + + Protocols http/1.1 h2 +

le protocole préféré sera HTTP/1 et il sera toujours sélectionné sauf si un client ne supporte que h2. Comme nous souhaitons communiquer en HTTP/2 avec les clients qui le supportent, la meilleure définition de la directive est

- + + Protocols h2 h2c http/1.1 +

Toujours à propos de l'ordre des protocoles, le client a lui aussi ses propres préférences en la matière. À ce titre, si vous le souhaitez, vous pouvez configurer votre serveur pour qu'il sélectionne non plus son protocole préféré, mais au contraire le protocole préféré du client :

- + + ProtocolsHonorOrder Off - + + +

Avec cette directive, l'ordre des protocoles que vous avez défini devient caduque et seul l'ordre défini par le client sera pris en compte.

@@ -248,11 +262,10 @@ ProtocolsHonorOrder Off
Clients -

La plupart des navigateurs modernes supportent HTTP/2, mais seulement sur - des connexions SSL : Firefox v43, Chrome v45, Safari v9, iOS Safari v9, - Opera v35, Chrome pour Android v49 et - Internet Explorer v11 sous Windows10 (selon cette source).

+

Tous les navigateurs modernes prennent en charge HTTP/2 sur + des connexions TLS (source). La + prise en charge est devenue universelle sur les navigateurs principaux à peu + près en 2015.

D'autres clients et serveurs sont listés dans le wiki des implémentations ; entre autres des implémentations pour c, c++, common @@ -268,14 +281,19 @@ ProtocolsHonorOrder Off

Le premier d'entre eux est bien entendu curl. Assurez-vous au préalable que votre version supporte HTTP/2 en vérifiant ses Fonctionnalités :

- - $ curl -V - curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4 - Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] - Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 - - homebrew sous Mac OS : - brew install curl --with-openssl --with-nghttp2 + + +$ curl -V +curl 8.20.0 (x86_64-pc-linux-gnu) libcurl/8.20.0 OpenSSL/3.5.7 zlib/1.3.1 nghttp2/1.69.0 +Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] +Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 + + + Notes à propos de macOS Homebrew +

curl de Homebrew inclut par défaut la prise en charge de + HTTP/2. Installez le avec la commande brew install curl et + suivez les instructions affichées pour le mettre en tête du PATH de votre + système.

Pour une inspection en profondeur : wireshark.

Le paquet nghttp2 inclut aussi des @@ -290,15 +308,22 @@ ProtocolsHonorOrder Off

Chrome fournit des journaux détaillés des connexions HTTP/2 via la page special net-internals page. Il y - a aussi cette extension intéressante pour Chrome + a aussi cette extension intéressante pour Chrome et Firefox + href="https://addons.mozilla.org/en-us/firefox/addon/http2-indicator/">Firefox qui permet d'indiquer que votre navigateur utilise HTTP/2.

Push serveur + Notification d’obsolescence +

Server Push est obsolète dans la 9113. Les + navigateurs principaux (Chrome 106+, Edge 106+) ont supprimé sa prise en + charge. Bien que mod_http2 implémente encore push, les + nouveaux déploiements doivent utiliser 103 Early + Hints à titre de méthode plus fiable pour informer les clients à propos + des ressources nécessaires.

+

Le protocole HTTP/2 permet au serveur de proposer (PUSH) des réponses pour lesquelles le client n'a rien demandé. La communication autour de ces réponses est du style : "voici une requête que vous n'avez jamais @@ -323,29 +348,37 @@ ProtocolsHonorOrder Off procéder vous-même à ces expérimentations :

mod_http2 inspecte l'en-tête de la réponse et recherche les en-têtes Link sous un certain format :

- + + Link </xxx.css>;rel=preload, </xxx.js>; rel=preload - + +

Si la connexion supporte PUSH, ces deux ressources seront envoyées au client. En tant que développeur web vous pouvez définir ces en-têtes soit directement au niveau de la réponse de votre application, soit en configurant votre serveur via

- + + <Location /xxx.html> - Header add Link "</xxx.css>;rel=preload" - Header add Link "</xxx.js>;rel=preload" +Header add Link "</xxx.css>;rel=preload" +Header add Link "</xxx.js>;rel=preload" </Location> - + +

Si vous souhaitez utiliser des liens preload sans déclencher de PUSH, vous pouvez utiliser le paramètre nopush comme suit :

- + + Link </xxx.css>;rel=preload;nopush - + +

Vous pouvez aussi désactiver les PUSHes pour l'ensemble de votre serveur via la directive

- + + H2Push Off - + +

À savoir aussi :

Le module maintient un journal des ressources ayant fait l'objet d'un PUSH pour chaque connexion (en général des condensés hash des URLs), et @@ -353,14 +386,13 @@ H2Push Off lorsque la connexion est fermée, le journal de ses PUSHes est supprimé.

Certains développeurs planchent sur la manière de permettre au client d'informer le serveur des ressources qu'il possède déjà dans son cache afin - d'éviter les PUSHes pour ces dernières, mais ceci n'en est actuellement qu'à - un stade très expérimental.

+ d'éviter les PUSHes pour ces dernières, mais aucune norme n’a émergé avant + que push ne devienne obsolète.

L' - en-tête Accept-Push-Policy est un autre dispositif expérimental + en-tête Accept-Push-Policy est un dispositif expérimental implémenté dans mod_http2 ; il permet au client de définir pour - chaque requête quels genres de PUSHes il accepte.

- - + chaque requête quels genres de PUSHes il accepte. Ce dispositif a été + abandonné et n’a jamais été adopté.

La fonctionnalité PUSH n'apportera pas toujours le gain de performances dans l'obtention de réponses aux requêtes. Vous trouverez plusieurs études sur ce @@ -385,27 +417,31 @@ H2Push Off

- Suggestions précoces + EarlyHints

A l'instar des ressources PUSHées, une autre méthode consiste à envoyer des en-têtes Link au client avant même que la réponse ne soit prête. Cette méthode utilise la fonctionnalité appelée "Suggestions précoces" (Early Hints) décrite dans la 8297.

Pour utiliser cette fonctionnalité, vous devez l'activer explicitement sur le serveur via :

- + + H2EarlyHints on - + +

Elle n'est en effet pas activée par défaut car certains navigateurs anciens perdent pied avec de telles réponses.

Une fois cette fonctionnalité activée, vous pouvez utiliser la directive H2PushResource pour déclencher les suggestions précoces et les PUSHes de ressources :

- + + <Location /xxx.html> - H2PushResource /xxx.css - H2PushResource /xxx.js +H2PushResource /xxx.css +H2PushResource /xxx.js </Location> - + +

Le serveur enverra alors au client une réponse "103 Early Hints" dès qu'il commencera à traiter la requête. Selon votre application web, cet envoi peut intervenir beaucoup plus tôt que le diff --git a/docs/manual/howto/public_html.xml.fr b/docs/manual/howto/public_html.xml.fr index 40bdcccc41..b32d9db513 100644 --- a/docs/manual/howto/public_html.xml.fr +++ b/docs/manual/howto/public_html.xml.fr @@ -1,7 +1,7 @@ - + @@ -35,19 +35,28 @@ visiteurs de l'URL http://example.com/~nom_utilisateur/ recevront un contenu situé dans le répertoire home de l'utilisateur "nom_utilisateur", et dans le sous-répertoire spécifié par la directive UserDir.

-

Notez que par défaut, l'accès à ces répertoires n'est +

Par défaut, l'accès à ces répertoires n'est pas permis. Vous pouvez en permettre l'accès à l'aide de la directive UserDir en décommentant la ligne :

- - #Include conf/extra/httpd-userdir.conf - + + +#Include conf/extra/httpd-userdir.conf + +

dans le fichier de configuration par défaut conf/httpd.conf, et en adaptant le fichier httpd-userdir.conf selon vos besoins, ou en incluant les directives appropriées dans une section Directory du fichier de configuration principal.

+ + Les distributions tierces de httpd (fournies par le fabricant de votre + OS ou par le gestionnaire de paquets) placent souvent la configuration de + mod_userdir dans un fichier séparé, et peuvent l’activer + par défaut. Consultez la documentation de votre distribution pour les + spécificités. Les exemples de ce document présupposent une construction par + défaut à partir des sources de httpd. Mise en correspondance des URLs @@ -79,7 +88,11 @@ avec le système de fichiers interprété comme chemin relatif au répertoire home de l'utilisateur considéré. Par exemple, avec cette configuration :

- UserDir public_html + + +UserDir public_html + +

l'URL http://example.com/~rbowen/fichier.html correspondra au chemin fichier @@ -89,8 +102,11 @@ avec le système de fichiers sera construit en utilisant ce chemin, suivi du nom de l'utilisateur considéré. Par exemple, avec cette configuration :

- UserDir /var/html - + + +UserDir /var/html + +

l'URL http://example.com/~rbowen/fichier.html correspondra au chemin fichier /var/html/rbowen/fichier.html

@@ -99,7 +115,11 @@ avec le système de fichiers remplacé par le nom de l'utilisateur dans le chemin du fichier correspondant. Par exemple, avec cette configuration :

- UserDir /var/www/*/docs + + +UserDir /var/www/*/docs + +

l'URL http://example.com/~rbowen/fichier.html correspondra au chemin fichier @@ -108,13 +128,17 @@ avec le système de fichiers

On peut aussi définir plusieurs répertoires ou chemins de répertoires.

- UserDir public_html /var/html + + +UserDir public_html /var/html + + -

Avec l'URL http://example.com/~rbowen/fichier.html, - Apache va rechercher ~rbowen. S'il ne le trouve pas, - Apache va rechercher rbowen dans - /var/html. S'il le trouve, l'URL ci-dessus correspondra - au chemin fichier /var/html/rbowen/file.html

+

Les arguments sont pris en compte selon l’ordre dans lequel ils + apparaissent. Pour l’URL http://example.com/~rbowen/file.html, + httpd recherchera d’abord ~rbowen. Si ce dernier n’est pas + trouvé, httpd cherchera rbowen dans /var/html. Le + fichier sera servi depuis le premier emplacement trouvé.

@@ -124,7 +148,11 @@ avec le système de fichiers module="mod_userdir">UserDir pour rediriger les requêtes relatives aux répertoires utilisateurs vers des URLs externes.

- UserDir http://example.org/users/*/ + + +UserDir http://example.org/users/*/ + +

L'exemple ci-dessus va rediriger une requête pour http://example.com/~bob/abc.html vers @@ -139,7 +167,11 @@ avec le système de fichiers vous pouvez définir quels utilisateurs sont autorisés à utiliser cette fonctionnalité :

- UserDir disabled root jro fish + + +UserDir disabled root jro fish + +

La configuration ci-dessus va autoriser l'utilisation de la fonctionnalité pour tous les utilisateurs, à l'exception de ceux @@ -148,11 +180,12 @@ avec le système de fichiers utilisateurs sauf certains d'entre eux en utilisant une configuration du style :

- + + UserDir disabled UserDir enabled rbowen krietz - - + +

Vous trouverez d'autres exemples dans la documentation de UserDir.

@@ -166,13 +199,14 @@ UserDir enabled rbowen krietz type="section">Directory pour activer CGI dans un sous-répertoire particulier d'un répertoire home utilisateur.

- + + <Directory "/home/*/public_html/cgi-bin/"> - Options ExecCGI - SetHandler cgi-script +Options ExecCGI +SetHandler cgi-script </Directory> - - + +

Avec la configuration ci-dessus, et en supposant que UserDir est défini à public_html, un programme CGI exemple.cgi pourra être chargé depuis ce