Share
Les fichiers de configuration .htaccess d'Apache ont déconcerté d'innombrables développeurs. Ce tutoriel a pour objectif de surmonter cette confusion en se concentrant sur des exemples et des descriptions détaillées. Parmi les avantages de l’apprentissage de la configuration .htaccess, on trouve le gzipper automatique de votre contenu, en fournissant des URL plus conviviales, en évitant la création de liens en hyperlien, en améliorant la mise en cache, etc..
Cet article vous apprendra comment configurer vos fichiers .htaccess manuellement, mais si vous souhaitez une solution simple et rapide, essayez de télécharger .htaccess Builder d’Envato Market. Il vous permet de livrer rapidement et sans effort un fichier htaccess sans avoir à vous souvenir du langage du serveur Apache utilisé pour construire le fichier htaccess.!
.htaccess Builder sur le marché Envato J'ai lu plusieurs articles sur .htaccess en ligne. Je vais admettre sans vergogne
Je n'ai pas dépassé la première page des résultats Google. J'ai été choqué quand
En fait, j'ai lu les articles et constaté qu'aucun d'eux n'expliquait ce qu'Apache était réellement.
Faire. Ils étaient simplement une collection d’astuces populaires ou utiles ou
extraits de code réutilisable. C'est bien beau, mais le classique
l'argument est:
“Donnez un poisson à un homme et il mangera pendant une journée. Apprendre à un homme à pêcher et il
va manger pour toute une vie. "
- Confucius
Dans cet article, je vais essayer de ne pas vous montrer que des exemples de
.htaccess, mais expliquez exactement ce qui est
passe. De cette façon, vous comprendrez les principes fondamentaux et pourrez ensuite étendre la
des exemples ou créer de nouvelles commandes pour votre propre usage de manière créative ou utile
vous pouvez venir avec.
Je vais me concentrer sur Apache 2, bien que cela s’applique en grande partie
Apache 1.3 et je vais essayer de souligner les différences que je connais.
Enfin, ce tutoriel aura plus de sens si vous le lisez dans l’ordre.
J'essaie de relier mes exemples et de les construire de telle manière.
façon que vous pouvez les essayer vous-même et suivre.
Pour citer Apache:
.Les fichiers htaccess (ou «fichiers de configuration distribués») fournissent un moyen de
changements de configuration par répertoire. Un fichier contenant un ou plusieurs
directives de configuration, est placé dans un répertoire de document particulier, et le
les directives s'appliquent à ce répertoire et à tous ses sous-répertoires.
“Directives” est la terminologie utilisée par Apache pour les commandes de son logiciel.
fichiers de configuration. Ce sont normalement des commandes relativement courtes, typiquement
des paires clé-valeur qui modifient le comportement d'Apache. Un fichier .htaccess permet
les développeurs à exécuter un tas de ces directives sans avoir besoin d'accéder à
Le fichier de configuration du serveur principal d'Apache, souvent nommé httpd.conf. Ce fichier,
httpd.conf, est généralement appelé le "fichier de configuration globale" et je vais
s'y référer avec ce nom ou son équivalent de nom de fichier court.
Cette fonctionnalité est idéale pour de nombreuses sociétés d’hébergement qui déploient un hébergement partagé.
environnement. La société d’hébergement ne permettra pas à ses clients d’accéder au
fichier de configuration global, qui affecte finalement tous les clients hébergés sur
ce serveur. Au lieu de cela, en activant .htaccess, ils donnent à chacun de leurs clients
le pouvoir de spécifier et d'exécuter leurs propres directives Apache dans leurs propres
répertoires et sous-répertoires. Bien sûr, il est également utile pour le single
développeur, comme vous le verrez.
Il convient de mentionner que tout ce qui peut être fait avec un fichier .htaccess peut
être fait dans le fichier httpd.conf. toutefois, NE PAS tout ce qui peut être fait dans
httpd.conf peut être créé dans un fichier .htaccess. En fait, les fichiers .htaccess doivent être
activé dans le fichier httpd.conf afin de pouvoir être exécuté. Une fois activé,
leur pouvoir peut être limité à certains "contextes" afin qu'ils puissent être autorisés
pour remplacer certains paramètres mais pas d’autres. Cela donne aux administrateurs système
plus de contrôle sur ce qu'ils ont laissé d'autres développeurs s'en tirer dans leur
.fichiers htaccess.
.Les fichiers htaccess sont normalement activés par défaut. Ceci est effectivement contrôlé
par la directive AllowOverride dans le fichier httpd.conf. Cette directive
ne peut être placé qu'à l'intérieur d'un
vous. Le fichier httpd.conf typique définit un DocumentRoot et la majorité
du fichier contiendra des directives à l'intérieur d'un
avec ce répertoire. Cela inclut la directive AllowOverride.
La valeur par défaut est "All" et les fichiers .htaccess sont donc activés par
défaut. Une valeur alternative serait «Aucune», ce qui signifierait qu'ils sont
complètement invalide. Il existe de nombreuses autres valeurs qui limitent la configuration de
certains contextes. Certains sont:
Je vais montrer quelques exemples, sans leur correspondant
Voici un exemple permettant de surcharger .htaccess:
# Autoriser les fichiers .htaccess à pleine puissance AllowOverride All
Et voici un exemple qui adopte une approche plus fine et ne permet que
écrasement des contextes Authorization et Indexes mais rien d’autre:
# Autorise uniquement les fichiers .htaccess à remplacer les index d'autorisation et d'index AllowOverride AuthConfig
La première ligne de ces deux exemples concerne les commentaires Apache. Les commentaires commencent
avec le symbole "#". Ceci est commun à de nombreux fichiers de configuration et scripts
langues. J'aurai beaucoup de commentaires dans mes exemples pour aider à expliquer ce que font les choses.
Cependant, ils ne sont pas nécessaires, et il s’agit vraiment d’une préférence personnelle
veux commenter. Les commentaires ne sont pas obligatoires.
La deuxième ligne est la directive AllowOverride elle-même. C’est la syntaxe habituelle d’un
Directive Apache. Il y a d'abord le nom de directive “AllowOverride” suivi d'un espace
liste de valeurs séparée. Bien que cette syntaxe semble plutôt lâche; Toujours être prudent.
Parfois, même une seule erreur dans votre fichier httpd.conf ou .htaccess entraînera un
fusion temporaire du serveur, et les utilisateurs verront 500 - Pages d'erreur de serveur interne.
Pour cette raison uniquement, il est recommandé de toujours effectuer une sauvegarde de vos fichiers httpd.conf et .htaccess avant toute modification ou tout ajout. De cette façon, si quelque chose ne va pas avec une modification, vous aurez
rien à craindre, car vous pouvez revenir à votre version de travail précédente. Je vais
vous encourage également à effectuer de petits changements à la fois et à vérifier que les changements fonctionnent
incréments plutôt que de faire plusieurs changements à la fois. De cette façon, si vous faites
une erreur, il sera beaucoup plus facile de dépister ce qui peut l’avoir causé.
Si vous vous trompez dans la syntaxe d’une directive, rendez-vous immédiatement à
Apache Directive listant et révisant la «syntaxe» qu’ils ont listée dans le tableau
pour chaque directive individuelle. Je ferai de mon mieux pour essayer de l'expliquer ici
(J'essaie d'enseigner) mais mon explication ne peut jamais être aussi bonne que la
documentation technique formelle elle-même. Ne jamais avoir peur de la documentation, c'est
votre référence la plus fiable et la plus fiable. Je vais essayer de rendre les choses plus intéressantes
ici (woohoo!), mais à la fin, je suis juste en train de mettre un spin différent sur ces docs.
Il est fort possible, en fait, extrêmement probable que votre hébergeur ne
vous donne accès au fichier httpd.conf. Alors, comment savoir si le support .htaccess est activé
ou pas? Ne vous inquiétez pas, .htaccess est une fonctionnalité très courante et utile que la plupart des entreprises
ont activé, ou permettra si vous demandez poliment.
La meilleure chose à faire serait de vérifier auprès de votre hébergeur. Si ce n'est pas explicitement
répertorié n'importe où dans votre plan d'hébergement, puis envoyez un e-mail à leur support. Ceci est un relativement commun
donc ils ont probablement déjà une réponse prête pour vous. Ils seront probablement disposés
pour permettre le service ou au moins donner une raison pour laquelle ils ne peuvent pas le permettre.
En tout état de cause, vous pouvez toujours essayer et voir si un simple fichier .htaccess fonctionne!
L’exemple de téléchargement de ce didacticiel contient deux méthodes que vous pouvez vérifier pour voir si .htaccess
le support est activé. Les deux dossiers sont «is_htaccess_enabled» et «is_htaccess_enabled_2»..
Donnez-leur un coup de feu, je vais expliquer ce que chacun fait ici.
Ce cas de test est très simple. Il utilise une directive pour rendre Apache
d'abord pour l'indexgood.html ”fichier avant“ index.html. ”Si le support .htaccess est
activé, lorsque vous pointez votre navigateur sur le dossier, Apache chargera le fichier .htaccess et saura que
il devrait afficher l'indexgood.html ”page contenant un message vert disant: félicitations!
Si le support .htaccess n'est pas activé, Apache ignorera par défaut le fichier .htaccess.
fichier et cherchez immédiatement un fichier index.html.
# Cette directive obligera Apache à rechercher # "index_good.html" avant de rechercher "index.html" DirectoryIndex index_good.html index.html
La directive DirectoryIndex prend une liste de noms de fichiers potentiels séparés par des espaces..
Lorsque Apache reçoit l’URL d’un répertoire et non une page directe (par exemple,
http://www.example.com et non http://www.example.com/index.html) Apache utilisera cette
liste des fichiers à rechercher pour la page à charger. Apache va chercher les fichiers
en utilisant les valeurs de la liste de gauche à droite. Le premier fichier qu'Apache voit existe
sera le fichier qu'il charge et affiche au client.
En utilisant le fichier .htaccess ci-dessus, voici un exemple des bons (activés) et mauvais (désactivés):
Comme je l’ai dit plus tôt, une erreur de syntaxe dans votre fichier .htaccess provoquera le hoquet du serveur..
Vous pouvez utiliser cela à votre avantage pour vérifier si la prise en charge de .htaccess est activée sur votre serveur.!
Voici un exemple de fichier .htaccess destiné à exploser.
# Ce fichier est destiné à faire exploser Apache. Cela aidera # à déterminer si .htaccess est activé ou non! AHHHHHHH
Il est assez clair que “AHHHHHHH” n'est pas une directive Apache valide. Cela causera
une erreur si Apache essaie de lire le fichier .htaccess! Donc, si vous récupérez une page en hurlant
“Internal Server Error”, votre serveur recherche les fichiers .htaccess! Si vous avez réellement
voir le contenu du fichier index.html, alors il est probable qu'ils ont été désactivés. Voici encore les bons et les mauvais cas:
Enfin, il est toujours possible que le support .htaccess soit toujours activé, avec seulement
paramètres uniques. Les administrateurs système peuvent modifier le nom du fichier .htaccess simplement
comme si nous avions changé le nom du fichier par défaut que Apache cherche. Ceci est possible par
en utilisant le AccessFileName
directive dans le fichier de configuration globale. Encore une fois, la meilleure chose à faire dans ce cas serait de
contactez votre hébergeur pour plus d'informations.
Avant d’entrer dans les choses intéressantes que vous pouvez faire avec les fichiers .htaccess, je dois
vous dire dans quoi vous vous engagez. Comme je l'ai mentionné précédemment, vous autorisez
remplacement des paramètres du serveur pour un répertoire et tous ses sous-répertoires. Toujours
garder à l'esprit que vous affectez tous les sous-répertoires ainsi que le courant
annuaire.
En outre, une fois activé, le serveur subira un impact négatif sur les performances. La raison est parce que, chaque demande du serveur, si le support .htaccess est activé, quand Apache va chercher le fichier demandé pour le client, il doit rechercher un fichier .htaccess dans chaque répertoire menant à l'endroit où il est stocké..
Cela signifie un certain nombre de choses. D'abord parce qu'Apache cherche toujours les fichiers .htaccess
à chaque demande, toute modification apportée au fichier prend effet immédiatement.
Apache ne les met pas en cache et il verra immédiatement vos modifications à la prochaine demande..
Cependant, cela signifie également qu’Apache devra effectuer un travail supplémentaire pour chaque demande..
Par exemple, si un utilisateur demande /www/supercool/test/index.html, votre serveur
vérifierait les fichiers .htaccess suivants:
/www/.htaccess /www/supercool/.htaccess /www/supercool/test/.htaccess
Ces accès de fichiers potentiels (potentiels car les fichiers peuvent ne pas exister) et leur
l'exécution (si elles existaient) prendra du temps. Encore une fois, mon expérience est que c'est
imperceptible et il ne l'emporte pas sur les avantages et la flexibilité que .htaccess
les fichiers fournissent aux développeurs.
Cependant, si cela vous concerne, tant que vous avez accès au fichier httpd.conf
alors vous pouvez toujours y mettre vos directives. En définissant AllowOverride sur «None»
Apache ne cherchera pas ces fichiers .htaccess. Si vous voulez vraiment, vous pouvez mettre
les directives que vous vouliez mettre dans votre fichier /www/supercool/test/.htaccess
directement dans httpd.conf comme ceci:
# Mettez les directives ici
L’inconvénient de cette approche est que vous devrez redémarrer le serveur Apache.
à chaque changement pour qu'il recharge la nouvelle configuration.
En fin de compte, cela dépend de vos préférences personnelles ou de ce que votre hôte vous permet..
Je préfère utiliser les fichiers .htaccess car j’ai la possibilité de les placer où
Je veux, et leurs effets sont en direct immédiatement sans nécessiter une réinitialisation du serveur.
Avant d'entrer dans l'une des fonctionnalités complexes, commençons par quelque chose
simple, mais utile, pour vous familiariser avec l'utilisation des fichiers .htaccess.
Les listes de répertoires sont si courantes que vous en avez probablement déjà vu beaucoup
fois sur le Web.
Lorsqu'un utilisateur demande un répertoire, Apache recherche d'abord le fichier par défaut. En règle générale, il sera nommé "index.html" ou "index.php" ou quelque chose de similaire. Quand ce n'est pas
trouver un de ces fichiers, il se replie sur le module mod_autoindex pour
affiche une liste des fichiers et des dossiers de ce répertoire. Parfois cela
est activé, parfois désactivé, et parfois vous voulez
faire des personnalisations. Eh bien, avec .htaccess vous pouvez facilement manipuler ces listes!
Par défaut, les listes de répertoires sont activées. Voici un exemple de scénario.
Supposons que vous stockiez plusieurs fichiers multimédias sur votre serveur Web.,
et vous voulez les cacher du public et des moteurs de recherche afin que personne ne puisse
voler ces fichiers. C'est très facile à faire! Créez simplement un fichier .htaccess
dans le répertoire que vous voulez masquer et ajoutez la directive suivante:
# Désactiver les listes de répertoires de ce répertoire et de ses sous-répertoires # Ceci masquera les fichiers du public, sauf s’ils connaissent les URL directes. Options -Indexes
En décomposant, nous utilisons la directive Options.
Cette directive peut prendre un certain nombre de valeurs (mentionnées précédemment). Si vous fournissez les valeurs
avec un + ou - comme je l'ai fait avec -Indexes, alors cela héritera du
Options activées dans les répertoires supérieurs et dans la configuration globale!
Si vous ne fournissez pas un + ou un - alors la liste que vous fournissez deviendra
la seulement options activées pour ce répertoire et ses sous-répertoires. Aucune autre option ne sera activée. Parce que vous ne savez peut-être pas quelles options ont été activées précédemment, vous aurez probablement
utilisez la syntaxe + ou - sauf si vous êtes absolument certain seulement veulent certaines options.
Maintenant, avec cette directive dans votre fichier .htaccess, lorsque vous pointez votre navigateur sur ce répertoire
vous ne pourrez plus voir les fichiers. Voici l'avant et après:
D'accord, peut-être que désactiver totalement l'index de l'annuaire n'est pas ce que vous voulez. C'est plus
probable que vous souhaitiez conserver les index mais autoriser uniquement l'accès à certaines personnes.
C'est là que l'authentification de base peut être très utile. C'est le plus commun
type d'authentification sur le web. Lorsque l'utilisateur tente d'accéder à la page, il
La boîte de dialogue familière Nom d'utilisateur / Mot de passe Seul un utilisateur avec le bon
les informations d'identification pourront accéder au contenu.
Pour l'authentification de base, il n'y a que deux étapes.
Traditionnellement, les développeurs Web ont nommé le fichier qui stocke les noms d’utilisateur et
mots de passe “.htpasswd”. En effet, l'outil de ligne de commande fourni avec
Apache qui génère la paire nom d'utilisateur / mot de passe chiffrée appropriée est en fait
appelé htpasswd! Si vous vous sentez à l'aise en ligne de commande, vous pouvez utiliser le mot de passe htpasswd.
outil, mais il existe de nombreux outils en ligne qui généreront la sortie tout aussi facilement.
J'ai créé un exemple de fichier .htpasswd pour un utilisateur “joe” avec le mot de passe “cool”.
J'ai intégré ces valeurs dans l'outil en ligne lié:
joe: $ apr1 $ QneYj /… $ 0G9cBfG2CdFGwia.AHFtR1
Votre sortie peut être différente, ça va. Les mots de passe sont hachés avec
un sel aléatoire pour les rendre un peu plus uniques et sécurisés. Une fois votre identifiant
et la combinaison du mot de passe a été ajoutée au fichier .htpasswd, alors vous devriez
ajoutez les lignes suivantes à votre fichier:
# Activer l'authentification de base AuthType Basic # C'est ce qui sera affiché à l'utilisateur dans la boîte de dialogue de connexion. AuthName "Accès aux fichiers cachés" # Ceci vous devez éditer. C'est le chemin absolu du fichier .htpasswd. AuthUserFile /path/to/.htpasswd # Ceci permet à tout utilisateur à l'intérieur du fichier .htpasswd d'accéder au contenu # s'il fournit le nom d'utilisateur et le mot de passe appropriés. Exiger un utilisateur valide
Ces commandes sont bien documentées. Le seul véritable défi est que vous
définir correctement le chemin d'accès au fichier .htpasswd que vous venez de
généré. Ceci est un chemin absolu complet de la racine absolue de la
serveur. De plus, comme le chemin du fichier .htpasswd est absolu, c'est bien
pratique de le mettre dans un répertoire en dehors du répertoire où Apache
sert des pages Web au public. De cette façon, les utilisateurs malveillants ne pourront pas
accéder facilement à la liste brute d'utilisateurs / mots de passe stockés dans le fichier .htpasswd.
Une fois que tout est configuré, lorsque quelqu'un tente d'accéder à la page, il le fera.
recevez le dialogue suivant:
L'authentification de base est simple et agréable, mais ce n'est pas une solution complète.
Les mots de passe sont envoyés par câble, Base 64 Encoded, en texte brut. Si vous
voulez une authentification plus sécurisée, vous devez coupler l'authentification de base
avec https, un plus
protocole sécurisé. C'est un sujet pour une autre fois.
Le protocole de base du Web est le protocole HTTP (Hypertext Transfer Protocol)..
Si vous voulez vraiment comprendre ce que le reste des directives Apache
traiter, vous devriez avoir une certaine connaissance du protocole. je suis
aller seulement à su pplya résumé très rapide ici. Je vais aussi faire un effort
expliquer ce que font les directives les plus complexes, mais cela rendra
plus logique si vous comprenez les en-têtes HTTP.
Le résumé rapide est que HTTP est sans état. A chaque demande (du navigateur)
et chaque réponse (du serveur Web comme Apache), il y a deux sections.
Une section d'informations d'en-tête, puis une section facultative contenant les données elles-mêmes,
s'il y a des données.
Les informations d’en-tête de requête spécifient souvent le fichier qu’elles sont.
demande au serveur (index.html), toute information d'état à fournir
(comme les données de cookies), et les types de mime qu'il est prêt à accepter du serveur
(contenu text / html ou même gzip).
Les informations d’en-tête de réponse spécifient souvent des informations de serveur génériques (Apache, PHP,
Versions Perl, etc.), l’encodage du contenu, la longueur, le mime / type, etc. Là
sont une pléthore d'en-têtes HTTP pour spécifier encore plus de détails, comme Cache Control,
Redirections et codes d'état. Jamais obtenu un 404? C’était le résultat d’une demande de
fichier que le serveur n'a pas pu trouver, et donc il a renvoyé un 404
Code de statut dans son
Réponse.
Qu'est-ce que cela a à voir avec .htaccess? Eh bien, vous pouvez utiliser les directives Apache pour
écraser (définir) ou ajouter de nouveaux en-têtes (ajouter) qui sont renvoyés au client
dans la section d'en-tête de la réponse. En outre, comme vous le verrez dans les prochains tutoriels,
des fonctionnalités plus avancées telles que la réécriture d'URL traite des en-têtes entrants.
Commençons simplement, nous allons ajouter un en-tête à la réponse et voir ce qui se passe:
# Ajoutez l'en-tête suivant à chaque réponse. En-tête, ajoutez X-HeaderName "Header Value".
Demander un fichier dans le même répertoire que ce fichier .htaccess affiche le
en-tête supplémentaire:
Vous avez probablement pensé qu'il était étrange que je préfixe l'en-tête personnalisé avec
"X-". Ceci est en fait une convention commune que les développeurs utilisent pour indiquer que
l'en-tête est un en-tête non standard. Cela rend très facile à réaliser que cet en-tête est personnalisé. Cette convention est
brièvement mentionné ici.
Sur une note plus comique, certaines personnes se sont bien amusées avec les en-têtes..
Ce site
souligne des en-têtes assez inhabituels trouvés sur le Web.
Cependant, je veux vraiment vous montrer comment créer des en-têtes afin que vous puissiez
utilisez-les comme technique de débogage. L’autre jour, j’ai fait un test avec
vérifiez si certains modules ont été activés sur un serveur Web. J'ai écrit
le chèque suivant:
En-tête ajouter mod_gzip activé par X En-tête ajouter mod_deflate activé par X
Lorsque j'ai fait ma prochaine demande avec mon navigateur et vérifié les en-têtes de réponse,
a montré qu'aucun des modules n'était allumé! J'ai contacté mon hébergeur et celui-ci a accepté d'activer la compression gzip!
Il y a une différence entre Header set et
En-tête ajouter. Avec ajouter, l'en-tête sera toujours être ajouté
à la réponse. Même s'il arrive à apparaître plusieurs fois dans la réponse. C'est le plus souvent
ce que vous voudriez pour les en-têtes personnalisés. Vous utiliseriez set quand vous voulez
écrasez la valeur de l’un des en-têtes par défaut renvoyés par Apache. Un
Cet exemple remplacerait le mime / type spécifié par le type de contenu.
en-tête pour un certain fichier. Apache définirait la valeur interne, puis
utilisez-le lorsqu'il affiche l'en-tête par défaut. Il n'y aura pas
les doublons, et donc aucune possibilité d'interpréter une erreur ou une confusion
par le client. (Au cas où vous vous le demanderiez, la spécification HTTP indique que, dans
Dans le cas de doublons, le client doit toujours utiliser la dernière valeur spécifiée.
pour cet en-tête en double.)
J'ai passé en revue certaines directives Apache de base de manière assez détaillée. Je voulais obtenir les détails fondamentaux afin que le prochain tutoriel puisse parler de choses plus cool. Mon prochain article sera
concentrez-vous sur certaines des fonctionnalités les plus utiles que vous pouvez activer avec .htaccess.
Ces sujets comprendront:
Et n'oubliez pas que si vous avez du mal à suivre cela, vous pouvez également essayer l'utilitaire .htaccess Builder disponible sur Envato Market..
Accentsconagua