<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1750750:1756959 (outdated) -->
+<!-- English Revision: 1756959 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
</usage>
</directivesynopsis>
+<directivesynopsis>
+<name>HttpProtocolOptions</name>
+<description>Modifie les contraintes sur les messages des requêtes HTTP</description>
+<syntax>HttpProtocolOptions [Strict|Unsafe] [StrictURL|UnsafeURL]
+ [StrictWhitespace|LenientWhitespace] [RegisteredMethods|LenientMethods]
+ [Allow0.9|Require1.0]</syntax>
+<default>HttpProtocolOptions Strict StrictURL LenientWhitespace
+LenientMethods Allow0.9</default>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+<compatibility>Disponible à partir des versions 2.2.32 et 2.4.24 du serveur HTTP
+Apache</compatibility>
+
+<usage>
+ <p>Cette directive permet de modifier les règles qui s'appliquent à la ligne
+ de requête HTTP (<a
+ href="https://tools.ietf.org/html/rfc7230#section-3.1.1">RFC 7230
+ §3.1.1</a>) et aux champs des en-têtes des requêtes HTTP (<a
+ href="https://tools.ietf.org/html/rfc7230#section-3.2">RFC 7230
+ §3.2</a>), qui s'appliquent maintenant par défaut ou en utilisant
+ l'option <code>Strict</code>. Les options <code>Unsafe</code> et
+ <code>UnsafeURL</code> 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.</p>
+
+ <p>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. <a
+ href="https://tools.ietf.org/html/rfc7230#section-9.4">RFC 7230 §9.4
+ Request Splitting</a> et <a
+ href="https://tools.ietf.org/html/rfc7230#section-9.5">§9.5 Response
+ Smuggling</a> 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 <code>Strict</code>.</p>
+
+ <p><a href="https://tools.ietf.org/html/rfc3986#section-2.2">RFC 7230
+ §2.2 and 2.3</a> 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 <code>StrictURI</code> rejète toutes les
+ requêtes contenant des caractères non valides. Cette règle peut être
+ contournée en utilisant l'option <code>UnsafeURI</code> qui permet de
+ supporter les agents utilisateur mal conçus.</p>
+
+ <p>Il est fortement déconseillé aux utilisateurs d'utiliser les modes
+ d'opérations <code>Unsafe</code> et <code>UnsafeURI</code>, 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é.</p>
+
+ <p>La consultation des messages enregistrés dans le journal
+ <directive>ErrorLog</directive>, configuré via la directive
+ <directive>LogLevel</directive> avec un niveau <code>info</code>, 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.</p>
+
+ <p>La section de la <a
+ href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230
+ §3.5</a> "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
+ <code>LenientWhitespace</code> continue d'accepter de telles requêtes en
+ provenance d'agents utilisateurs non conformes, mais l'administrateur est
+ encouragé à utiliser plutôt l'option <code>StrictWhitespace</code> 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.</p>
+
+ <p>La section de la <a
+ href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231
+ §4.1</a> "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
+ <code>LenientMethods</code> est utilisée, mais les administrateurs ont la
+ possibilité de limiter les méthodes utilisées via l'option
+ <code>RegisteredMethods</code> en enregistrant toute méthode non standard
+ via la directive <directive>RegisterHttpMethod</directive>, en particulier
+ si l'option <code>Unsafe</code> est utilisée. L'option
+ <code>RegisteredMethods</code> <strong>ne doit pas</strong> être utilisée
+ pour les serveurs mandataires car ces derniers ne connaissent pas les
+ méthodes supportées par les serveurs originaux.</p>
+
+ <p>La section de la <a
+ href="https://tools.ietf.org/html/rfc2616#section-19.6">RFC 2616
+ §19.6</a> "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 <a
+ href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 2616 Appendix
+ A</a>. A ce titre, l'option <code>Require1.0</code> permet à l'utilisateur
+ d'inhiber le comportement induit par l'option par défaut
+ <code>Allow0.9</code>.</p>
+</usage>
+</directivesynopsis>
+
<directivesynopsis>
<name>Error</name>
<description>Interrompt la lecture de la configuration avec un message
<FilesMatch ".+\.(gif|jpe?g|png)$">
# ...
</FilesMatch>
-</highlight>
+ </highlight>
<p>correspondrait à la plupart des formats graphiques de
l'Internet.</p>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1731335:1756706 (outdated) -->
+<!-- English Revision: 1756706 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<name>Redirect</name>
<description>Envoie une redirection externe demandant au client
d'effectuer une autre requête avec une URL différente</description>
-<syntax>Redirect [<var>état</var>] [<var>chemin URL</var>]
+<syntax>Redirect [<var>état</var>] [<var>URL-path</var>]
<var>URL</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>FileInfo</override>
<usage>
- <p>La directive Redirect permet de faire correspondre une ancienne
- URL à une nouvelle en demandant au client d'aller chercher la ressource à
- une autre localisation.</p>
+ <p>La directive <directive>Redirect</directive> permet de faire correspondre
+ une ancienne URL à une nouvelle en demandant au client d'aller chercher la
+ ressource à une autre localisation.</p>
- <p>L'ancien <em>chemin URL</em> est un chemin sensible à la casse
+ <p>L'ancien <em>URL-path</em> 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.</p>
slash, auquel cas le protocole et le nom d'hôte du serveur local
seront ajoutés.</p>
- <p>Ensuite, toute requête commençant par <em>chemin URL</em> va
+ <p>Ensuite, toute requête commençant par <em>URL-path</em> va
renvoyer une redirection au client vers l'<em>URL</em> cible. Tout
- élément de chemin supplémentaire situé en aval du <em>chemin
- URL</em> sera ajouté à l'URL cible.</p>
+ élément de chemin supplémentaire situé en aval du <em>URL-path</em> sera
+ ajouté à l'URL cible.</p>
<highlight language="config">
# Redirige vers une URL sur un serveur différent
<code>http://example.com/servicefoo.txt</code>. Pour des mises en
correspondance plus complexes utilisant la <a
href="../expr.html">syntaxe des expressions</a>, ne spécifiez pas
- d'argument <var>chemin URL</var> comme décrit ci-dessous. En outre,
+ d'argument <var>URL-path</var> comme décrit ci-dessous. En outre,
pour une mise en correspondance en utilisant les expressions
rationnelles, veuillez vous reporter à la directive <directive
module="mod_alias">RedirectMatch</directive>.</p>
<note><title>Note</title>
- <p>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 <var>chemin URL</var>.</p></note>
+ <p>Les directives <directive>Redirect</directive> ont priorité sur les
+ directives <directive module="mod_alias">Alias</directive> et <directive
+ module="mod_alias">ScriptAlias</directive>, quel que soit leur ordre
+ d'apparition dans le fichier de configuration. Les directives
+ <directive>Redirect</directive> définies au sein d'une section Location
+ l'emportent sur les directives <directive>Redirect</directive> et <directive
+ module="mod_alias">Alias</directive> comportant un argument
+ <var>URL-path</var>.</p></note>
<p>Si aucun argument <var>état</var> n'est spécifié, la
redirection sera temporaire (code HTTP 302). Le client est alors
<p>Si une directive <directive>Redirect</directive> est définie au
sein d'une section <directive type="section"
module="core">Location</directive> ou <directive type="section"
- module="core">LocationMatch</directive> et si l'argument <var>chemin
- URL</var> est omis, l'argument <var>URL</var> sera interprété en
+ module="core">LocationMatch</directive> et si l'argument <var>URL-path</var> est omis, l'argument <var>URL</var> sera interprété en
utilisant la <a href="../expr.html">syntaxe des expressions</a>.<br />
Cette syntaxe est disponible à partir de la version 2.4.19 du
serveur HTTP Apache.</p>
projects / apache / commitdiff