l'option <code>Strict</code>. L'option <code>Unsafe</code>
a été ajoutée 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
+ utilisateurs personnalisés considérés comme obsolètes.</p>
+
+ <p>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>Cette directive accepte trois paramètres issus de la liste suivante, ceux
+ qui ne sont pas spécifiés prenant leur valeur par défaut :</p>
+
+ <dl>
+ <dt>Strict|Unsafe</dt>
+ <dd>
<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
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>
+ <div class="warning"><h3>Risques de sécurité liés au mode Unsafe</h3>
<p>Il est fortement déconseillé aux utilisateurs d'utiliser le mode
d'opération <code>Unsafe</code>, ou
<code>UnsafeWhitespace</code>, en particulier pour les déploiements de
nécessite une interface, les utilisateurs ne doivent utiliser les options de
type UnSafe qu'en cas de nécessité et uniquement au sein d'un serveur
virtuel bien spécifique et sur un réseau privé.</p>
+ </div>
- <p>La consultation des messages enregistrés dans le journal
- <code class="directive">ErrorLog</code>, configuré via la directive
- <code class="directive">LogLevel</code> 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>
-
+ <div class="example"><h3>Exemple de requête provoquant l'envoi d'un message HTTP 400 en
+ mode Strict</h3><p><code>
+
+ # Missing CRLF<br />
+ GET / HTTP/1.0\n\n
+ </code></p></div>
+ </dd>
+ <dt>RegisteredMethods|LenientMethods</dt>
+ <dd>
<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
possibilité de limiter les méthodes utilisées via l'option
<code>RegisteredMethods</code> en enregistrant toute méthode non standard
via la directive <code class="directive">RegisterHttpMethod</code>, en particulier
- si l'option <code>Unsafe</code> est utilisée. L'option
+ si l'option <code>Unsafe</code> est utilisée.</p>
+
+ <div class="warning"><h3>Compatibilité avec le mandat direct</h3>
+ <p>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>
+ </div>
+ <div class="example"><h3>Exemple de requête provoquant l'envoi d'un message HTTP 501 en
+ mode LenientMethods</h3><p><code>
+
+ # Méthode HTTP inconnue<br />
+ WOW / HTTP/1.0\r\n\r\n<br /><br />
+ # Méthode HTTP spécifiée en minuscules<br />
+ get / HTTP/1.0\r\n\r\n<br />
+ </code></p></div>
+ </dd>
+ <dt>Allow0.9|Require1.0</dt>
+ <dd>
<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
d'inhiber le comportement induit par l'option par défaut
<code>Allow0.9</code>.</p>
+ <div class="example"><h3>Exemple de requête provoquant l'envoi d'un message HTTP 400 en
+ mode Require1.0</h3><p><code>
+
+ # Version HTTP non supportée<br />
+ GET /\r\n\r\n
+ </code></p></div>
+ </dd>
+ </dl>
+
+ <p>La consultation des messages enregistrés dans le journal
+ <code class="directive">ErrorLog</code>, configuré via la directive
+ <code class="directive">LogLevel</code> 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>
+
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="if" id="if">Directive</a> <a name="If" id="If"><If></a></h2>
projects / apache / commitdiff