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]