From: Lucien Gentis Le module Le module mod_cache
s'appuie sur des
- implémentations de stockage en arrière-plan spécifiques pour gérer
+ implémentations de stockage sous-jacentes spécifiques pour gérer
le cache ; à ce titre, mod_cache_disk
fournit le
support de la mise en cache sur disque.mod_authn_socache
permet la mise en
cache des données issues d'une authentification, diminuant ainsi
- la charge des serveurs d'authentification en arrière-plan.
Dans l'exemple suivant, on force le module à traiter les paquets de - données en provenance de l'arrière-plan du FCGI dès leur réception, sans les + données en provenance du serveur FCGI d'arrière-plan dès leur réception, sans les faire transiter par un tampon.
ProxyPassMatch "^/myapp/.*\.php(/.*)?$" "fcgi://localhost:9000/var/www/" enablereuse=on flushpackets=on
L'exemple suivant est similaire au précédent avec une différence : ici, - les données en provenance de l'arrière-plan du FCGI sont traitées après un + les données en provenance du serveur FCGI d'arrière-plan sont traitées après un temps de valeur fixe (elles sont mises en tampon). Cette méthode est - utile si l'arrière-plan du FCGI envoie ses données sous forme + utile si le serveur FCGI d'arrière-plan envoie ses données sous forme de petits paquets, auquel cas le traitement immédiat de chacun d'entre eux serait inefficace et couteux en ressources. Notez que cet exemple ne sera peut-être pas adapté dans le cas où l'envoi de paquets de données par @@ -190,8 +190,9 @@ fournisseur du protocole FCGI :
mod_proxy_fcgi
ne créera jamais
- ni n'exportera la variable d'environnement PATH_INFO,
+ ProxyPass
ou ProxyPassMatch
,
+ mod_proxy_fcgi
ne définit pas la variable
+ d'environnement PATH_INFO,
ce qui permet au serveur FCGI d'arrière-plan de déterminer
correctement SCRIPT_NAME et Script-URI, et
de se conformer à la section 3.3 de la RFC 3875. Si au contraire