Description:	Ce module permet de restreindre aisément les méthodes HTTP +pouvant être utilisées sur le serveur
Statut:	Expérimental
Identificateur de Module:	allowmethods_module
Fichier Source:	mod_allowmethods.c

Description:	Restreint l'accès aux méthodes HTTP spécifiées
Syntaxe:	`AllowMethods reset\|HTTP-method +[HTTP-method]...`
Défaut:	`AllowMethods reset`
Contexte:	répertoire
Statut:	Expérimental
Module:	mod_allowmethods

Module Apache mod_authz_dbd

Langues Disponibles: en | + fr

+ + + + +

Description:	Autorisation en groupe et reconnaissance d'identité avec base +SQL
Statut:	Extension
Identificateur de Module:	authz_dbd_module
Fichier Source:	mod_authz_dbd.c
Compatibilité:	Disponible dans les versions 2.4 et supérieures +d'Apache

Sommaire

+ +

Ce module fournit des fonctionnalités d'autorisation permettant + d'accorder ou de refuser aux utilisateurs authentifiés l'accès à + certaines zones du site web en fonction de leur appartenance à tel + ou tel groupe. Les modules mod_authz_groupfile et + mod_authz_dbm fournissent une fonctionnalité + similaire, mais ici le module interroge une base de données SQL pour + déterminer si un utilisateur appartient ou non à tel ou tel groupe.

Ce module propose également des fonctionnalités de connexion + utilisateur s'appuyant sur une base de données, ce qui peut se révéler + particulièrement utile lorsque le module est utilisé conjointement avec + mod_authn_dbd.

Ce module s'appuie sur mod_dbd pour spécifier le + pilote de la base de données sous-jacente et les paramètres de + connexion, et gérer les connexions à la base de données.

Reconnaissance d'identité s'appuyant sur une base de données

+ +

+Outre sa fonction d'autorisation standard consistant à vérifier +l'appartenance à des groupes, ce module permet aussi de gérer des +sessions utilisateur côté serveur grâce à sa fonctionnalité de connexion utilisateur +en s'appuyant sur une base de données. En particulier, il peut mettre à +jour le statut de session de l'utilisateur dans la base de données +chaque fois que celui-ci visite certaines URLs (sous réserve bien +entendu que l'utilisateur fournissent les informations de connexion +nécessaires).

Pour cela, il faut definir deux directives Require spéciales : Require +dbd-login et Require dbd-logout. Pour les détails de +leur utilisation, voir l'exemple de configuration ci-dessous.

Reconnaissance d'identité côté client

+ +

Certains administrateurs peuvent vouloir implémenter une gestion de +session côté client fonctionnant de concert avec les fonctionnalités de +connexion/déconnexion des utilisateurs côté serveur offertes par ce module, en +définissant ou en annulant par exemple un cookie HTTP ou un jeton +similaire lorsqu'un utilisateur se connecte ou se déconnecte. Pour +supporter une telle intégration, mod_authz_dbd exporte +un programme à déclenchement optionnel (hook) qui sera lancé chaque fois +que le statut d'un utilisateur sera mis à jour dans la base de données. +D'autres modules de gestion de session pourront alors utiliser ce +programme pour implémenter des fonctions permettant d'ouvrir et de +fermer des sessions côté client.

Exemple de configuration

+ +

+# configuration de mod_dbd
+DBDriver pgsql
+DBDParams "dbname=apacheauth user=apache pass=xxxxxx"
+
+DBDMin  4
+DBDKeep 8
+DBDMax  20
+DBDExptime 300
+
+<Directory /usr/www/mon.site/team-private/>
+  # configuration de mod_authn_core et mod_auth_basic
+  # pour mod_authn_dbd
+  AuthType Basic
+  AuthName Team
+  AuthBasicProvider dbd
+
+  # requête SQL de mod_authn_dbd pour authentifier un utilisateur qui se
+  # connecte
+  AuthDBDUserPWQuery \
+    "SELECT password FROM authn WHERE user = %s AND login = 'true'"
+
+  # configuration de mod_authz_core pour mod_authz_dbd
+  Require dbd-group team
+
+  # configuration de mod_authz_dbd
+  AuthzDBDQuery "SELECT group FROM authz WHERE user = %s"
+
+  # lorsqu'un utilisateur échoue dans sa tentative d'authentification ou
+  # d'autorisation, on l'invite à se connecter ; cette page doit
+  # contenir un lien vers /team-private/login.html
+  ErrorDocument 401 /login-info.html
+
+  <Files login.html>
+    # il n'est pas nécessaire que l'utilisateur soit déjà connecté !
+    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+
+    # le processus de connexion dbd exécute une requête pour enregistrer
+    # la connexion de l'utilisateur
+    Require dbd-login
+    AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s"
+
+    # redirige l'utilisateur vers la page d'origine (si elle existe)
+    # après une connexion réussie
+    AuthzDBDLoginToReferer On
+  </Files>
+
+  <Files logout.html>
+    # le processus de déconnexion dbd exécute une requête pour
+    # enregistrer la déconnexion de l'utilisateur
+    Require dbd-logout
+    AuthzDBDQuery "UPDATE authn SET login = 'false' WHERE user = %s"
+  </Files>
+</Directory>
+

+ +

AuthzDBDLoginToReferer Directive

+ + + + + + + +

Description:	Définit si le client doit être redirigé vers la page +d'origine en cas de connexion ou de déconnexion réussie si un en-tête +de requête `Referer` est présent
Syntaxe:	`AuthzDBDLoginToReferer On\|Off`
Défaut:	`AuthzDBDLoginToReferer Off`
Contexte:	répertoire
Statut:	Extension
Module:	mod_authz_dbd

Utilisée en conjonction avec Require dbd-login ou + Require dbd-logout, cette directive permet de rediriger + le client vers la page d'origine (l'URL contenue dans l'en-tête + de requête HTTP Referer, s'il est présent). En + l'absence d'en-tête Referer, la définition + AuthzDBDLoginToReferer On sera ignorée.

