Share
.htaccess-filer används för att konfigurera Apache, liksom en rad andra webbservrar. Trots .htaccess filtypförlängning, de är helt enkelt textfiler som kan redigeras med någon textredigerare. I den här artikeln granskar vi vad de är och hur du kan använda dem i dina projekt.
Observera att .htaccess-filer inte fungerar på Windows-baserade system, även om de kan redigeras och laddas upp till en kompatibel webbserver, och på Linux-baserade system är de dolda som standard.
För att kunna arbeta med htaccess-filer lokalt, för att se hur de fungerar och i allmänhet leker med dem kan vi använda XAMPP (eller MAMP) på Mac - ett paket som installerar och konfigurerar Apache, PHP och MySQL. För att redigera dessa .htaccess-filer på Mac borde vi använda en textredigerare som tillåter öppnandet av dolda filer, till exempel TextWrangler.
En .htaccess-fil följer samma format som Apaches huvudkonfigurationsfil: httpd.conf. Många av de inställningar som kan konfigureras med huvudkonfigurationsfilen kan också konfigureras med dem och vice versa.
En inställning som är konfigurerad i en .htaccess-fil kommer att åsidosätta samma inställning i huvudkonfigurationsfilen för katalogen som innehåller filen, liksom alla dess underkataloger.
De kallas ibland som dynamiska konfigurationsfiler eftersom de läses av servern på varje förfrågan till katalogen de finns i. Det betyder att alla ändringar i en .htaccess-fil kommer att träda i kraft omedelbart utan att behöva starta om servern, till skillnad från ändringar som gjorts i den globala konfigurationsfilen. Det innebär också att du betalar en liten prestationsflik för att använda dem, men de kan vara användbara när du inte har tillgång till serverns huvudkonfigurationsfil.
Så nu vet vi alla vad .htaccess-filer är, hur de redigeras och arbetat med, och några av deras för-och nackdelar, låt oss titta på hur de kan användas och några av de coola sakerna de kan göra.
En populär användning av .htaccess-filer är att utföra omdirigeringar eller skriva om webbadresser. Detta kan hjälpa till med SEO efter en ändring av domännamn eller omstrukturering av filstrukturer, eller kan göra lång, otäck webbadress mer vänlig och minnesvärd.
En omdirigering kan vara så enkel som följande:
Omdirigera 301 ^ gamla \ .html $ http: //localhost/new.html
Detta ställer HTTP-statuskoden till 301 (flyttas permanent) och omdirigerar alla förfrågningar till old.html öppet till new.html. Vi använder ett regelbundet uttryck för att matcha URL-adressen som ska omdirigera, vilket ger oss en fin grad av kontroll för att säkerställa att endast den korrekta webbadressen matchas för omdirigering, men lägger till komplexitet i konfigurationen och administrationen av den. Den fullständiga URL-adressen för resursen som omdirigeras till krävs.
En omskrivningsregel kan vara så enkelt som detta:
RewriteEngine på RewriteRule ^ old \ .html $ new.html
I det här exemplet tillhandahåller vi bara en enkel fildirigering från en fil till en annan, som också kommer att genomföras på ett öppet sätt utan att ändra det som visas i adressfältet. Det första direktivet, RewriteEngine på, garanterar helt enkelt att omskrivningsmotorn är aktiverad.
För att uppdatera det som visas i adressfältet på besökarens webbläsare kan vi använda R flagga i slutet av RewriteRule t.ex.
RewriteRule ^ old \ .html $ http: //hostname/new.html [r = 301]
De r flaggan orsakar en extern omdirigering, varför den fullständiga webbadressen (ett exempel URL-URL här) till den nya sidan ges. Vi kan också ange statuskoden när flaggan används. Detta gör att adressfältet uppdateras i besökarens webbläsare.
En av de möjliga användningarna för URL-omskrivning som jag gav i början av det här avsnittet var att göra fula webbadresser (som innehåller sökordsträngsdata) mer användarvänliga för besökare och sökmotorer. Låt oss se detta i aktion nu:
RewriteRule ^ produkter / ([^ /] +) / ([^ /] +) / ([^ /] +) product.php? Cat = $ 1 & brand = $ 2 & prod = $ 3
Denna regel tillåter besökare att använda en webbadress som produkter / skivspelare / teknik / sl1210, och har det förvandlats till product.php? cat = skivspelare &$ 1, $ 2 och $ 3 respektive. De [^ /]+ teckenklass inom parentesen betyder att alla tecken är förutom en framåtskärning 1 eller flera gånger.
I praktiken kan URL-omskrivning vara (och vanligtvis) mycket mer komplex och uppnå mycket större saker än detta. URL-omskrivning förklaras bättre med hjälp av hela handledning så vi kommer inte att titta på dem i ytterligare detalj här.
Det är bara inte coolt att visa standard 404-sidan längre. Många webbplatser utnyttjar möjligheten som erbjuds av en fil som inte hittat ett fel för att injicera lite humor på deras webbplats, men i alla fall förväntar man sig att 404-sidan på en sida åtminstone matchar stilen och temat på någon annan sida på webbplatsen.
Mycket nära relaterat till URL-omskrivning, som serverar en anpassad fel sida istället för standard 404-sidan är lätt med en .htaccess-fil:
ErrorDocument 404 "/404.html"
Det är allt vi behöver när ett 404-fel inträffar visas den angivna sidan. Vi kan konfigurera sidor som ska visas för många andra serverfel också.
Med hjälp av .htaccess-filer kan vi aktivera lösenordsskydd för alla filer eller kataloger, till alla användare eller baseras på saker som domän eller IP-adress. Detta är trots allt en av deras kärnanvändningar. För att förhindra åtkomst till en hel katalog kan vi enkelt skapa en ny .htaccess-fil med följande kod:
AuthName "Användarnamn och lösenord krävs" AuthUserFile /path/to/.htpasswd Kräv giltig användare AuthType Basic
Den här filen ska sparas i den katalog vi vill skydda. De AuthName Direktivet anger meddelandet som ska visas i dialogrutan användarnamn / lösenord, AuthUserFile ska vara sökvägen till .htpasswd-filen. De Fordra Direktivet anger att endast autentiserade användare får tillgång till den skyddade filen medan AuthType är satt till Grundläggande.
För att skydda en specifik fil kan vi pakka in ovanstående kod i en
AuthName "Användarnamn och lösenord krävs" AuthUserFile /path/to/.htpasswd Kräv giltig användare AuthType Basic
Vi behöver också en .htpasswd-fil för dessa typer av autentisering, som innehåller en kolonnseparerad lista över användarnamn och krypterade lösenord som krävs för att komma åt den / de skyddade resurserna. Den här filen ska sparas i en katalog som inte är tillgänglig för webben. Det finns en rad tjänster som kan användas för att generera dessa filer automatiskt eftersom lösenordet ska lagras i krypterad form.
En annan användning av .htaccess-filer är att snabbt och enkelt blockera alla förfrågningar från en IP-adress eller användaragent. För att blockera en viss IP-adress, lägg bara till följande direktiv i din .htaccess-fil:
ordning tillåter, neka neka från 192.168.0.1 tillåta från alla
De ordning direktivet berättar Apache i vilken ordning att utvärdera direktiven om tillåtelse / nekande. I detta fall, tillåta utvärderas först då förneka. De tillåta från alla Direktivet utvärderas först (även om det förekommer efter förneka direktivet) och alla IP-adresser är tillåtna, då klientens IP matchar den som anges i förneka Direktivet är tillträde förbjudet. Detta låter alla utom den angivna IP-adressen. Observera att vi också kan neka tillgång till hela IP-block genom att tillhandahålla en kortare IP, t.ex.. 192,168.
För att neka förfrågningar baserade på användaragent kan vi göra det här:
RewriteCond% HTTP_USER_AGENT ^ OrangeSpider RewriteRule ^ (. *) $ Http: //% REMOTE_ADDR / $ [r = 301, l]
I det här exemplet kan någon klient med en HTTP_USER_AGENT sträng som börjar med OrangeSpider (en dålig bot) omdirigeras tillbaka till adressen som den härrör från. Det reguljära uttrycket matchar alla enskilda tecken (.) noll eller flera gånger (*) och omdirigerar till % REMOTE_ADDR miljöfaktor. De l flaggan vi använde här instruerar Apache att behandla den här matchen eftersom den sista regeln så kommer inte att behandla någon annan innan du skriver omskrivningen.
Tillsammans med att kontrollera hur servern svarar på vissa förfrågningar, kan vi också göra saker till besökarens webbläsare, t ex tvinga IE att göra sidor med en specifik återgivningsmotor. Till exempel kan vi använda mod_headers modul, om den är närvarande, för att ställa in X-UA-kompatibel rubrik:
Header set X-UA-kompatibel "IE = Edge"
Lägga till den här raden i en .htaccess-fil instruerar IE att använda det högsta reningsläget som är tillgängligt. Som demonstreras av HTML5 Boilerplate kan vi också undvika att ställa in denna rubrik på filer som inte kräver det genom att använda en
Header unset X-UA-Compatible
Cachning är lätt att ställa in och kan göra att din webbplats laddas snabbare.
Cachning är lätt att ställa in och kan göra att din webbplats laddas snabbare. 'Nog sagt! Genom att ange en långt framtid löper ut datum på delar av webbplatser som inte ändras mycket ofta kan vi hindra webbläsaren att begära oförändrade resurser på varje förfrågan.
Om du kör din webbplats via Google PageSpeed eller Yahoos YSlow och du får meddelandet om hur du ställer in framtida utgåvor, så här fixar du det:
ExpiresActive on ExpiresActive på ExpiresByType image / gif "access plus 1 månad" ExpiresByType image / png "access plus 1 månad" ExpiresByType image / jpg "access plus 1 månad" ExpiresByType image / jpeg "access plus 1 månad" ExpiresByType video / ogg " plus 1 månad "ExpiresByType audio / ogg" åtkomst plus 1 månad "ExpiresByType video / mp4" åtkomst plus 1 månad "ExpiresByType video / webm" access plus 1 månad "
Du kan lägga till olika ExpiresByType riktlinjer för innehåll som är listat i det prestationsverktyg du använder, eller något annat som du vill kontrollera caching på. Det första direktivet, ExpiresActive on, garanterar helt enkelt att genereringen av Expires-huvuden är påslagen. Dessa direktiv är beroende av Apache som har mod_expires modul laddad.
En annan varning som vi kan få i en prestandakontroll refererar till att möjliggöra komprimering, och det här är också något vi kan fixa genom att uppdatera vår .htaccess-fil:
FilterDeclare COMPRESS FilterProvider COMPRESS DEFLATE resp = Innehålls-typ $ text / html FilterProvider COMPRESS DEFLATE resp = Innehålls-typ $ text / css FilterProvider COMPRESS DEFLATE resp = Innehålls-typ $ text / javascript FilterChain COMPRESS FilterProtocol COMPRESS DEFLATE change = ja; byteranges = nej
Detta komprimeringsschema fungerar på nyare versioner av Apache (2.1+) med hjälp av mod_filter modul. Den använder SÄNKA komprimeringsalgoritm för att komprimera innehåll baserat på dess svarinnehållstyp, i det här fallet anger vi text / html, text / css och text / javascript (vilket förmodligen kommer att vara de typer av filer som flaggats i PageSpeed / Yslow i alla fall).
I ovanstående exempel börjar vi genom att deklarera det filter vi vill använda, i det här fallet KOMPRIMERA, använda FilterDeclare direktiv. Vi listar sedan de innehållstyper vi vill använda detta filter. De FilterChain direktivet instruerar sedan servern att bygga en filterkedja baserad på FilterProvider direktiv som vi har listat. De FilterProtocol Direktivet tillåter oss att ange alternativ som tillämpas på filterkedjan när den körs, alternativen vi behöver använda är förändring = yes (innehållet kan ändras av filtret (i detta fall komprimerat)) och byteranges = ingen (filtret får endast användas för att slutföra filer).
På äldre versioner av Apache, den mod_deflate modulen används för att konfigurera DEFLATE-komprimering. Vi har mindre kontroll över hur innehållet filtreras i det här fallet, men direktiverna är enklare:
SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE text / html text / css text / javascript
I det här fallet ställer vi just komprimeringsalgoritmen med SetOutputFilter direktivet och ange sedan de innehållstyper vi vill komprimera med AddOutputFilterByType direktiv.
Vanligtvis använder din webbserver en av dessa moduler beroende på vilken version av Apache som används. Vanligtvis vet du detta på förhand, men om du skapar en generell .htaccess-fil som du kan använda på en mängd olika webbplatser, eller som du kanske delar med andra människor och därför inte vet vilka moduler som kan användas, du kan önska att använda båda ovanstående block av kod insvept i
Vi kollade på några av de vanligaste användningarna för .htaccess-filer och granskade hur vi kan uppnå vissa uppgifter som, som webbplatsbyggare / underhållare, är av särskilt intresse för oss. Såsom är fallet med någon introduktionshandledning av denna typ presenteras de ämnen vi har behandlat som introduktioner till ett visst ämne. Det finns många andra alternativ och konfigurationer än vi har kunnat titta på, så jag rekommenderar starkt vidare läsning om något ämne som är av särskilt intresse.
Accentsconagua