Re: New translation httpd-docs-1.3/htdocs/manual/bind.html.fr

[Herve Dumont]

If there is no remarks, can some one commit the files
BTW here are five new translations.
These translations are coming from Valery Fremaux :

httpd-docs-1.3/htdocs/manual/dns-caveats.html.fr
httpd-docs-1.3/htdocs/manual/custom-error.html.fr
httpd-docs-1.3/htdocs/manual/cgi_path.html.fr
httpd-docs-1.3/htdocs/manual/mod/directives.html.fr
httpd-docs-1.3/htdocs/manual/mod/directives-dict.html.fr

----- Message d'origine -----
De : Herve Dumont
� : [EMAIL PROTECTED]
Envoy� : dimanche 1 avril 2001 10:37
Objet : New translation httpd-docs-1.3/htdocs/manual/bind.html.fr



bind.html should be renamed and bind.html.html created.

Herve





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Title: Apache et le DNS

Apache et le DNS Cette page aurait pu être résumée par la phrase : ne demandez pas à Apache d'utiliser le DNS pour la lecture des fichiers de configuration. Si appache doit utiliser le DNS pour récupérer ses fichiers de configuration, alors votre serveur peut être sujet à des problèmes de fiabilité (il peut tout simplement ne pas démarrer), ou s'ouvrir à des attaques et des vols d'information (y compris des utilisateurs qui pourraient "voler" des hits d'autres utilisateurs). Un exemple simple Considérez ce court extrait de code de configuration : <VirtualHost www.abc.dom> ServerAdmin [EMAIL PROTECTED] DocumentRoot /www/abc </VirtualHost> Pour qu'Apache fonctionne correctement, il a absolument besoin d'au moins deux informations pour chaque hôte virtuel : le ServerName et au moins une adresse IP à laquelle ce serveur doit répondre. Cet exemple ne fait pas apparaître d'adresse IP ; Apache doit donc utiliser le DNS pour trouver l'adresse correspondant à www.abc.dom. Si pour telle ou telle raison, le service de noms de domaines n'est pas accessible au moment ou le serveur interprète ses fichiers de configuration, alors cet hôte virtuel ne pourra pas être configuré. Il ne pourra donc pas répondre aux requêtes émises vers cet hôte virtuel (les versions d'Apache antérieures à la 1.2 n'auraient même pas pu démarrer). Supposons que le doamine www.abc.dom ait pour adresse 10.0.0.1. Considérez alors ce nouvel extrait de code de configuration : <VirtualHost 10.0.0.1> ServerAdmin [EMAIL PROTECTED] DocumentRoot /www/abc </VirtualHost> Apache doit alors effectuer une résolution DNS inverse pour trouver le nom ServerName pour cet hôte virtuel. Si cette résolution échoue, alors il devra partiellement désactiver cet hôte virtuel (les versions d'Apache antérieures à la 1.2 n'auraient même pas démarré). Si l'hôte virtuel est basé sur un nom de domaine alors il sera totalement inhibé, si par contre il se base sur une adresse IP, alors il tournera probablement. Cependant, si Apache devait à générer une URL complète pour ce serveur, incluant le nom de domaine, l'URL produite ne pourrait être correctement constituée. Voici un extrait qui élimine ces deux problèmes. <VirtualHost 10.0.0.1> ServerName www.abc.dom ServerAdmin [EMAIL PROTECTED] DocumentRoot /www/abc </VirtualHost> Refus de service Il existe (au moins) deux situations où Apache refuse de fournir le service. Si vous exécutez une version antérieure à la version 1.2 d'Apache, votre serveur ne démarrera même pas si l'une des deux résolutions DNS mentionnées ci-avant échoue pour au moins un hôte virtuel. Dans certain cas, cette résolution peut ne même pas être sous votre contrôle. Par exemple, si abc.dom est l'un de vos clients, lequel contrôle son propre serveur DNS, ce dernier peut forcer votre serveur Apache (en version antérieure à 1.2) à s'arrêter au démarrage en supprimant simplement l'enregistrement du nom www.abc.dom. Une autre situation est beaucoup plus pernicieuse. Considérez cet extrait de code de configuration : <VirtualHost www.abc.dom> ServerAdmin [EMAIL PROTECTED] DocumentRoot /www/abc </VirtualHost> <VirtualHost www.def.dom> ServerAdmin [EMAIL PROTECTED] DocumentRoot /www/def </VirtualHost> Supposez que vous avez assigné 10.0.0.1 au domaine www.abc.dom et 10.0.0.2 au domaine www.def.dom. De plus, supposez que def.com contrôle son propre service DNS. Avec la précédente configuration, vous permettez à def.com de "voler" tout le trafic destiné à abc.com. Tout ce qu'ils auraient à faire pour y parvenir est d'assigner www.def.dom à l'adresse 10.0.0.1. Dans la mesure où ils contrôlent leur propre DNS, vousne pouvez les empêcher de piéger leur enregistrement de www.def.com. Les requêtes arrivant pour 10.0.0.1 (y compris toutes celles où les utilisateurs auront tapé une URL de la forme http://www.abc.dom/qqchose) seront toutes servies par l'hôte virtuel def.com. Mieux comprendre comment cela est possible demande une discussion plus détaillée sur la manière dont Apache traite des requêtes arrivant pour des hôtes virtuels. Un premier document descrivant ceci est disponible. L'adresse du "serveur principal" L'addition du support d'hôtes virtuels basés sur les noms dans Apache 1.1 nécessite qu'Apache connaisse les adresses IP de l'hôte sur lequel est exécuté httpd. Pour obtenir cette adresse, il utilise soit le ServerName global (si défini) ou appelle la fonction C gethostname (qui renvoie une information similaire à celle donnée par la commande interactive "hostname"). Puis il procède à une résolution DNS pour cette adresse. Jusqu'à présent, il n'y a aucun moyen d'éviter cette résolution. Si vous craignez que cette résolution échoue parceque votre serveur DNS est arrêté, alors vous popuvez ajouter le nom d'hôte dans le fichier /etc/hosts (où il devrait normalement déjà figurer, ne serait-ce que pour assurer un démarrage correct de la machine). Vous devrez en outre vous assurer que votre machine est configurée pour exploiter le fichier /etc/hosts en cas d'échec d'une résolution dynamique. Suivant l'OS que vous utilisez, ceci peut être fait en éditant le code /etc/resolv.conf, ou peut être /etc/nsswitch.conf. Si votre machine n'a pas de résolution DNS à effectuer pour toute autre raison (par exemple parce qu'elle est isolée), alors vous pourrez néanmoins faire tourner Apache en initialisant la variable d'environnement HOSTRESORDER à "local". Tout ceci dépend de l'OS et des librairies de résolveur que vous utilisez. Les CGI sont également affectés CGIsauf si vous utilisez la fonctionnalité mod_env pour contrôler l'environnement. Il est prudent de consulter les pages de manuel ou les FAQ spécifiques à votre OS. Astuces pour éviter ces problèmes utilisez des adresses IP dans les sections <VirtualHost> utilisez des adresses IP dans la clause Listen utilisez des adresses IP dans la clause BindAddress assurez vous que tous les hôtes virtuels on un ServerName créez un serveur <VirtualHost _default_:*> qui ne sert aucune page. Appendice: Directions futures Cette situation vis-à-vis du DNS est largement insatisfaisante. Pour Apache 1.2, nous avons travaillé pour que le serveur puisse continuer à démarrer dans le cas de l'échec d'une résolution DNS, mais il est possible que nous puissions en faire plus. Toute écriture nécessitant l'usage d'adresses IP explicites dans le fichier de configuration n'est pas souhaitable dans le contexte Internet actuel où la rotation d'adresses est une nécessité. Une parade au vol de service serait d'effectuer une résolution DNS inverse sur l'adresse IP renvoyée par la résolution directe, et comparer les deux noms. En cas de non concordance, cet hôte virtuel serait désactivé. Ceci impliquerait que la résolution DNS inverse soit correctement configurée (ce qui reste assez connu des administrateurs du fait de l'usage commun de la résolution inverse double par les serveurs FTP et les transposeurs TCP). Dans tous les cas, il ne semble pas possible de garantir la fiabilité du démarrage d'un serveur web gérant des hôtes virtuels lorsque la résolution DNS a échoué, sauf si la définition de ces hôtes utilise des adresses IP explicites. Une solution partielle consistant à ignorer certaines portions du fichier de configuration serait encore pire que ne pas démarrer du tout, dans certains cas d'exploitation. Par l'extension de l'usage de HTTP/1.1, les navigateurs et proxies fournissent de plus en plus souvent l'en-tête Host, et il deviendra possible d'éviter totalement la définition d'hôtes virtuels basés sur des adresses IP. Dans ce cas, un serveur Web n'aura plus de résolution DNS à effectuer pendant la configuration. Mais à la date de Mars 1997, ces fonctionnalités n'ont pas été suffisament largement déployées pourpouvoir être exploitées par des serveurs en situation critique.

