From 9eb9180e9c9c0105ae11ce05e3593438366704c0 Mon Sep 17 00:00:00 2001 From: Lucien Gentis Date: Sun, 21 Aug 2016 11:43:53 +0000 Subject: [PATCH] Rebuild. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1757050 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/core.html.fr | 96 ++++++++++++++++++++++++++-- docs/manual/mod/core.xml.meta | 2 +- docs/manual/mod/mod_alias.html.fr | 34 +++++----- docs/manual/mod/mod_alias.xml.meta | 2 +- docs/manual/mod/mod_rewrite.html.fr | 6 +- docs/manual/mod/mod_rewrite.xml.meta | 2 +- 6 files changed, 110 insertions(+), 32 deletions(-) diff --git a/docs/manual/mod/core.html.fr b/docs/manual/mod/core.html.fr index 03c1a5fbd4..d059727788 100644 --- a/docs/manual/mod/core.html.fr +++ b/docs/manual/mod/core.html.fr @@ -33,8 +33,6 @@  ja  |  tr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
Description:Fonctionnalités de base du serveur HTTP Apache toujours disponibles
Statut:Core
@@ -2174,7 +2172,7 @@ clients
top

Directive HttpProtocolOptions

- + @@ -2183,10 +2181,94 @@ LenientMethods Allow0.9 - -
Description:Modify restrictions on HTTP Request Messages
Description:Modifie les contraintes sur les messages des requêtes HTTP
Syntaxe:HttpProtocolOptions [Strict|Unsafe] [StrictURL|UnsafeURL] [StrictWhitespace|LenientWhitespace] [RegisteredMethods|LenientMethods] [Allow0.9|Require1.0]
Contexte:configuration du serveur, serveur virtuel
Statut:Core
Module:core
Compatibilité:2.2.32 or 2.4.24 and later

La documentation de cette directive - n'a pas encore t traduite. Veuillez vous reporter la version - en langue anglaise.

+Compatibilité:Disponible à partir des versions 2.2.32 et 2.4.24 du serveur HTTP +Apache + +

Cette directive permet de modifier les règles qui s'appliquent à la ligne + de requête HTTP (RFC 7230 + §3.1.1) et aux champs des en-têtes des requêtes HTTP (RFC 7230 + §3.2), qui s'appliquent maintenant par défaut ou en utilisant + l'option Strict. Les options Unsafe et + UnsafeURL ont été ajoutées pour pouvoir restaurer les anciens + comportements nécessaires aux anciens modules et applications et aux agents + utilisateurs personnalisés considérés comme obsolètes. Ces règles + s'appliquant avant le traitement de la requête, elles doivent, pour être prises en + compte, être définies + au niveau global ou dans la première section par défaut du serveur virtuel + qui correspond à la requête considérée, par interface IP/port et non par + nom.

+ +

Avant l'introduction de cette directive, les interpréteurs de requêtes du + serveur HTTP Apache toléraient un grand nombre de formats en entrée qui + n'étaient pas forcément conformes au protocole. RFC 7230 §9.4 + Request Splitting et §9.5 Response + Smuggling ne rappellent que deux des risques potentiels induits par des + requêtes non conformes. Avec l'introduction de cette directive, toutes les + règles de grammaire de la spécification doivent être respectées dans le mode + d'opérations par défaut Strict.

+ +

RFC 7230 + §2.2 and 2.3 définit les "Caractères réservés" ainsi que les + "Caractères non réservés". Tous les autres caractères doivent être encodés + sous la forme %XX selon la spécification, et la RFC7230 se conforme à ces + instructions. Par défaut, l'option StrictURI rejète toutes les + requêtes contenant des caractères non valides. Cette règle peut être + contournée en utilisant l'option UnsafeURI qui permet de + supporter les agents utilisateur mal conçus.

+ +

Il est fortement déconseillé aux utilisateurs d'utiliser les modes + d'opérations Unsafe et UnsafeURI, en particulier + pour les déploiements de serveurs ouverts sur l'extérieur et/ou accessibles + au public. Si un moniteur défectueux ou autre logiciel spécialisé ne + s'exécutant que sur un intranet nécessite une interface, les utilisateurs + ne doivent les utilisés qu'au sein d'un serveur virtuel bien spécifique et + sur un réseau privé.