+ +

AuthzDBDQuery Directive

+ + + + + + +

Description:	Définit la requête SQL pour l'opération requise
Syntaxe:	`AuthzDBDQuery requête`
Contexte:	répertoire
Statut:	Extension
Module:	mod_authz_dbd

La directive AuthzDBDQuery permet de + spécifier une requête SQL à exécuter. Le but de cette requête dépend + de la directive Require en cours de + traitement.

Avec la directive Require dbd-group, elle spécifie + une requête permettant de rechercher les groupes d'appartenance de + l'utilisateur courant. Ceci correspond à la fonctionnalité standard + d'autres modules d'autorisation comme + mod_authz_groupfile et + mod_authz_dbm. + La première colonne de chaque enregistrement renvoyé par la requête + doit contenir une chaîne de caractères correspondant à un nom de + groupe. La requête peut renvoyer zéro, un ou plusieurs + enregistrements. +
```
+Require dbd-group
+AuthzDBDQuery "SELECT group FROM groups WHERE user = %s"
+
```
+ +
Avec la directive Require dbd-login ou + Require dbd-logout, elle ne refusera jamais l'accès, + mais au contraire exécutera une requête SQL permettant d'enregistrer + la connexion ou la déconnexion de l'utilisateur. Ce dernier doit + être déjà authentifié avec mod_authn_dbd. +
```
+Require dbd-login
+AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s"
+
```
+ +

Dans tous les cas, l'identifiant utilisateur sera transmis comme + paramètre sous la forme d'une simple chaîne lorsque la requête SQL + sera exécutée. Il y sera fait référence dans la requête en utilisant + le spécificateur de format %s.

+ +

AuthzDBDRedirectQuery Directive

+ + + + + + +

Description:	Définit une requête pour rechercher une page vers laquelle +rediriger l'utilisateur après une connexion réussie
Syntaxe:	`AuthzDBDRedirectQuery requête`
Contexte:	répertoire
Statut:	Extension
Module:	mod_authz_dbd

Spécifie une requête SQL optionnelle à utiliser après une + connexion (ou une déconnexion) réussie pour rediriger l'utilisateur + vers une URL, qui peut être spécifique à l'utilisateur. + L'identifiant utilisateur sera transmis comme paramètre sous la + forme d'une simple chaîne lorsque la requête SQL sera exécutée. Il y + sera fait référence dans la requête en utilisant le spécificateur de + format %s.

+AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
+

+ +

La première colonne du premier enregistrement renvoyé par la + requête doit contenir une chaîne de caractères correspondant à une + URL vers laquelle rediriger le client. Les enregistrements suivants + sont ignorés. Si aucun enregistrement n'est renvoyé, le client ne + sera pas redirigé.

Notez que AuthzDBDLoginToReferer l'emporte + sur cette directive si les deux sont définies.

+ +

Description:	Autorisation basée sur les groupes à l'aide de fichiers +DBM
Statut:	Extension
Identificateur de Module:	authz_dbm_module
Fichier Source:	mod_authz_dbm.c
Compatibilité:	Disponible depuis les versions 2.1 et supérieures +d'Apache

Description:	Définit le nom du fichier de base de données contenant la +liste des groupes d'utilisateurs permettant de définir les +autorisations des utilisateurs
Syntaxe:	`AuthDBMGroupFile chemin-fichier`
Contexte:	répertoire, .htaccess
AllowOverride:	AuthConfig
Statut:	Extension
Module:	mod_authz_dbm

Description:	Définit le type de fichier de base de données contenant +la liste des groupes d'utilisateurs
Syntaxe:	`AuthzDBMType default\|SDBM\|GDBM\|NDBM\|DB`
Défaut:	`AuthzDBMType default`
Contexte:	répertoire, .htaccess
AllowOverride:	AuthConfig
Statut:	Extension
Module:	mod_authz_dbm

Description:	Autorisation basée sur les groupes à l'aide de fichiers +textes
Statut:	Base
Identificateur de Module:	authz_groupfile_module
Fichier Source:	mod_authz_groupfile.c
Compatibilité:	Disponible depuis les versions 2.1 et supérieures +d'Apache

Description:	Définit le nom d'un fichier texte contenant la liste des +groupes d'utilisateurs permettant de définir les autorisations des +utilisateurs
Syntaxe:	`AuthGroupFile chemin-fichier`
Contexte:	répertoire, .htaccess
AllowOverride:	AuthConfig
Statut:	Base
Module:	mod_authz_groupfile

