From: Lucien Gentis Date: Sun, 21 Aug 2016 11:42:51 +0000 (+0000) Subject: XML updates. X-Git-Tag: 2.5.0-alpha~1225 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=df61fdc3635348203628999ccd34621eac077492;p=apache XML updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1757049 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.xml.fr b/docs/manual/mod/core.xml.fr index 0544ed00a5..c4f4b8a9c3 100644 --- a/docs/manual/mod/core.xml.fr +++ b/docs/manual/mod/core.xml.fr @@ -1,7 +1,7 @@ - + @@ -1354,6 +1354,114 @@ host + +HttpProtocolOptions +Modifie les contraintes sur les messages des requêtes HTTP +HttpProtocolOptions [Strict|Unsafe] [StrictURL|UnsafeURL] + [StrictWhitespace|LenientWhitespace] [RegisteredMethods|LenientMethods] + [Allow0.9|Require1.0] +HttpProtocolOptions Strict StrictURL LenientWhitespace +LenientMethods Allow0.9 +server config +virtual host +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.

+ + + Error Interrompt la lecture de la configuration avec un message @@ -2030,7 +2138,7 @@ host <FilesMatch ".+\.(gif|jpe?g|png)$"> # ... </FilesMatch> - +

correspondrait à la plupart des formats graphiques de l'Internet.

diff --git a/docs/manual/mod/mod_alias.xml.fr b/docs/manual/mod/mod_alias.xml.fr index 013af1dbea..b0157e2f37 100644 --- a/docs/manual/mod/mod_alias.xml.fr +++ b/docs/manual/mod/mod_alias.xml.fr @@ -1,7 +1,7 @@ - + @@ -313,18 +313,18 @@ en faisant intervenir les expressions rationnelles Redirect Envoie une redirection externe demandant au client d'effectuer une autre requête avec une URL différente -Redirect [état] [chemin URL] +Redirect [état] [URL-path] URL server configvirtual host directory.htaccess FileInfo -

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.

@@ -334,10 +334,10 @@ d'effectuer une autre requête avec une URL différente 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 @@ -362,18 +362,21 @@ Redirect "/one" "/two" 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 @@ -422,8 +425,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 + module="core">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_rewrite.xml.fr b/docs/manual/mod/mod_rewrite.xml.fr index c0f2910655..93a8eebbfe 100644 --- a/docs/manual/mod/mod_rewrite.xml.fr +++ b/docs/manual/mod/mod_rewrite.xml.fr @@ -1,7 +1,7 @@ - + @@ -1198,8 +1198,8 @@ sécurité.
  • 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 Ã