+ +

La consultation des messages enregistrés dans le journal + ErrorLog, configuré via la directive + LogLevel avec un niveau info, pourra + vous aider à identifier de telles requêtes non conformes ainsi que leur + provenance. Les utilisateurs devront accorder une attention particulière aux + messages d'erreur de type 400 dans le journal access pour détecter les + requêtes apparemment valides mais rejetées.

+ +

La section de la RFC 7230 + §3.5 "Message Parsing Robustness" décrit les risques potentiels + induits par l'interprétation de messages contenant des blancs représentés + par un caractère autre que l'espace. Alors que les spécifications indiquent + qu'un et un seul espace sépare l'URI de la méthode et le protocole de l'URI, + le serveur HTTP Apache a toujours toléré des blancs constitués d'un ou + plusieurs espaces ou tabulations horizontales. L'option par défaut + LenientWhitespace continue d'accepter de telles requêtes en + provenance d'agents utilisateurs non conformes, mais l'administrateur est + encouragé à utiliser plutôt l'option StrictWhitespace pour + imposer la présence d'exactement deux espaces dans la ligne de requête. + D'autres types de blancs comme les tabulations verticales, form feed + ou retour chariot seront alors rejetés et ne seront plus supportés.

+ +

La section de la RFC 7231 + §4.1 "Request Methods" "Overview" indique que les serveurs doivent + renvoyer un message d'erreur lorsque la ligne de requête comporte une + méthode non supportée. C'est déjà le cas lorsque l'option + LenientMethods est utilisée, mais les administrateurs ont la + possibilité de limiter les méthodes utilisées via l'option + RegisteredMethods en enregistrant toute méthode non standard + via la directive RegisterHttpMethod, en particulier + si l'option Unsafe est utilisée. L'option + RegisteredMethods ne doit pas être utilisée + pour les serveurs mandataires car ces derniers ne connaissent pas les + méthodes supportées par les serveurs originaux.

+ +

La section de la RFC 2616 + §19.6 "Compatibility With Previous Versions" encouragait les + serveurs HTTP à supporter les anciennes requêtes HTTP/0.9. La RFC 7230 va + cependant à son encontre via sa préconisation "Le souhait de supporter les + requêtes HTTP/0.9 a été supprimé" et y adjoint des commentaires dans RFC 2616 Appendix + A. A ce titre, l'option Require1.0 permet à l'utilisateur + d'inhiber le comportement induit par l'option par défaut + Allow0.9.

+ +
top

Directive <If>

diff --git a/docs/manual/mod/core.xml.meta b/docs/manual/mod/core.xml.meta index b9d96ee4c5..e78755527a 100644 --- a/docs/manual/mod/core.xml.meta +++ b/docs/manual/mod/core.xml.meta @@ -10,7 +10,7 @@ deenes - fr + frjatr diff --git a/docs/manual/mod/mod_alias.html.fr b/docs/manual/mod/mod_alias.html.fr index 700d47e13e..3d9d6655f2 100644 --- a/docs/manual/mod/mod_alias.html.fr +++ b/docs/manual/mod/mod_alias.html.fr @@ -32,8 +32,6 @@  ko  |  tr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
@@ -299,18 +297,18 @@ en faisant intervenir les expressions rationnelles
Description:Permet d'atteindre différentes parties du système de fichiers depuis l'arborescence des documents du site web, ainsi que la redirection d'URL
-
Description:Envoie une redirection externe demandant au client d'effectuer une autre requête avec une URL différente
Syntaxe:Redirect [état] [chemin URL] +
Syntaxe:Redirect [état] [URL-path] URL
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:FileInfo
Statut:Base
Module:mod_alias
-

La directive Redirect permet de faire correspondre une ancienne - URL à une nouvelle en demandant au client d'aller chercher la ressource à - une autre localisation.

+

La directive Redirect permet de faire correspondre + une ancienne URL à une nouvelle en demandant au client d'aller chercher la + ressource à une autre localisation.

-

L'ancien chemin URL est un chemin sensible à la casse +

L'ancien URL-path est un chemin sensible à la casse (décodé à l'aide de caractères %) commençant par un slash. Les chemins relatifs ne sont pas autorisés.