Module Apache mod_proxy_ajp

Langues Disponibles: en | + fr | + ja

+ + + + +

Description:	Module de support AJP pour +`mod_proxy`
Statut:	Extension
Identificateur de Module:	proxy_ajp_module
Fichier Source:	mod_proxy_ajp.c
Compatibilité:	Disponible depuis la version 2.1 d'Apache

Sommaire

+ +

Ce module nécessite le chargement de mod_proxy. Il fournit le support du Protocole Apache + JServ version 1.3 (nommé dans la suite de ce document + AJP13).

+ +

Pour être en mesure d'exploiter le protocole AJP13, + il est donc nécessaire de charger les modules + mod_proxy et mod_proxy_ajp.

+ +

Avertissement

N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux non seulement pour + votre réseau, mais aussi pour l'Internet au sens large.

Directives

Ce module ne fournit aucune directive.

Voir aussi

Commentaires

Utilisation

Ce module permet de mandater en inverse un serveur d'application + d'arrière-plan (comme Apache Tomcat) qui utilise le protocole AJP13. + Son utilisation est similaire à celle d'un mandataire inverse HTTP, + mais s'appuie sur le prefixe ajp:// :

+ +

Mandataire inverse simple

+    ProxyPass /app ajp://backend.example.com:8009/app
+

+ +

On peut aussi configurer un répartiteur de charge :

Mandataire inverse avec répartiteur de charge

+<Proxy balancer://cluster>
+    BalancerMember ajp://app1.example.com:8009 loadfactor=1
+    BalancerMember ajp://app2.example.com:8009 loadfactor=2
+    ProxySet lbmethod=bytraffic
+</Proxy>
+ProxyPass /app balancer://cluster/app
+

+ +

Notez qu'en général, la directive ProxyPassReverse n'est pas + nécessaire. La requête AJP inclut l'en-tête host original fourni + au mandataire, et le serveur d'application est sensé générer des + en-têtes auto-référençants relatifs à cet hôte ; aucune réécriture + n'est donc nécessaire.

+ +