Title: Messages d'erreur personnalisés

Messages d'erreur personnalisés But Fonctionnalité additionnelle. Permet aux administrateurs Web de personnaliser les réponses donn�es par Apache en cas de problèmes. Les réponses personnalisées définies peuvent être activables lorsque le serveur est à même de détecter la cause du problème. ex. si un script termine en faute, produisant une réponse "500 Server Error", alors cette réponse peut être remplacée soit par un texte quelque peu plus explicatif soit par une redirection vers une autre URL (locale ou externe). Ancien comportement La version 1.3 d'httpd du NCSA répondait souvent avec des messages d'erreur ennuyeux et peu amènes qui �taient sans signification pour l'utilisateur, et ne donnait pas les symptômes qui pouvaient causer la faute. Nouveau comportement On pourra désormais demander au serveur : D'afficher un autre texte, plutôt que les messages standard NCSA, ou rediriger l'utilisateur vers une URL locale, ou encore rediriger l'utilisateur vers une URL sur un autre serveur. La redirection vers une autre URL peut être utile, mais seulement si certaines informations peuvent être passées et qui serviront à produire un affichage ou un enregistrement du problème plus clair et explicite. Pour ce faire, Apache définira de nouvelles variables d'environnement ( à la mode CGI), ex. REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712) REDIRECT_PATH=.:/bin:/usr/local/bin:/etc REDIRECT_QUERY_STRING= REDIRECT_REMOTE_ADDR=121.345.78.123 REDIRECT_REMOTE_HOST=ooh.ahhh.com REDIRECT_SERVER_NAME=crash.bang.edu REDIRECT_SERVER_PORT=80 REDIRECT_SERVER_SOFTWARE=Apache/0.8.15 REDIRECT_URL=/cgi-bin/buggy.pl notez le préfixe REDIRECT_. Seront au moins passés à la nouvelle URL les variables REDIRECT_URL et REDIRECT_QUERY_STRING (en supposant que l'URL de redirection est un script CGI ou un Include CGI). Les autres variables n'existeront que si elles existaient déjà avant l'apparition du problème. Aucune de ces deux variables ne sera initialisée si votre Document d'erreur est le résultat d'une redirection externe (c-à-d. toute adresse commençant par le nom d'un plan de protocole comme http:, même si le protocole invoqué aboutit sur le même hôte que le serveur à l'origine de la redirection). Configuration L'utilisation des documents "ErrorDocument" est autorisée dans les fichiers .htaccess lorsque la surcharge "FileInfo" est active. En voici quelques exemples... ErrorDocument 500 /cgi-bin/crash-recover ErrorDocument 500 "Désolé, votre script s'est vautré. Fichtre ErrorDocument 500 http://xxx/ ErrorDocument 404 /Lame_excuses/not_found.html ErrorDocument 401 /Subscription/how_to_subscribe.html La syntaxe admise est : ErrorDocument <code � trois chiffres> action dans laquelle l'action peut être : Le texte devant être affiché. Le texte devra être préfixé par un guillemet ("). Tout ce qui suit le guillemet sur la ligne est affiché. Notez : le préfixe (") lui-même n'est pas affiché. Une URL externe de redirection. Une URL locale de redirection. Redirections et affichage d'erreurs personnalisées But Le comportement d'Apache lorsqu'il redirige des URL a été modifié afin que d'autres variables d'environnement additionnelles puissent être rendues accessibles par un script/server-include. Ancien comportement Les variables CGI standard étaient transmises au script vers lequel était redirigé le client. Aucune indication n'était transmise quant à qui redirigeait le message. Nouveau comportement Un nouvel ensemble de variables d'environnement sera initialisé, à l'intention du script vers lequel le client a été redirigé. Chaque nouvelle variable de cet ensemble est préfixée par REDIRECT_. Les variables d'environnement de type REDIRECT_ sont créées à partir des variables d'environnement CGI qui existaient avant que n'intervienne la redirection, en leur rajoutant le préfixe. Par exemple HTTP_USER_AGENT devient REDIRECT_HTTP_USER_AGENT. En plus de ces variables, Apache définit les variables REDIRECT_URL et REDIRECT_STATUS pour aider le script à identifier l'origine de la redirection. Dans la trace d'accès déduite peuvent apparaître l'URL initiale ainsi que l'URL vers laquelle est redirigée la requête. Si la directive ErrorDocument sp�cifie une redirection local vers un script CGI, le script devra inclure un champ "Status:" dans l'en-t�te de sa sortie afin de garantir la retransmiison compl�te vers le client des conditions d'erreurs qui ont caus� son invocation. Par exemple un script Perl devrait inclure les lignes suivantes : : print "Content-type: text/html\n"; printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; : Si le script est d�di� pour trait� une condition d'erreur particuli�re telle que 404 Not Found, il peut utiliser le code sp�cifique et le message d'erreur � la place.

Title: Termes utilis�s pour d�crire les directives Apache

Termes utilis�s pour d�crire les directives Apache Chaque directive de configuration d'Apache est d�crite selon un format de pr�sentation commun ressemblant � ceci : Syntaxe: nomDirective arguments D�faut: nomDirective valeursParD�faut Contexte: listeDeContextes Surcharge: DirectivesSurcharg�es Statut: statut Module: nomModule Compatibilit�: notes concernant la compatibilit� Chacun des attributs possibles pour les directives, avec toutes leurs valeurs possibles sont d�crites dans ce document. Termes employ�s pour les directives Syntaxe D�faut Contexte Surcharge Statut Module Compatibilit� Syntaxe Indique le format dans laquelle la directive doit �tre inscrite dans les fichiers de configuration. Cette syntaxe est tr�s sp�cifique pour chaque directive, et est d�crite en d�tail dans la d�finition de la directive. G�n�ralement, le nom de la directive est suivi d'un ou de plusieurs arguments. Les arguments optionnels sont entour�s de crochets Quand un argument peut prendre plus d'une valeur possible, les valeurs possibles sont s�par�es par une barre verticale. Les valeurs litt�rales sont affich�e avec la fontes par d�faut, tandis qur les type d'arguments pour lesquels une substitution doit �tre faite sont en italique. Les diretrives pouvant avoir un nombre variable d'arguments se terminent avec "..." indiquant que le dernier argument se r�p�te. D�faut Si la directive a une valeur par d�faut (c-�-d., si elle n'apparait pas du tout dans le fichier de configuration, le serveur Apache se comportera comme si cette directive avait �t� �crite en mentionnant cette valeur), elle est sp�cifi�e ici. Si aucune valeur n'est d�finie par d�faut, cette section pr�cisera "Non pr�cis�". Contexte Indique l� ou l'implantation de la directive dans le fichier de configuration est licite. Il est exprim� comme une liste s�par�e par des virgules, et pouvant contenir les �l�ments suivants : configuration serveur La directive peut �tre utilis�e dans le fichier de configuration du serveur (ex., httpd.conf, srm.conf, et access.conf), mais dans aucune des sections int�rieures des containers <VirtualHost> ni <Directory>. Elle n'est pas permise dans aucun des fichiers .htaccess. h�te virtuel Dans ce contexte, la directive peut appara�tre dans les containers <VirtualHost> �crits dans les fichiers de configuration du serveur. r�pertoire La directive peut appara�tre dans les containers <Directory> �crits dans les fichiers de configuration du serveur. .htaccess La directive peut appara�tre dans les fichiers .htaccess situ� dans chacun des r�pertoires. Elle peut ou ne pas �tre interpr�t�e, suivant la configuration des directives de surcharge. Les directives ne sont autoris�es que dans les contextes cit�s ; si vous essayez de les �crire ailleurs, vous provoquerez une erreur de configuration qui soit conduira le serveur � ignorer les requ�tes dans le contexte sp�cifi�, soit peut emp�cher le serveur de fonctionner -- c-�-d., le serveur refusera de d�marrer. Les emplacements valides pour les directives sont le r�sultat d'un OU bool�en de tous les contextes cit�s. En d'autres termes, une directive marqu�e comma �tant valide dans le contexte "configuration serveur, .htaccess" peut �tre utilis�e dans le fichier httpd.conf et dans les fichiers .htaccess, mais pas dans le container <Directory> ni <VirtualHost>. Surcharge Cet attribut de directive pr�cise quelle surcharge doit �tre permise pour que la directive puisse �tre interpr�t�e lorsqu'elle appara�t dans un fichier .htaccess. Si le contexte de directive ne permet pas une �criture dans les fichiers .htaccess, cet attribut doit mentionner "Non applicable". Les surcharges sont g�r�es par la directive AllowOverrides, et ont une port�e d�finie, par exemple un r�pertoire donn� et tous ses descendants, sauf si la configuration de surcharge est chang�e � un endroit de la descendance par une directive AllowOverrides d'un niveau inf�rieur. La documentation pour cette directive liste aussi les noms possibles de surcharges disponibles. Statut Indique � quel module du serveur Apache Web la directive est rattach�e ; en d'autres termes, vous devrez peut �tre recompiler le serveur en pr�cisant un ensemble plus large de modules pour pouvoir b�n�ficier de cette fonctionnalit�. Les valeurs possibles pour cet attribut sont : Noyau Il s'agit d'une directive du noyau d'Apache et est de ce fait toujours disponible. Base La directive est impl�ment�e dans un module d'Apache faisant partie de l'ensemble de compilation de base, et est normalement disponible sauf si vous avez explicitement enlev� ce module � la compilation. Extension La directive est impl�ment�e par un module faisant partie de l'Apache Server Kit, mais ce module n'est pas compil� par d�faut. Pour activer cette directive, et rendre op�rationnelle cette fonctionnalit�, vous devrez modifier le fichier de configuration de compilation et recompiler Apache. Exp�rimental Le statut "Experimental" indique que la directive est disponible dans le Kit Apache, mais que vous ne pouvez l'utiliser qu'� vos risques et p�rils. La directive est document� dans un souci d'exhaustivit� mais n'est pas forc�ment support�e. Le module qui donne acc�s � cette directive peut �tre ou ne pas �tre compil� par d�faut ; reportez vous en t�te de la page qui d�crit la directive et le module pour toute remarque concernant sa disponibilit�. Module Donne simplement le nom du module ou est impl�ment�e cette fonctionnalit�. Compatibilit� Si la directive ne faisait pas partie de la version 1 d'Apache, le num�ro indique la version dans laquelle elle a �t� introduite. Si la directive a le m�me nom qu'une ancienne directive du serveur HTTPd du NCSA, toute diff�rence de comportement y sera mentionn�e. Dans les autres cas, cette rubrique affichera "Pas de remarques sur compatiblit�."