@@ -320,10 +318,10 @@ d'effectuer une autre requ slash, auquel cas le protocole et le nom d'hôte du serveur local seront ajoutés.

-

Ensuite, toute requête commençant par chemin URL va +

Ensuite, toute requête commençant par URL-path va renvoyer une redirection au client vers l'URL cible. Tout - élément de chemin supplémentaire situé en aval du chemin - URL sera ajouté à l'URL cible.

+ élément de chemin supplémentaire situé en aval du URL-path sera + ajouté à l'URL cible.

# Redirige vers une URL sur un serveur différent
 Redirect "/service" "http://foo2.example.com/service"
@@ -346,17 +344,18 @@ Redirect "/one" "/two"
précédent ne s'appliquera pas à l'URL http://example.com/servicefoo.txt. Pour des mises en correspondance plus complexes utilisant la syntaxe des expressions, ne spécifiez pas - d'argument chemin URL comme décrit ci-dessous. En outre, + d'argument URL-path comme décrit ci-dessous. En outre, pour une mise en correspondance en utilisant les expressions rationnelles, veuillez vous reporter à la directive RedirectMatch.

Note

-

Les directives de redirection ont priorité sur les directives - Alias et ScriptAlias, quel que soit leur ordre d'apparition dans le - fichier de configuration. Les directives Redirect définies au sein - d'une section Location l'emportent sur les directives Redirect et - Alias comportant un argument chemin URL.

+

Les directives Redirect ont priorité sur les + directives Alias et ScriptAlias, quel que soit leur ordre + d'apparition dans le fichier de configuration. Les directives + Redirect définies au sein d'une section Location + l'emportent sur les directives Redirect et Alias comportant un argument + URL-path.

Si aucun argument état n'est spécifié, la redirection sera temporaire (code HTTP 302). Le client est alors @@ -402,8 +401,7 @@ Redirect 303 "/three" "http://example.com/other"

Si une directive Redirect est définie au - sein d'une section <Location> ou <LocationMatch> et si l'argument chemin - URL est omis, l'argument URL sera interprété en + sein d'une section <Location> ou <LocationMatch> et si l'argument URL-path est omis, l'argument URL sera interprété en utilisant la syntaxe des expressions.
Cette syntaxe est disponible à partir de la version 2.4.19 du serveur HTTP Apache.

diff --git a/docs/manual/mod/mod_alias.xml.meta b/docs/manual/mod/mod_alias.xml.meta index d83657f9fa..547a2db773 100644 --- a/docs/manual/mod/mod_alias.xml.meta +++ b/docs/manual/mod/mod_alias.xml.meta @@ -8,7 +8,7 @@ en - fr + fr ja ko tr diff --git a/docs/manual/mod/mod_rewrite.html.fr b/docs/manual/mod/mod_rewrite.html.fr index 9c9327035e..502ae8a7d9 100644 --- a/docs/manual/mod/mod_rewrite.html.fr +++ b/docs/manual/mod/mod_rewrite.html.fr @@ -29,8 +29,6 @@

Langues Disponibles:  en  |  fr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
@@ -1174,8 +1172,8 @@ s
  • Lorsqu'on utilise le moteur de réécriture dans un fichier .htaccess, le chemin de base du répertoire courant (autrement dit le chemin URI qui représente le répertoire contenant ce fichier -.htaccess) est automatiquement supprimé au cours de la -comparaison avec le modèle de la règle de réécriture, et automatiquement +.htaccess) est supprimé au cours de la +comparaison avec le modèle de la règle de réécriture, et ajouté lorsqu'une substitution relative (ne débutant pas par un slash ou un nom de protocole) arrive à la fin d'un jeu de règles. Voir la directive RewriteBase pour plus de détails à diff --git a/docs/manual/mod/mod_rewrite.xml.meta b/docs/manual/mod/mod_rewrite.xml.meta index 0be21e86f4..decc0a7b1e 100644 --- a/docs/manual/mod/mod_rewrite.xml.meta +++ b/docs/manual/mod/mod_rewrite.xml.meta @@ -8,6 +8,6 @@ en - fr + fr -- 2.50.1
    • Description:Ce module fournit un moteur de réécriture à base de règles permettant de réécrire les URLs des requêtes à la volée