XML updates.

<?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: 1768961:1777141 (outdated) -->

<!-- English Revision: 1777141 -->

<!-- French translation : Lucien GENTIS -->

<!-- Reviewed by : Vincent Deffontaines -->

    cette directive, et n'est conservé (avec des effets imprévisibles) que dans un

    but de compatibilité ascendante.</p>

</usage>

<seealso><directive module="core">UnDefine</directive></seealso>

<seealso><directive module="core">IfDefine</directive></seealso>

</directivesynopsis>

<directivesynopsis type="section">

</usage>

</directivesynopsis>

<directivesynopsis>

<name>HttpProtocolOptions</name>

<description>Modifie les contraintes sur les messages des requêtes HTTP</description>

<syntax>HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods]

 [Allow0.9|Require1.0]</syntax>

<default>HttpProtocolOptions Strict 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

    &sect;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

    &sect;3.2</a>), qui s'appliquent maintenant par défaut ou en utilisant

    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

    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, alors que <a

    href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230

    &sect;3.5</a> signale les risques encourus par l'acceptation de blancs non

    conformes dans les lignes de requête. 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>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

    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 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>

    <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/rfc7231#section-4.1">RFC 7231

    &sect;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

    &sect;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 7230 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

    changements qu'elle induit sont visibles de toute directive

    ultérieure, au delà de tout bloc VirtualHost.</p>

</usage>

<seealso><directive module="core">Define</directive></seealso>

<seealso><directive module="core">IfDefine</directive></seealso>

</directivesynopsis>

<directivesynopsis>

</usage>

</directivesynopsis>

<directivesynopsis>

<name>RegisterHttpMethod</name>

<description>Enregistrement de méthodes HTTP non standards</description>

<syntax>RegisterHttpMethod <var>méthode</var> [<var>méthode</var> [...]]</syntax>

<contextlist><context>server config</context></contextlist>

<usage>

<p>Normalement, les méthodes HTTP non conformes aux RFCs correspondantes

sont rejetées au cours du traitement de la requête par HTTPD. Pour

éviter ceci, les modules peuvent enregistrer les méthodes HTTP non

standards qu'ils supportent. La directive

<directive>RegisterHttpMethod</directive> permet d'enregistrer de telles

méthodes manuellement. Ceci peut s'avérer utile si de telle méthodes

doivent être utilisées dans un traitement externe, comme un script CGI.</p>

</usage>

</directivesynopsis>

</modulesynopsis>

<?xml version='1.0' ?>

<?xml version='1.0' encoding="UTF-8"?>

<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>

<!-- English Revision: 1344668:1777060 (outdated) -->

<!-- English Revision: 1777060 -->

<!-- French translation by Vincent Deffontaines, review by alain B -->

<!-- Updated by Lucien Gentis -->