Title: Directives Apache

Directives Apache Chacune des directives Apache disponible dans la distribution standard est list�e ici. Elles sont d�crites selon un format pr�cis, et nous fournissons un dictionnaire des termes utilis�s pour leur description. AccessConfig AccessFileName Action AddAlt AddAltByEncoding AddAltByType AddCharset AddDefaultCharset AddDescription AddEncoding AddHandler AddIcon AddIconByEncoding AddIconByType AddLanguage AddModule AddModuleInfo AddType AgentLog Alias AliasMatch allow AllowCONNECT AllowOverride Anonymous Anonymous_Authoritative Anonymous_LogEmail Anonymous_MustGiveEmail Anonymous_NoUserID Anonymous_VerifyEmail AuthAuthoritative AuthDBAuthoritative AuthDBGroupFile AuthDBMAuthoritative AuthDBMGroupFile AuthDBMGroupFile AuthDBUserFile AuthDBMUserFile AuthDigestFile AuthGroupFile AuthName AuthType AuthUserFile BindAddress BrowserMatch BrowserMatchNoCase BS2000Account CacheDefaultExpire CacheDirLength CacheDirLevels CacheForceCompletion CacheGcInterval CacheLastModifiedFactor CacheMaxExpire CacheNegotiatedDocs CacheRoot CacheSize CheckSpelling ClearModuleList ContentDigest CookieExpires CookieLog (mod_cookies) CookieLog (mod_log_config) CookieTracking CoreDumpDirectory CustomLog DefaultIcon DefaultLanguage DefaultType deny <Directory> <DirectoryMatch> DirectoryIndex DocumentRoot EBCDICConvert EBCDICConvertByType EBCDICKludge ErrorDocument ErrorLog Example ExpiresActive ExpiresByType ExpiresDefault ExtendedStatus FancyIndexing <Files> <FilesMatch> ForceType Group Header HeaderName HostNameLookups IdentityCheck <IfDefine> <IfModule> ImapBase ImapDefault ImapMenu Include IndexIgnore IndexOptions IndexOrderDefault ISAPIReadAheadBuffer ISAPILogNotSupported ISAPIAppendLogToErrors ISAPIAppendLogToQuery KeepAlive KeepAliveTimeout LanguagePriority <Limit> <LimitExcept> LimitRequestBody LimitRequestFields LimitRequestFieldsize LimitRequestLine Listen ListenBacklog LoadFile LoadModule <Location> <LocationMatch> LockFile LogFormat LogLevel MaxClients MaxKeepAliveRequests MaxRequestsPerChild MaxSpareServers MetaDir MetaFiles MetaSuffix MimeMagicFile MinSpareServers MMapFile NameVirtualHost NoCache Options order PassEnv PidFile Port ProxyBlock ProxyDomain ProxyPass ProxyPassReverse ProxyReceiveBufferSize ProxyRemote ProxyRequests ProxyVia ReadmeName Redirect RedirectMatch RedirectPermanent RedirectTemp RefererIgnore RefererLog RemoveEncoding RemoveHandler RemoveType require ResourceConfig RewriteBase RewriteCond RewriteEngine RewriteLock RewriteLog RewriteLogLevel RewriteMap RewriteOptions RewriteRule RLimitCPU RLimitMEM RLimitNPROC Satisfy ScoreBoardFile Script ScriptAlias ScriptAliasMatch ScriptInterpreterSource ScriptLog ScriptLogBuffer ScriptLogLength SendBufferSize ServerAdmin ServerAlias ServerName ServerPath ServerRoot ServerSignature ServerTokens ServerType SetEnv SetEnvIf SetEnvIfNoCase SetHandler StartServers ThreadsPerChild TimeOut TransferLog TypesConfig UnsetEnv UseCanonicalName User UserDir <VirtualHost> VirtualDocumentRoot VirtualDocumentRootIP VirtualScriptAlias VirtualScriptAliasIP XBitHack

