Ce fichier, qui s'appelle souvent httpd.conf, se trouve souvent dans le répertoire /etc/{httpd,apache(2)}/conf/ sous Linux et dans le répertoire conf du répertoire d'installation d'Apache sous Windows.

Après modification de ce fichier, il faut redémarrer le serveur pour prendre en compte les changements.

Sous Linux et Unix vous devriez au pire pouvoir le localiser via une recherche avec des outils comme locate ou find, exemple :
find / \( -name httpd.conf -o -name apache.conf -o -name apache2.conf \) -type f

La directive ErrorDocument vous permet d'associer une page personnalisée à chacune des erreurs. Illustration :

# Erreur d'authentification
ErrorDocument 401 /home/www/online/erreur401.php
# Accès interdit
ErrorDocument 403 http://www.monDomaine.fr/erreur.php?code=403
# Document non trouvé
ErrorDocument 404 "Document introuvable"
# Erreur serveur
ErrorDocument 500 /home/www/online/erreur500.html

Ces directives peuvent également être utilisées dans un fichier htaccess à condition que la configuration du serveur le permette : directive AllowOverride à la valeur FileInfo ou All.

La directive DocumentRoot dans le fichier de configuration d'Apache indique la racine du serveur Web. Vous pouvez modifier celle-ci de sorte à utiliser un autre emplacement.

Prêtez attention aux permissions au niveau des fichiers de cette arborescence : l'utilisateur sous lequel fonctionne Apache doit être capable de parcourir les dossiers (droit x sur systèmes de type Unix) et de lire les fichiers qu'ils contiennent (droit r) que l'on souhaite publier.

Sur systèmes Unix/Linux, la commande suivante devrait répondre à cette interrogation :

find / \( -name httpd.conf -o -name apache.conf -o -name apache2.conf \) -type f | xargs grep 'DocumentRoot "' | awk -F'"' '{print $2}'

Pour changer le port d'écoute d'Apache, vous devez modifier la valeur de la directive Listen dans le fichier de configuration d'Apache. Exemple :

Listen 81

• Le port standard pour le protocole HTTP est 80 (443 pour HTTPS). S'il est modifié, il faudra clairement le mentionner dans vos différentes URL. Exemple pour un serveur local fonctionnant sur le port 8080 : http://localhost:8080/index.php ;
• L'usage d'un port situé dans la plage 1-1024 requiert normalement les droits d'un administrateur système.

Certains serveurs sont spécifiquement configurés pour fonctionner en local, en écoutant l'adresse 127.0.0.1 (localhost). Donc pour pouvoir y accéder depuis d'autres ordinateurs, il faut le faire écouter l'adresse de la machine sur le réseau. Il s'agit juste d'une ligne à changer dans le fichier de configuration. Stoppez le serveur, modifiez le fichier httpd.conf (situé dans le répertoire conf_files pour EasyPHP) et changez la ligne :

Listen 127.0.0.1:80

Par :

Listen [IP de la machine]:80

Puis redémarrez le serveur.

Des environnements tout en un, comme WAMP, intègrent une option de type "Put Online" qui permet de rendre, ou non, le serveur accessible aux machines extérieures.

Pour mettre en place des redirections basiques, c'est-à-dire d'une URL A, qui ne doit plus être utilisée, à une URL B, remplaçant la première ; vous avez à votre disposition plusieurs directives équivalentes. Il faut notamment prendre en compte le type de redirection (temporaire contre permanente) :

• La forme "générale" :

   

  Sélectionnez

  Redirect (status) URL-path (URL)

  Le paramètre status, facultatif, correspond au code HTTP que le serveur renvoie au client. Les valeurs possibles sont :

  • permanent (301) : la ressource demandée est déplacée de manière permanente de URL-path. Sa nouvelle adresse est URL ;
  • temp (302, valeur par défaut) : le document ciblé par le client, URL-path, est temporairement déplacé à URL ;
  • seeother (303) : la ressource demandée a été remplacée ;
  • gone (410) : le document spécifié fait l'objet d'une suppression définitive. Le paramètre URL, n'a donc pas raison d'être ;
  • le code HTTP numérique, directement, à renvoyer. Si celui-ci ne se situe pas dans la tranche des 300, l'argument URL n'a pas à être fourni.

• Une forme abrégée pour une redirection permanente :

   

  Sélectionnez

  RedirectPermanent URL-path URL

  Qui est équivalente en tout point à :

   

  Sélectionnez

  Redirect permanent URL-path URL
  # Ou encore
  Redirect 301 URL-path URL

• Et il en existe une également, sur le même principe, pour les redirections temporaires :

   

  Sélectionnez

  RedirectTemp URL-path URL

  Strictement synonyme à :

   

  Sélectionnez

  Redirect temp URL-path URL
  # Ou encore
  Redirect 302 URL-path URL

