From: Lucien Gentis Cette directive permet de spécifier la liste des protocoles
+ supportés par un serveur virtuel ou non. Cette liste énumère les
+ protocoles qu'un client sera autorisé à négocier avec ce
+ serveur. Vous ne devez fournir cette liste que si vous voulez limiter
+ les protocoles disponibles pour le serveur. Par défaut, tous les
+ protocoles sont disponibles. Par exemple, si vous ne voulez autoriser que le protocole
+ HTTP/1.1, même si le protocole HTTP/2 est disponible, utilisez
+ cette directive comme suit : Les protocoles valides sont Spécifier des protocoles non disponibles ou désactivés n'aura
+ aucun effet, et ceux-ci seront simplement ignorés. Si des protocoles sont spécifiés au niveau du serveur
+ principal, il seront concaténés à ceux éventuellement définis
+ au niveau des serveurs virtuels. Comme certains protocoles comme
+ HTTP/2 permettent la réutilisation des connexions sous certaines
+ conditions, la restriction de l'utilisation des protocoles pour
+ des serveurs virtuels individuels pourra ne pas fonctionner de
+ la manière dont vous vous attendez. Cette directive permet de définir si le serveur doit tenir
+ compte de l'ordre des protocoles définis par la directive
+ Par défaut, un client fournit une liste de protocoles
+ supportés et le serveur sélectionne le premier disponible. Si la directive Ce module permet la journalisation légale des requêtes client. La
- journalisation s'effectuant avant et après le traitement de la
+ Ce module permet la journalisation légale des requêtes client. La création du fichier journal correspondant s'effectue via la
+ directive La journalisation s'effectuant avant et après le traitement de la
requête, le journal légal contient deux lignes pour chaque requête.
Le processus de journalisation légale est très strict, à savoir
: Pour interpréter les données du journal légal, vous pouvez vous
+ Pour interpréter les données du journal
+ légal afin d'identifier les requêtes dont le traitement n'a
+ pas été mené à bien, vous pouvez vous
aider du script Cette directive va créer un worker associé à l'URL du serveur
- original Lorsqu'elle est activée, cette directive va transmettre l'en-tête
Host: de la requête entrante vers le serveur mandaté, au lieu du nom
- d'hôte spécifié par la directive http/1.1
pour les
+ connexions http et https, h2
pour les connections
+ https et h2c
pour les connexions http. D'autres
+ modules peuvent fournir d'autres protocoles.on
, il n'est pas tenu compte de l'ordre de la liste des
+ protocoles fournie par le client, et seul l'ordre de la liste des
+ protocles définie au niveau du serveur influera la négociation
+ du protocole.check_forensic
qui se trouve dans le
répertoire support de la distribution.http://backend.example.com
, et utilisant les
+ original http://backend.example.com
, qui utilisera les
valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre
d'un mandataire direct, les workers sont en général définis via la
directive
Cette directive est habituellement définie à Off
.
Elle est principalement utile dans les configurations particulières
@@ -758,7 +758,7 @@ ProxyRemote ftp http://ftpproxy.mydomain:8080
HTTP, vers un autre mandataire capable de les traiter.
Cette directive supporte aussi les configurations de mandataire - inverse - un serveur web d'arrière-plan peut être intégré dans + inverse ; un serveur web d'arrière-plan peut être intégré dans l'espace d'URL d'un serveur virtuel, même si ce serveur est caché par un autre mandataire direct.
@@ -1480,7 +1480,7 @@ ProxyPass "/" "balancer://hotcluster/ " utilisent PATH_INFO. Le mot-clé optionnel nocanon modifie ce comportement et permet de transmettre le chemin d'URL sous sa forme brute au serveur d'arrière-plan. Notez - que ceci peut affecter la sécurité de votre serveur d'arrière-plan, + que ce mot-clé peut affecter la sécurité de votre serveur d'arrière-plan, car la protection limitée contre les attaques à base d'URL que fournit le mandataire est alors supprimée. @@ -1654,8 +1654,8 @@ par un serveur mandaté en inversechemin est le nom d'un chemin virtuel local.
- url est une URL partielle pour le serveur distant - ils
- sont utilisés de la même façon qu'avec la directive
Supposons par exemple que le serveur local a pour adresse
@@ -1673,7 +1673,7 @@ ProxyPassReverseCookiePath "/" "/mirror/foo/"
requête mandatée pour http://backend.example.com/bar
(la fonctionnalité fournie par ProxyPass
). Il va
aussi s'occuper des redirections que le serveur
- backend.example.com
envoie : lorsque
+ backend.example.com
envoie lorsque
http://backend.example.com/bar
est redirigé par
celui-ci vers http://backend.example.com/quux
, Apache
httpd corrige ceci en http://example.com/miroir/foo/quux
@@ -1683,8 +1683,9 @@ ProxyPassReverseCookiePath "/" "/mirror/foo/"
module="core">UseCanonicalName.
Notez que la directive RewriteRule ... [P]
) du module
+ peut aussi être utilisée en conjonction avec la
+ fonctionnalité de mandataire
+ (RewriteRule ... [P]
) du module
${nom_var}
dans les directives
de configuration par la valeur de la variable d'environnement
- nom_var
(si l'option interpolate est
- spécifiée).
+ nom_var
si l'option interpolate est
+ spécifiée.
Conservez cette directive à off (pour les performances du serveur), sauf si vous en avez réellement besoin.
diff --git a/docs/manual/rewrite/flags.xml.fr b/docs/manual/rewrite/flags.xml.fr index 4cb3b6ad5a..7db59f426f 100644 --- a/docs/manual/rewrite/flags.xml.fr +++ b/docs/manual/rewrite/flags.xml.fr @@ -1,7 +1,7 @@ - + @@ -153,6 +153,15 @@ suivante : [CO=NAME:VALUE:DOMAIN:lifetime:path:secure:httponly] +Si un caractère littéral ':' doit être insérer dans un des champs du +cookie, une autre syntaxe est disponible. Pour utiliser cette syntaxe +alternative, le contenu du champ "Name" doit être précédé du caractère +';', et les sépateurs de champs deviendront des ';'.
+ +Vous devez déclarer un nom, une valeur et un domaine pour que le cookie puisse être défini.