Title: Modification de PATH_INFO dans l'environnement CGI

Modification de PATH_INFO dans l'environnement CGI Vue d'ensemble Telle qu'elle �tait impl�ment�e dans les versions ant�rieures � la version 1.1.1 d'Apache (comprise), la m�thode utilis�e par Apache pour cr�er la variable PATH_INFO dans l'environnement CGI �tait loin d'�tre intuitive, et pouvait conduire � certaines d�faillances dans certains cas. A partir de la version 1.2 d'Apache, cette m�thode a �t� modifi�e. Bien que ces modifications puissent conduire � certaines incompatibilit�s avec certaines applications CGI, le comportement d'Apache 1.2 reste toujours compatible avec la sp�cification CGI/1.1, et les scripts CGI restent facilement modifiables (voir ci-dessous). Le Probl�me Les versions d'Apache jusqu'� 1.1.1 construisaient les variables d'environnement CGI PATH_INFO et SCRIPT_NAME en inspectant les noms de fichiers, et non les URL. Bien que cette technique conduise � des valeurs correctes dans la plupart des cas, il pouvait arriver que le chemin d�fini par le syst�me de fichiers soit surcharg� par une red�finition, laquelle conduisait � une mauvaise interpr�tation lors de la constitution des variables. Par exemple, si la ligne suivante apparaissait dans un fichier de configuration : Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph Dans ce cas, user.cgi d�signe le script CGI, la cha�ne "/ralph" est une information � passer au CGI. Si cette configuration �tait en place, et qu'une requ�te vers "/cgi-ralph/script/" �tait re�ue, le code du serveur aurait constitu� une variable PATH_INFO de valeur "/ralph/script", et SCRIPT_NAME de valeur "/cgi-". Il est �vident de constater que la deuxi�me variable est fausse. Dans certains cas, cela aurait m�me pu conduire � un arr�t du serveur. La Solution Les versions post�rieures � 1.2 d'Apache d�finissent maintenant les variables SCRIPT_NAME et PATH_INFO en inspectant directement l'URL, et en d�terminant quelle portion de l'URL est modifiable par le client. PATH_INFO est initialis� � cette partie modifiable. Pour r�exploiter l'exemple ci-dessus, PATH_INFO prendrait maintenant la valeur "/script", et SCRIPT_NAME la valeur correcte "/cgi-ralph". Il n'y a plus de probl�me de comportement du serveur dans ce cas. Cela permet en outre de garantir l'accessibilit� de l'URL http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO" laquelle pointe sur le script courant. Ce n'�tait pas n�cesairement vrai dans les versions pr�c�dentes d'Apache. Toutefois, l'information "/ralph" de la directive Alias est perdue. Nous pensions que l'utilisation du syst�me de fichiers pour faire passer ce genre d'information n'�tait pas une m�thode recommand�e, et un script utilisant ce principe �tait de toutes fa�ons � �viter. Nous avons ajout� malgr� tout � partir de la version 1.2b3 d'Apache une fa�on de contourner cette restriction. Compatibilit� avec des serveurs plus anciens Il se peut que certains scripts �crits pour des versions ant�rieures d'Apache ou pour d'autres serveurs aient besoin d'exploiter les informations donn�es dans l'ancien mod�le de variable PATH_INFO. A cet effet, la version 1.2 d'Apache (1.2b3 et post�rieures) proposent une variable suppl�mentaire, appel�e FILEPATH_INFO. Cette nouvelle variable d'environnement contient la valeur qui �tait pr�c�demment inscrite dans PATH_INFO par la version 1.1.1 d'Apache. Un script d�sirant �tre compatible avec toutes les versions d'Apache peut simplement tester l'existence de la variable FILEPATH_INFO, et utiliser cette variable si besoin est. Autrement, il r�cup�rera ses informations dans la variable PATH_INFO. Par exemple, en Perl, on pourra �crire : $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'}; Par cette �criture, un script fonctionnera avec tous les serveurs conformes � la sp�cification CGI/1.1, incluant par l� m�me toutes les versions d'Apache.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]