L'ensemble de ces directives fonctionnent par rapport au chemin de l'URL, ce qui signifie que la redirection, ainsi mise en place, sera également effective pour les potentielles sous-ressources (typiquement les fichiers d'un répertoire qui ferait l'objet d'une redirection).

Seules les versions 2 d'Apache sont capables d'accepter un chemin (débutant par un slash), reprenant alors les noms et protocoles de l'URL d'origine, au niveau de leur dernier paramètre (l'URL sur laquelle on redirige). Les versions antérieures généreront une erreur interne (500) si vous veniez malgré tout à en utiliser une.

La directive RedirectMatch vient compléter les précédentes dans le but d'établir des redirections de masse plus évoluées. En effet, comme pourrait le laisser supposer son préfixe Match, celle-ci est capable de se baser sur des expressions rationnelles pour décider si l'URL courante doit faire l'objet d'une redirection ou non. Son avantage est également d'offrir la fonctionnalité de capture, qui permet de réemployer une partie de l'URL d'origine dans celle de redirection.

Un exemple (fictif et incomplet) pour illustrer cette dernière possibilité, soit la redirection suivante :

RedirectMatch permanent ^/(.+)/(.+)\.php$ http://domaine2/$1/$2/

Sa mise en place fait suite à une migration du nom de domaine et accessoirement une réorganisation interne d'un site. En effet, une URL telle que http://domaine1/a/b.php sera renvoyée sur http://domaine2/a/b/ (on suppose la redirection destinée à domaine1 et domaine2 avec une arborescence propre, sinon ils seraient tous deux concernés par cette redirection et engendreraient une redirection sans fin).

Le module de réécriture permet également de réaliser des redirections. Il faut, en ce cas, préciser l'option R (ou redirect) au niveau de votre règle RewriteRule. Le code par défaut renvoyé sera alors celui d'une redirection temporaire. Vous pouvez indiquer tout autre code par son nom symbolique ou valeur numérique (exemple : R=301 ou R=permanent pour une redirection à valeur permanente).

Ces directives ne permettent pas de prendre en compte la partie dite "query string" de l'URL (au sens test ; il faudra, le cas échéant, envisager le module de réécriture). Par contre, ces paramètres seront retransmis, tels quels, à l'URL de redirection.

Peut être voyez-vous une information décrivant votre serveur comme celle ci-dessous, située au bas des pages d'erreur ou autre listing de répertoire :

Apache/2.2.11 (Debian) mod_chroot/0.5 Server at localhost Port 80

Et vous souhaitez ne pas l'afficher ? C'est la directive ServerSignature qui, à la valeur On, affiche cette donnée. A Off, elle ne sera plus du tout visible ou vous pouvez encore la remplacer par l'adresse mail de l'administrateur du serveur (indiquée via une directive ServerAdmin) en précisant la valeur Email.

En complément, depuis les versions 2.0.44, une nouvelle directive a fait son apparition : ServerTokens. Cette dernière permet de restreindre quelles données l'on souhaite voir affichées lorsque ServerSignature est à On. Voici, en reprenant mon précédent exemple, ce que l'on obtient pour chacune des valeurs que ServerTokens peut prendre :

ServerSignature et, surtout, ServerTokens altèrent également les informations transmises à PHP lorsqu'il fonctionne comme module.

Une autre solution pourrait être de patcher Apache mais s'avère être une mauvaise idée car certains modules, comme Perl, nécessite les informations de version. Sans compter que cela donne, en terme de maintenance, plus de travail.

Les variables d'environnement SCRIPT_URI et SCRIPT_URL sont exclusivement gérées par le module de réécriture (mod_rewrite) à condition que la réécriture soit activée au niveau même du serveur. C'est à dire que vous devez avoir RewriteEngine On au niveau du serveur concerné (celui par défaut et/ou un virtualhost).

Par contre, de par cette spécificité au niveau de la configuration et de leur absence de standardisation (norme CGI 1.1), je vous recommande fortement de vous appuyer sur d'autres variables présentes en toute circonstance.

Oui, il est possible de réaliser dynamiquement la modification d'une ressource avant l'envoi au client directement avec Apache. Il faut pour cela ajouter un filtre en sortie et rediriger, pour traitement, cette même sortie à un module.

Il existe notamment le module substitute, à condition de posséder une version 2.2.7 minimum où celui-ci est activé, pour effectuer du remplacement de texte (éventuellement par l'intermédiaire d'expressions régulières).

Une possible utilisation pourrait être de réaliser la fonction inverse d'une réécriture d'URL afin de ne pas avoir à modifier son site. Il faut cependant bien être conscient, qu'à traiter une page comme un vulgaire texte et avec de multiples opérations de remplacements, nous sommes susceptibles d'introduire des remplacements indésirés.

C'est toutefois l'exemple que je vous propose par le .htaccess suivant (on supposera le module substitute chargé/activé) :

<IfModule mod_rewrite.c>
    <IfModule mod_substitute.c>
        AddOutputFilterByType SUBSTITUTE text/html
 
        Substitute s~(?:index\.php)?\?page=([[:lower:]]+)~$1~
        Substitute s~article\.php\?id=(\d+)~article-$1~
    </IfModule>
 
    Options +FollowSymLinks
 
    <IfModule mod_negotiation.c>
        Options -MultiViews
    </IfModule>
 
    RewriteEngine On
    RewriteBase /
 
    RewriteRule ^([[:lower:]]+)$ index.php?page=$1 [L]
    RewriteRule ^article-(\d+)$ article.php?id=$1 [L]
</IfModule>

Ainsi, nos liens de la forme (index.php)?page=X seront dynamiquement réécrits en X et article.php?id=Y en article-Y par le module substitute. Et le module de réécriture se chargera de les faire aboutir, en interne, sur l'URL originale. Nous avons donc mis en place des liens "propres" sans avoir modifié le moindre script/page du site.