La situation la plus courante dans laquelle la directive ProxyPassReverse est nécessaire se + rencontre lorsque le chemin de l'URL au niveau du mandataire est + différente de celle du serveur d'arrière-plan. Dans ce cas, un + en-tête redirect peut être réécrit relativement à l'URL de l'hôte + original (et non du serveur d'arrière-plan ajp:// URL) + ; par exemple :

Réécriture d'un chemin mandaté

+ProxyPass /apps/foo ajp://backend.example.com:8009/foo
+ProxyPassReverse /apps/foo http://www.example.com/foo
+

Il est cependant préférable en général de déployer l'application + sur le serveur d'arrière-plan avec le même chemin que sur le + mandataire. +

Variables d'environnement

Les variables d'environnement dont le nom possède le préfixe + AJP_ sont transmises au serveur original en tant + qu'attributs de requête AJP (le préfixe AJP_ étant supprimé du nom + de la clé).

Vue d'ensemble du protocole

Le protocole AJP13 est orienté paquet. Le format + binaire a été préféré, probablement pour des raisons de + performances, au format texte pourtant plus lisible. Le serveur web + communique avec le conteneur de servlets sur une connexion TCP. Pour + diminuer la charge induite par le processus de création de socket, + le serveur web va tenter d'utiliser des connexions TCP persistantes + avec le conteneur de servlets, et de réutiliser les connexions + pendant plusieurs cycles requêtes/réponse.

Lorsqu'une connexion a été assignée à une requête particulière, + elle ne sera utilisée pour aucune autre jusqu'à ce que le cycle de + traitement de la requête se soit terminé. En d'autres termes, il n'y + a pas de multiplexage des requêtes sur une connexion. Ceci se + traduit par un code beaucoup plus simple à chaque extrémité de la + connexion, un nombre plus important de connexions étant cependant + ouvertes en même temps.

Lorsque le serveur web a ouvert une connexion vers le conteneur + de servlets, celle-ci peut se trouver dans l'un des états suivants + :

Idle
Aucune requête n'est traitée sur cette + connexion.
Assigned
La connexion fait l'objet d'un traitement de + requête.

Lorsqu'une connexion est assignée au traitement d'une requête + particulière, les informations de base de cette dernière (comme les + en-têtes HTTP, etc...) sont envoyées sur la connexion sous une forme + très condensée (par exemple les chaînes courantes sont codées sous + forme d'entiers). Vous trouverez des détails sur ce format plus + loin dans la structure des paquets de requête. Si la requête possède + un corps (content-length > 0), il est envoyé dans un + paquet séparé immédiatement après.

A ce moment, le conteneur est probablement prêt à traiter la + requête. Au cours de ce traitement, il peut renvoyer les messages + suivants au serveur web :

SEND_HEADERS
Renvoie un jeu d'en-têtes au navigateur.
SEND_BODY_CHUNK
Renvoie un tronçon de corps de requête au + navigateur. +
GET_BODY_CHUNK
Reçoit un autre tronçon de données de la + requête si elle n'a pas encore été transmise intégralement. Ce type + de transmission est nécessaire car les paquets possèdent une taille + maximale fixe, et des quantités quelconques de données peuvent être + contenues dans le corps de la requête (pour un chargement de + fichier, par exemple). Notez que cela n'a rien à voir avec le + transfert HTTP fractionné.
END_RESPONSE
Termine le cycle du traitement de la + requête.

Chaque message est associé à un paquet de données formaté + différemment. Voir plus loin les structures des paquets de réponses + pour plus de détails.

Structure de base des paquets

Ce protocole hérite en partie de XDR, mais il diffère sur de + nombreux points (pas d'alignement sur 4 bits, par exemple).

Ordre des octets : je ne suis pas sûr du type endian des octets + individuels. Je suppose qu'ils sont de type little-endian, car cela + correspond à la spécification XDR, et je suppose aussi que la + bibliothèque sys/socket fonctionne ainsi automatiquement (du point + de vue du langage C). Il serait souhaitable que quelqu'un possèdant + une meilleure connaissance des appels socket puisse prendre le + relai.

Le protocole comporte quatre types de données : octets, booléens, + entiers et chaînes de caractères.

Octet: Un seul octet.
Booléen: Un seul octet, 1 = vrai, 0 = faux. + L'utilisation d'autres valeurs non nulles (dans le style C) peut + fonctionner dans certains cas, mais pas dans certains autres..
Entier: Un nombre compris entre 0 et 2^16 (32768), stocké + sur 2 octets en débutant par l'octet de poids forts.
Chaîne: Une chaîne de taille variable (longueur limitée à 2^16). Elle + est codée comme suit : les deux premiers octets représentent la + longueur de la chaîne, les octets suivants constituent la chaîne + proprement dite (y compris le '\0' final). Notez que la longueur + encodée dans les deux premiers octets ne prend pas en compte le + '\0' final, de la même manière que strlen. Cela peut + prêter à confusion du point de vue de Java qui est surchargé de + déclarations d'autoincrémentation étranges destinées à traiter + ces terminateurs. Je suppose que le but dans lequel cela a + été conçu ainsi était de permettre au code C d'être plus efficace + lors de la lecture de chaînes en provenance du conteneur de + servlets -- avec le caractère \0 final, le code C peut transmettre + des références dans un seul tampon, sans avoir à effectuer de + copie. En l'absence du caractère \0 final, le code C doit + effectuer une copie afin de pouvoir tenir compte de sa notion de + chaîne.

+ +

Taille du paquet

Selon la majorité du code, la taille maximale du paquet est de + 8 * 1024 bytes (8K). La taille réelle du paquet est + encodée dans l'en-tête.

+ +

En-têtes de paquet

Les paquets envoyés par le serveur vers le conteneur commencent + par 0x1234. Les paquets envoyés par le conteneur vers + le serveur commencent par AB (c'est à dire le code + ASCII de A suivi du code ASCII de B). Ensuite, vient un entier (codé + comme ci-dessus) représentant la longueur des données transmises. + Bien que ceci puisse faire croire que la taille maximale des données + est de 2^16, le code définit en fait ce maximum à 8K.

+ + + + + + + + + + + + + + + + + + + +

Format du paquet (Serveur->Conteneur)
Octet	0	1	2	3	4...(n+3)
Contenu	0x12	0x34	Taille des données (n)		Data

+ + + + + + + + + + + + + + + + + + + +

Format du paquet (Conteneur->Serveur)
Octet	0	1	2	3	4...(n+3)
Contenu	A	B	Taille des données (n)		Data

Pour la plupart des paquets, le premier octet de la charge utile + encode le type de message, à l'exception des paquets contenant un + corps de requête envoyés du serveur vers le conteneur -- ils + comportent un en-tête standard (0x1234 suivi de la taille + du paquet), mais celui-ci n'est suivi d'aucun préfixe.

Le serveur web peut envoyer les messages suivants au conteneur + de servlets :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Code	Type de paquet	Signification
2	Fait suivre la requête	Débute le cycle de traitement de la requête avec les données + qui suivent.
7	Arrêt	Le serveur web demande au conteneur de s'arrêter.
8	Ping	Le serveur web demande au conteneur de prendre le contrôle + (phase de connexion sécurisée).
10	CPing	Le serveur web demande au conteneur de répondre rapidement + avec un CPong. +
none	Données	Taille (2 octets) et les données correspondantes.

À des fins de sécurité, le conteneur n'effectuera réellement son + Arrêt que si la demande provient de la machine par + laquelle il est hébergé.

Le premier paquet Données est envoyé immédiatement + après le paquet Faire suivre la requête par le serveur + web.

Le conteneur de servlets peut envoyer les types de messages + suivants au serveur web :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Code	Type de paquet	Signification
3	Envoi d'un tronçon de corps	Envoi d'un tronçon de corps depuis le conteneur de servlets + vers le serveur web (et probablement vers le navigateur).
4	Envoie les en-têtes	Envoi des en-têtes de réponse depuis le conteneur de + servlets vers le serveur web (et probablement vers le + navigateur).
5	Fin de la réponse	Marque la fin de la réponse (et par conséquent du cycle de + traitement de la requête). +
6	Réception du tronçon de corps suivant	Réception de la suite des données de la requête si elles + n'ont pas encore été entièrement transmises.
9	Réponse CPong	La réponse à une requête CPing

Chacun des messages ci-dessus possède une structure interne + différente dont vous trouverez les détails ci-dessous.

+ +

Structure des paquets de +requête

Pour les messages de type Faire suivre la requête depuis + le serveur vers le conteneur :

+AJP13_FORWARD_REQUEST :=
+    prefix_code      (byte) 0x02 = JK_AJP13_FORWARD_REQUEST
+    method           (byte)
+    protocol         (string)
+    req_uri          (string)
+    remote_addr      (string)
+    remote_host      (string)
+    server_name      (string)
+    server_port      (integer)
+    is_ssl           (boolean)
+    num_headers      (integer)
+    request_headers *(req_header_name req_header_value)
+    attributes      *(attribut_name attribute_value)
+    request_terminator (byte) OxFF
+

Les request_headers possèdent la structure suivante + : +

+req_header_name :=
+    sc_req_header_name | (string)  [voir ci-dessous pour la manière dont
+    ceci est interprété]
+
+sc_req_header_name := 0xA0xx (integer)
+
+req_header_value := (string)
+

Les attributes sont optionnels et possèdent la + structure suivante :

+attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)
+
+

Un des en-têtes les plus importants est + content-length, car il indique si le conteneur doit ou + non attendre un autre paquet immédiatement.

Description détaillée de la requête que le serveur + fait suivre vers le conteneur +

Préfixe de la requête

Pour toutes les requêtes, ce préfixe est 2. Voir ci-dessus pour + les détails des autres codes de préfixes.

+ +

Méthode

La méthode HTTP, encodée sous la forme d'un seul octet :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Nom commande	Code
OPTIONS	1
GET	2
HEAD	3
POST	4
PUT	5
DELETE	6
TRACE	7
PROPFIND	8
PROPPATCH	9
MKCOL	10
COPY	11
MOVE	12
LOCK	13
UNLOCK	14
ACL	15
REPORT	16
VERSION-CONTROL	17
CHECKIN	18
CHECKOUT	19
UNCHECKOUT	20
SEARCH	21
MKWORKSPACE	22
UPDATE	23
LABEL	24
MERGE	25
BASELINE_CONTROL	26
MKACTIVITY	27

Les versions futures d'ajp13 pourront transmettre des méthodes + supplémentaires, même si elles ne font pas partie de cette + liste.

+ +

protocol, req_uri, remote_addr, remote_host, server_name, + server_port, is_ssl

Les significations de ces éléments sont triviales. Ils sont tous + obligatoires et seront envoyés avec chaque requête.

+ +

En-têtes

La structure de request_headers est la suivante + : tout d'abord, le nombre d'en-têtes num_headers est + encodé, suivi d'une liste de paires nom d'en-tête + req_header_name / valeur req_header_value. + Les noms d'en-têtes courants sont codés sous forme d'entiers afin de + gagner de la place. Si le nom d'en-tête ne fait partie de la liste + des en-têtes courants, il est encodé normalement (une chaîne de + caractères préfixée par la taille). La liste des en-têtes courants + sc_req_header_name avec leurs codes se présente comme + suit (il sont tous sensibles à la casse) :

+ + + + + + + + + + + + + + + + + + + +

Nom	Valeur du code	Nom du code
accept	0xA001	SC_REQ_ACCEPT
accept-charset	0xA002	SC_REQ_ACCEPT_CHARSET +
accept-encoding	0xA003	SC_REQ_ACCEPT_ENCODING +
accept-language	0xA004	SC_REQ_ACCEPT_LANGUAGE +
authorization	0xA005	SC_REQ_AUTHORIZATION
connection	0xA006	SC_REQ_CONNECTION
content-type	0xA007	SC_REQ_CONTENT_TYPE
content-length	0xA008	SC_REQ_CONTENT_LENGTH
cookie	0xA009	SC_REQ_COOKIE
cookie2	0xA00A	SC_REQ_COOKIE2
host	0xA00B	SC_REQ_HOST
pragma	0xA00C	SC_REQ_PRAGMA
referer	0xA00D	SC_REQ_REFERER
user-agent	0xA00E	SC_REQ_USER_AGENT

Le code Java qui lit ceci extrait l'entier représenté par les + deux premiers octets, et si le premier octet est + '0xA0', il utilise l'entier représenté par le deuxième + octet comme index d'un tableau de noms d'en-têtes. Si le premier + octet n'est pas 0xA0, l'entier représenté par les deux + octets est considéré comme la longueur d'une chaîne qui est alors + lue.

Ceci ne peut fonctionner que si aucun nom d'en-tête ne possède + une taille supérieure à 0x9999 (==0xA000 - 1), ce qui + est vraisemblable, bien qu'un peu arbitraire.

Note:

+ L'en-tête content-length est extrêmement important. + S'il est présent et non nul, le conteneur considère que la requête + possède un corps (une requête POST, par exemple), et lit + immédiatement le paquet suivant dans le flux d'entrée pour extraire + ce corps. +

+ +

Attributs

Les attributs préfixés par ? (par exemple + ?context) sont tous optionnels. Chacun d'eux est + représenté par un octet correspondant au type de l'attribut et par + sa valeur (chaîne ou entier). Ils peuvent être envoyés dans un ordre + quelconque (bien que le code C les envoie dans l'ordre ci-dessous). + Un code de terminaison spécial est envoyé pour signaler la fin de la + liste des attributs optionnels. La liste des codes est la suivante + :

+ + + + + + + + + + + + + + +

Information	Valeur code	Type de valeur	Note
?context	0x01	-	Non implémenté + actuellement +
?servlet_path	0x02	-	Non implémenté + actuellement +
?remote_user	0x03	String
?auth_type	0x04	String
?query_string	0x05	String
?jvm_route	0x06	String
?ssl_cert	0x07	String
?ssl_cipher	0x08	String
?ssl_session	0x09	String
?req_attribute	0x0A	String	Nom (le + nom de l'attribut vient ensuite)
?ssl_key_size	0x0B	Integer
are_done	0xFF	-	request_terminator

context et servlet_path ne sont pas + définis actuellement par le code C, et la majorité du code Java + ignore complètement ce qui est envoyé par l'intermédiaire de ces + champs (il va même parfois s'interrompre si une chaîne est + envoyée après un de ces codes). Je ne sais pas si c'est une bogue ou + une fonctionnalité non implémentée, ou tout simplement du code + obsolète, mais en tout cas, il n'est pris en charge par aucune des + deux extrémités de la connexion.

remote_user et auth_type concernent + probablement l'authentification au niveau HTTP, et contiennent le + nom de l'utilisateur distant ainsi que le type d'authentification + utilisée pour établir son identité (à savoir Basic, Digest).

query_string, ssl_cert, + ssl_cipher et ssl_session contiennent les + éléments HTTP et HTTPS correspondants.

jvm_route est utilisé dans le cadre des sessions + persistantes, en associant une session utilisateur à une instance + Tomcat particulière en présence de plusieurs répartiteurs de + charge.

Au delà de cette liste de base, tout autre attribut + supplémentaire peut être envoyé via le code + req_attribute 0x0A. Une paire de chaînes + représentant le nom et la valeur de l'attribut est envoyée + immédiatement après chaque instance de ce code. Les variables + d'environnement sont transmises par cette méthode.

Enfin, lorsque tous les attributs ont été transmis, le + terminateur d'attributs, 0xFF, est envoyé. Ce dernier + indique à la fois la fin de la liste d'attributs et la fin du paquet + de la requête

+ +

Structure du paquet de la +réponse

Pour les messages que le conteneur peut renvoyer au + serveur.

+AJP13_SEND_BODY_CHUNK :=
+  prefix_code   3
+  chunk_length  (integer)
+  chunk        *(byte)
+  chunk_terminator (byte) Ox00
+
+
+AJP13_SEND_HEADERS :=
+  prefix_code       4
+  http_status_code  (integer)
+  http_status_msg   (string)
+  num_headers       (integer)
+  response_headers *(res_header_name header_value)
+
+res_header_name :=
+    sc_res_header_name | (string)   [voir ci-dessous pour la manière
+    dont ceci est interprété]
+
+sc_res_header_name := 0xA0 (byte)
+
+header_value := (string)
+
+AJP13_END_RESPONSE :=
+  prefix_code       5
+  reuse             (boolean)
+
+
+AJP13_GET_BODY_CHUNK :=
+  prefix_code       6
+  requested_length  (integer)
+

Détails:

Envoi d'un tronçon de corps

Le tronçon se compose essentiellement de données binaires et est + renvoyé directement au navigateur.

+ +

Envoi des en-têtes

Les code et message d'état correspondent aux code et message HTTP + habituels (par exemple 200 et OK). Les + noms d'en-têtes de réponses sont codés de la même façon que les noms + d'en-têtes de requêtes. Voir ci-dessus le codage des en-têtes pour + plus de détails à propos de la manière dont les codes se distinguent + des chaînes.
+ Les codes des en-têtes courants sont ::

+ + + + + + + + + + + + + +

Nom	Valeur code
Content-Type	0xA001
Content-Language	0xA002
Content-Length	0xA003
Date	0xA004
Last-Modified	0xA005
Location	0xA006
Set-Cookie	0xA007
Set-Cookie2	0xA008
Servlet-Engine	0xA009
Status	0xA00A
WWW-Authenticate	0xA00B

La valeur de l'en-tête est codée immédiatement après le code ou + la chaîne du nom d'en-tête.

+ +

Fin de la réponse

Signale la fin de ce cycle de traitement de requête. Si le + drapeau reuse est à true (==1), cette + connexion TCP peut être réutilisée pour traiter de nouvelles + requêtes entrantes. Si reuse est à false (toute autre + valeur que 1 dans le véritable code C), la connexion sera + fermée.

+ +

Réception d'un tronçon de corps

Le conteneur réclame la suite des données de la requête (dans le + cas où la taille du corps était trop importante pour pouvoir être + contenue dans le premier paquet envoyé, où lorsque la requête est + fractionnée). Le serveur va alors envoyer un paquet contenant une + quantité de données correspondant au minimum de la + request_length, la taille maximale de corps envoyée + (8186 (8 Koctets - 6)), et le nombre réel d'octets + restants à envoyer pour ce corps de requête.
+ S'il ne reste plus de données à transmettre pour ce corps de requête + (c'est à dire si le conteneur de servlets tente de lire au delà de + la fin du corps), le serveur va renvoyer un paquet vide + dont la charge utile est de longueur 0 et se présentant sous la + forme (0x12,0x34,0x00,0x00).

+ +

Structure des paquets de +requête +

Pour les messages de type Faire suivre la requête depuis + le serveur vers le conteneur :

+AJP13_FORWARD_REQUEST :=
+    prefix_code      (byte) 0x02 = JK_AJP13_FORWARD_REQUEST
+    method           (byte)
+    protocol         (string)
+    req_uri          (string)
+    remote_addr      (string)
+    remote_host      (string)
+    server_name      (string)
+    server_port      (integer)
+    is_ssl           (boolean)
+    num_headers      (integer)
+    request_headers *(req_header_name req_header_value)
+    attributes      *(attribut_name attribute_value)
+    request_terminator (byte) OxFF
+

Les request_headers possèdent la structure suivante + : +

+req_header_name :=
+    sc_req_header_name | (string)  [voir ci-dessous pour la manière dont
+    ceci est interprété]
+
+sc_req_header_name := 0xA0xx (integer)
+
+req_header_value := (string)
+

Les attributes sont optionnels et possèdent la + structure suivante :

+attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)
+
+

Un des en-têtes les plus importants est + content-length, car il indique si le conteneur doit ou + non attendre un autre paquet immédiatement.

Description détaillée de la requête que le serveur + fait suivre vers le conteneur +

Préfixe de la requête +

Pour toutes les requêtes, ce préfixe est 2. Voir ci-dessus pour + les détails des autres codes de préfixes.

Méthode +

La méthode HTTP, encodée sous la forme d'un seul octet :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Nom commande	Code
OPTIONS	1
GET	2
HEAD	3
POST	4
PUT	5
DELETE	6
TRACE	7
PROPFIND	8
PROPPATCH	9
MKCOL	10
COPY	11
MOVE	12
LOCK	13
UNLOCK	14
ACL	15
REPORT	16
VERSION-CONTROL	17
CHECKIN	18
CHECKOUT	19
UNCHECKOUT	20
SEARCH	21
MKWORKSPACE	22
UPDATE	23
LABEL	24
MERGE	25
BASELINE_CONTROL	26
MKACTIVITY	27

Les versions futures d'ajp13 pourront transmettre des méthodes + supplémentaires, même si elles ne font pas partie de cette + liste.

protocol, req_uri, remote_addr, remote_host, server_name, + server_port, is_ssl +

Les significations de ces éléments sont triviales. Ils sont tous + obligatoires et seront envoyés avec chaque requête.

En-têtes +

+ + + + + + + + + + + + + + + + + + + +

Nom	Valeur du code	Nom du code
accept	0xA001	SC_REQ_ACCEPT
accept-charset	0xA002	SC_REQ_ACCEPT_CHARSET +
accept-encoding	0xA003	SC_REQ_ACCEPT_ENCODING +
accept-language	0xA004	SC_REQ_ACCEPT_LANGUAGE +
authorization	0xA005	SC_REQ_AUTHORIZATION
connection	0xA006	SC_REQ_CONNECTION
content-type	0xA007	SC_REQ_CONTENT_TYPE
content-length	0xA008	SC_REQ_CONTENT_LENGTH
cookie	0xA009	SC_REQ_COOKIE
cookie2	0xA00A	SC_REQ_COOKIE2
host	0xA00B	SC_REQ_HOST
pragma	0xA00C	SC_REQ_PRAGMA
referer	0xA00D	SC_REQ_REFERER
user-agent	0xA00E	SC_REQ_USER_AGENT

Ceci ne peut fonctionner que si aucun nom d'en-tête ne possède + une taille supérieure à 0x9999 (==0xA000 - 1), ce qui + est vraisemblable, bien qu'un peu arbitraire.

+ Note: + L'en-tête content-length est extrêmement important. + S'il est présent et non nul, le conteneur considère que la requête + possède un corps (une requête POST, par exemple), et lit + immédiatement le paquet suivant dans le flux d'entrée pour extraire + ce corps. + +

Attributs +

+ + + + + + + + + + + + + + +

Information	Valeur code	Type de valeur	Note
?context	0x01	-	Non implémenté + actuellement +
?servlet_path	0x02	-	Non implémenté + actuellement +
?remote_user	0x03	String
?auth_type	0x04	String
?query_string	0x05	String
?jvm_route	0x06	String
?ssl_cert	0x07	String
?ssl_cipher	0x08	String
?ssl_session	0x09	String
?req_attribute	0x0A	String	Nom (le + nom de l'attribut vient ensuite)
?ssl_key_size	0x0B	Integer
are_done	0xFF	-	request_terminator

query_string, ssl_cert, + ssl_cipher et ssl_session contiennent les + éléments HTTP et HTTPS correspondants.

jvm_route est utilisé dans le cadre des sessions + persistantes, en associant une session utilisateur à une instance + Tomcat particulière en présence de plusieurs répartiteurs de + charge.

Module Apache mod_substitute

Langues Disponibles: en | + fr

+ + + + +

Description:	Effectue des opérations de recherche/remplacement sur les +corps de réponses
Statut:	Extension
Identificateur de Module:	substitute_module
Fichier Source:	mod_substitute.c
Compatibilité:	Disponible depuis la version 2.2.7 +du serveur HTTP Apache

Sommaire

+ +

mod_substitute fournit un mécanisme permettant + d'effectuer des substitutions de chaînes fixes ou d'expressions + rationnelles sur les corps de réponses.

Directives

Substitute

Commentaires

+ +

Substitute Directive

+ + + + + + + +

Description:	Modèle de substition dans le contenu de la +réponse
Syntaxe:	`Substitute s/modèle/substitution/[infq]`
Contexte:	répertoire, .htaccess
AllowOverride:	FileInfo
Statut:	Extension
Module:	mod_substitute

La directive Substitute permet de + spécifier un modèle de recherche/remplacement à appliquer au corps + de la réponse.

+ +

La signification du modèle peut être modifiée via toute + combinaison de ces drapeaux :

+ +

i: Effectue une comparaison sans tenir compte de la casse.
n: Par défaut, le modèle est traité en tant qu'expression + rationnelle. Le drapeau n force le traitement du + modèle en tant que chaîne fixe.
f: Avec le drapeau f, mod_substitute met à plat le + résultat d'une substitution (les conteneurs ou buckets ne sont + pas dissociés), ce qui permet à d'éventuelles substitutions + ultérieures de s'effectuer sur cette dernière. C'est le + comportement par défaut.
q: Avec le drapeau q, mod_substitute dissocie les + conteneurs (ou buckets) après chaque substitution. Ceci peut + améliorer la rapidité de la réponse et diminuer la quantité de + mémoire utilisée, mais ne doit être utilisé que s'il n'existe + aucune possibilité pour que le résultat d'une substitution ne + corresponde au modèle ou à l'expression rationnelle d'une + substitution ultérieure.

+ +

Exemple

+<Location />
+    AddOutputFilterByType SUBSTITUTE text/html
+    Substitute s/foo/bar/ni
+</Location>
+

+ +

Si le modèle ou la chaîne de substitution contient un caractère + slash '/', il faut utiliser un autre délimiteur :

+ +

Exemple d'utilisation d'un délimiteur + alternatif

+<Location />
+    AddOutputFilterByType SUBSTITUTE text/html
+    Substitute "s|<BR */?>|<br />|i"
+</Location>
+

+ +

Lorsqu'on utilise des expressions rationnelles, on peut insérer + des références arrières dans les opérations de comparaison et de + substitution, comme illustré dans l'exemple suivant :

Exemple d'utilisation de références arrières et de captures

+<Location />
+    AddOutputFilterByType SUBSTITUTE text/html
+    # "foo=k,bar=k" -> "foo/bar=k"
+    Substitute "s|foo=(\w+),bar=\1|foo/bar=$1"
+</Location>
+

+ +

Un scénario courant d'utilisation de mod_substitute + est la situation où un serveur frontal mandate des requêtes pour un + serveur d'arrière-plan qui renvoie des documents HTML contenant des + URLs intégrées codées en dur qui font référence à ce serveur + d'arrière-plan. Ces URLs ne fonctionnent pas pour l'utilisateur + final car le serveur d'arrière-plan est hors d'atteinte.

+ +

On peut, dans ce cas, utiliser mod_substutite pour + réécrire ces URLs afin qu'elles soit utilisables dans la partie + située derrière le mandataire :

+ +

Réécriture des URLs intégrées à un contenu mandaté

+ProxyPass /blog/ http://internal.blog.example.com
+ProxyPassReverse /blog/ http://internal.blog.example.com/
+
+Substitute "s|http://internal.blog.example.com/|http://www.example.com/blog/|i"
+

+ +

La directive ProxyPassReverse modifie tout en-tête + Location (redirection) envoyé par le serveur + d'arrière-plan et, dans cet exemple, la directive + Substitute se charge à son tour de la modification de + la réponse HTML.

+ + +

Module Apache mod_allowmethods

Sommaire

Directives

Avertissement

Module Apache mod_authz_dbd

Sommaire

Directives

Sujets

Voir aussi

Module Apache mod_authz_dbm

Sommaire

Directives

Voir aussi

Sécurité

Module Apache mod_authz_groupfile

Sommaire

Directives

Voir aussi

Exemple :

Sécurité

Module Apache mod_proxy_ajp

Sommaire

Avertissement

Directives

Sujets

Voir aussi

Mandataire inverse simple

Mandataire inverse avec répartiteur de charge

Réécriture d'un chemin mandaté

Taille du paquet

En-têtes de paquet

Description détaillée de la requête que le serveur + fait suivre vers le conteneur +

Préfixe de la requête

Méthode

protocol, req_uri, remote_addr, remote_host, server_name, + server_port, is_ssl

En-têtes

Note:

Attributs

Détails:

Envoi d'un tronçon de corps

Envoi des en-têtes

Fin de la réponse

Réception d'un tronçon de corps

Module Apache mod_substitute

Sommaire

Directives

Exemple

Exemple d'utilisation d'un délimiteur + alternatif

Exemple d'utilisation de références arrières et de captures

Réécriture des URLs intégrées à un contenu mandaté