Share
Apache: s .htaccess-konfigurationsfiler har förvirrade otaliga utvecklare. Denna handledning syftar till att bryta igenom denna förvirring genom att fokusera på exempel och noggranna beskrivningar. Bland fördelarna med att lära. Htaccess-konfigurationen är automatisk gzipping av ditt innehåll, ger vänligare webbadresser, förhindrar hotlinking, förbättrar caching och mer.
Den här artikeln kommer att lära dig att konfigurera dina .htaccess-filer manuellt, men om du vill ha en enkel, snabb lösning, försök ladda ner .htaccess Builder från Envato Market. Det låter dig snabbt och enkelt leverera en htaccess-fil utan att behöva komma ihåg något om Apache-serverns språk som används för att konstruera htaccess-filen!
.htaccess Builder på Envato Market Jag har läst ett antal .htaccess-artiklar online. Jag erkänner skamlöst
Jag kom inte längre än den första sidan av Googles resultat. Jag blev chockad när
Jag läste verkligen artiklarna och fann att ingen av dem förklarade vad Apache egentligen var
gör. De var bara en samling av populära eller användbara tricks eller
utdrag av återanvändbar kod. Det är allt bra och bra, men den klassiska
argumentet är:
"Ge en man en fisk och han ska äta en dag. Lär en man att fiska och han
kommer att äta under en livstid. "
- Konfucius
I den här artikeln ska jag försöka att inte bara visa exempel på användbarhet
.htaccess-direktiv, men förklara exakt vad som är
pågår. På detta sätt förstår du kärnprinciperna och kan sedan förlänga
exempel eller skapa nya kommandon för egen användning, oavsett kreativa eller användbara sätt
du kan komma med.
Mitt fokus kommer att vara på Apache 2, men mycket av detta kommer att gälla
till Apache 1.3 och jag ska försöka peka på några skillnader som jag känner till.
Slutligen kommer denna handledning att ge dig mest mening om du läser det i ordning.
Jag försöker knyta mina exempel tillsammans och bygga upp dem i en sådan
sätt att du kan prova dem själv och följa med.
Att citera Apache:
.htaccess-filer (eller "distribuerade konfigurationsfiler") ger ett sätt att göra
konfigurationsändringar per per-basis. En fil som innehåller en eller flera
konfigurationsdirektiv, placeras i en viss dokumentkatalog och
Direktiv gäller för den katalogen och alla underkataloger därav.
"Direktiv" är den terminologi som Apache använder för kommandona i Apache
konfigurationsfiler. De är normalt relativt korta kommandon, vanligtvis
nyckelvärdespar, som ändrar Apaches beteende. En .htaccess-fil tillåter
utvecklare att genomföra en massa dessa direktiv utan att behöva ha tillgång till
Apaches kärna serverns konfigurationsfil, ofta heter httpd.conf. Den här filen,
httpd.conf, kallas vanligen "global konfigurationsfil" och jag kommer att göra det
hänvisa till det med det namnet eller dess korta filnamnekvivalent.
Den här funktionen är idealisk för många värdföretag som distribuerar en gemensam värd
miljö. Vertsföretaget tillåter inte sina kunder att komma åt
global konfigurationsfil, som i slutändan påverkar alla kunder som är värd för
den servern. I stället, genom att aktivera .htaccess, ger de var och en av sina kunder
makt att ange och genomföra sina egna Apache-direktiv i sig
kataloger och underkataloger. Det är självklart också användbart för singeln
utvecklare, som du kommer att se.
Det är värt att nämna att allt som kan göras med en .htaccess-fil kan
görs i httpd.conf-filen. dock, INTE allt som kan göras i
httpd.conf kan göras i en .htaccess-fil. Faktum är att .htaccess-filer måste vara
aktiverad i httpd.conf-filen för att kunna utföras alls. En gång aktiverad,
deras makt kan begränsas till vissa "sammanhang" så att de får tillåtas
att åsidosätta vissa inställningar men inte andra. Detta ger systemadministratörer
mer kontroll över vad de låter andra utvecklare komma undan med i deras
.htaccess-filer.
.htaccess-filer är normalt aktiverade som standard. Detta styrs faktiskt
genom AllowOverride-direktivet i httpd.conf-filen. Detta direktiv
kan bara placeras inuti a
du. Den typiska httpd.conf-filen definierar en DocumentRoot och majoriteten
av filen kommer att innehålla direktiv inom en
med den katalogen. Detta inkluderar AllowOverride-direktivet.
Standardvärdet är faktiskt "Allt" och därmed .htaccess-filer är aktiverade av
standard. Ett alternativt värde skulle vara "None" vilket skulle innebära att de är
helt inaktiverad. Det finns många andra värden som endast begränsar konfigurationen
vissa sammanhang. Några är:
Jag ska visa några exempel, utan deras motsvarande
Här är ett exempel som tillåter fullständig .htaccess överordnad:
# Tillåt .htaccess-filer sin fulla kraft AllowOverride All
Och här är ett exempel som tar en mer fin kornad tillvägagångssätt och tillåter bara
tvingande av tillstånd och indexer kontext men inget annat:
# Tillåt bara .htaccess-filer att åsidosätta behörighet och indexer Tillåt överför AuthConfig-index
Den första raden i båda dessa exempel är Apache kommentarer. Kommentarer startar
med symbolen "#". Detta är vanligt för många konfigurationsfiler och skript
språk. Jag har massor av kommentarer i mina exempel för att hjälpa till att förklara vad saker gör.
Men de är inte nödvändiga, och det är egentligen bara personlig preferens på hur mycket du
vill kommentera. Kommentarer är inte nödvändiga.
Den andra raden är själva AllowOverride-direktivet. Detta är den vanliga syntaxen för en
Apache-direktivet. Först finns det direktivnamnet "AllowOverride" följt av ett mellanslag
separerad lista över värden. Även om denna syntax ser ganska lös ut; var alltid försiktig.
Ibland kan även ett enda fel i din httpd.conf eller .htaccess-fil resultera i en
tillfällig smältning av servern, och användarna kommer att se 500 - intern serverfelsidor.
Av den anledningen är det bra att alltid säkerhetskopiera dina httpd.conf- och .htaccess-filer innan du gör en ändring eller tillägg. På så sätt, om något går fel med en ändring, kommer du att ha
inget att oroa dig för, för att du kan återgå till din tidigare arbetsversion. jag ska
uppmuntra dig också att göra små ändringar i taget och kontrollera att ändringarna fungerar
steg i stället för att göra ett antal ändringar på en gång. På det här sättet, om du gör det
Ett fel, det blir mycket lättare att spåra vad som kan ha orsakat det.
Om du någonsin är förvirrad på syntaxen i något direktiv, gå genast till
Apache-direktivet listar och granskar "Syntax" som de har listat i tabellen
för varje enskilt direktiv. Jag ska göra mitt bästa för att försöka förklara det här
(Jag försöker att lära) men min förklaring kan aldrig vara lika bra som
formell teknisk dokumentation själv. Var aldrig rädd för dokumentationen, det är det
din mest pålitliga och pålitliga referens Jag ska försöka göra sakerna mer intressanta
här (woohoo!), men i slutändan lägger jag bara en annan snurr på dessa dokument.
Det är ganska möjligt, det är faktiskt extremt troligt att ditt webbhotell inte gör det
ger dig tillgång till httpd.conf-filen. Så hur vet du om .htaccess-support är aktiverat
eller inte? Oroa dig inte. .Htaccess är en mycket vanlig och användbar funktion som de flesta företag kommer att göra
har aktiverat, eller kommer att aktivera om du frågar hövligt.
Det bästa du bör göra är att bara kolla med ditt webbhotell. Om det inte är explicit
listade var som helst i din värdplan, skjut sedan deras support ett mail. Detta är en relativt vanlig
fråga så de mest sannolikt redan har ett svar redo för dig. De kommer sannolikt vara villiga
för att aktivera tjänsten eller åtminstone ge en anledning till varför de inte tillåter det.
Under alla omständigheter kan du alltid ge det ett skott och se om en enkel .htaccess-fil fungerar!
Innehållet i den här handledningens provhämtning är två sätt som du kan kolla om du vill se om .htaccess
support är aktiverat. De två mapparna är "is_htaccess_enabled" och "is_htaccess_enabled_2".
Ge dem ett skott, jag förklarar vad var och en gör här.
Detta testfall är väldigt enkelt. Det använder ett direktiv för att göra Apache utseende
först för "indexetgood.html "filen före" index.html. "Om .htaccess-support är
aktiverat, när du pekar webbläsaren till mappen kommer Apache att ladda .htaccess-filen och känner till den
Det ska visa "indexetgood.html "-sidan med ett grönt meddelande som säger grattis!
Om .htaccess-support inte är aktiverat, ignorerar Apache som standard .htaccess
filen och leta efter en index.html-fil.
# Detta direktiv kommer att göra Apache se först # för "index_good.html" innan man letar efter "index.html" DirectoryIndex index_good.html index.html
DirectoryIndex-direktivet tar en mellanseparerad lista över potentiella filnamn.
När Apache ges en URL till en katalog, och inte en direkt sida (till exempel
http://www.example.com och inte http://www.example.com/index.html) Apache använder det här
lista med filer för att söka efter rätt sida att ladda. Apache letar efter filerna
Använd värdena i listan från vänster till höger. Den första filen som Apache ser existerar
kommer att vara filen som den laddas och visas till klienten.
Använda ovanstående .htaccess-fil, här är ett exempel på de bra (aktiverade) och dåliga (inaktiverade) fallen:
Som jag sa tidigare kommer ett syntaxfel i din .htaccess-fil att orsaka servern till hicka.
Du kan använda detta till din fördel för att testa om din server har .htaccess support aktiverat!
Här är ett exempel på en .htaccess-fil som är avsedd att spränga upp.
# Den här filen är avsedd att göra Apache uppblåst. Detta kommer att hjälpa # bestämma om .htaccess är aktiverat eller inte! ahhhhhhh
Det är ganska klart att "AHHHHHHH" inte är ett giltigt Apache-direktiv. Detta kommer att orsaka
ett fel om Apache försöker läsa .htaccess filen! Så, om du kommer tillbaka en sida skriker
"Internt serverfel" så ser din server efter .htaccess-filer! Om du faktiskt
se innehållet i index.html-filen, då är det troligt att de har inaktiverats. Här är igen de goda och dåliga fallen:
Slutligen är det fortfarande möjligt att .htaccess-support fortfarande är aktiverat, bara med
unika inställningar. Systemadministratörer kan bara ändra namnet på .htaccess-filen
som vi ändrade namnet på den standardfil som Apache letar efter. Detta är möjligt av
med hjälp av AccessFileName
direktivet i den globala konfigurationsfilen. Återigen är det bästa att göra i det fallet att
kontakta ditt webbhotell för mer information.
Innan jag kommer in i några av de coola sakerna du kan göra med .htaccess-filer, måste jag
berätta vad du kommer in i. Som jag nämnde tidigare tillåter du
överordnade serverinställningar för en katalog och alla dess underkataloger. Alltid
Tänk på att du påverkar alla underkataloger såväl som nuvarande
katalog.
När det är aktiverat tar servern också en potentiell prestationsfrekvens. Anledningen är att, varje serverförfrågan, om .htaccess-support är aktiverat, när Apache går för att hämta den begärda filen för klienten, måste den leta efter en .htaccess-fil i varje enskild katalog som leder upp till var filen är lagrad.
Detta betyder ett antal saker. Först eftersom Apache alltid söker efter .htaccess-filer
På varje förfrågan kommer alla ändringar i filen att träda i kraft omedelbart.
Apache cache inte dem, och det kommer omedelbart se dina ändringar på nästa förfrågan.
Men det innebär också att Apache kommer att behöva göra lite extra arbete för varje förfrågan.
Till exempel, om en användare begär /www/supercool/test/index.html, då din server
skulle kolla efter följande .htaccess-filer:
/www/.htaccess /www/supercool/.htaccess /www/supercool/test/.htaccess
Dessa potentiella filåtkomster (potentiella eftersom filerna kanske inte existerar) och deras
utförande (om de fanns) tar tid. Återigen är min erfarenhet att det är
unnoticeable och det uppväger inte fördelarna och flexibiliteten som .htaccess
filer ger utvecklare.
Om det här gäller dig, så länge du har tillgång till httpd.conf-filen
då kan du alltid sätta dina riktlinjer där. Genom att ställa AllowOverride till "None"
Apache söker inte efter dessa .htaccess-filer. Om du verkligen vill kan du sätta
de direktiv du ville lägga i din /www/supercool/test/.htaccess-fil
direkt i httpd.conf så här:
# Sätt direktiv här
Nackdelen med detta tillvägagångssätt är att du måste starta om Apache-servern
på varje förändring så att den laddar upp den nya konfigurationen.
I slutändan kommer det ner till personliga preferenser eller vad din värd tillåter.
Jag föredrar att använda .htaccess-filer eftersom jag har flexibilitet att placera dem där
Jag vill, och deras effekter lever direkt omedelbart utan att det krävs en serveråterställning.
Innan vi börjar med några av de komplexa funktionerna, låt oss börja med något
enkelt men användbart, så att du kan få en känsla för att arbeta med .htaccess-filer.
Directory Listings är så vanliga att du har antagligen stött på dem många
gånger på webben.
När en användare begär en katalog söker Apache först efter standardfilen. Vanligen kommer det att kallas "index.html" eller "index.php" eller något liknande. När det inte gör det
hitta en av dessa filer, faller den tillbaka på mod_autoindex-modulen till
visa en lista över filer och mappar i den katalogen. Ibland här
är aktiverad, ibland inaktiverad och ibland vill du
göra anpassningar. Tja, med .htaccess kan du enkelt manipulera dessa listor!
Som standard är katalogannonser aktiverade. Här är ett exempel scenario.
Antag att du har en massa mediefiler som du lagrar på din webbserver,
och du vill gömma dem från allmänheten och sökmotorerna så att ingen kan
stjäla dessa filer. Det är väldigt lätt att göra! Skapa bara en .htaccess-fil
i katalogen som du vill gömma och lägg till följande direktiv:
# Inaktivera katalogförteckningar i den här katalogen och underkataloger # Det här kommer att dölja filerna från allmänheten om de inte vet direktadresser. Alternativ -Indexes
Att bryta ner det här använder vi alternativdirektivet.
Detta direktiv kan ta ett antal värden (nämnd tidigare). Om du anger värdena
med + eller - som jag gjorde med -Indexes, då kommer detta att ärva den
Alternativ som aktiverades i högre kataloger och den globala konfigurationen!
Om du inte anger + eller - kommer listan som du tillhandahåller bli
de endast alternativ aktiverade för den katalogen och dess underkataloger. Inga andra alternativ aktiveras. Eftersom du kanske inte vet vilka alternativ som aktiverades tidigare, kommer du med största sannolikhet
använd + eller - syntaxen om du inte är helt säker på dig endast vill ha vissa alternativ.
Nu, med det direktivet i din .htaccess-fil, när du pekar din webbläsare till den katalogen
Du kommer inte längre kunna se filerna. Här är före och efter:
Okej, kanske helt inaktiverande Directory Index är inte vad du vill. Det är mer
sannolikt att du vill behålla indexerna men bara tillåta vissa personer att komma åt.
Det är där grundläggande autentisering kan vara mycket användbar. Detta är det vanligaste
typ av autentisering på webben. När användaren försöker komma åt sidan de
kommer att se den välbekanta användarnamn / lösenordsdialogrutan. Endast en användare med rätt
referenser kommer att kunna komma åt innehållet.
För grundläggande autentisering finns det bara två steg.
Traditionellt har webbutvecklare namngivit filen som lagrar användarnamnen och
lösenord ".htpasswd". Detta beror på att kommandoradsverktyget som skickas med
Apache som genererar det korrekta krypterade användarnamnet / lösenordsparet är faktiskt
kallas htpasswd! Om du känner dig bekväm på kommandoraden kan du använda htpasswd
verktyg, men det finns många onlineverktyg som genererar produktionen lika enkelt.
Jag skapade ett exempel .htpasswd-fil för en användare "Joe" med lösenord "cool".
Jag kastade dessa värden i det länkade onlineverktyget och det producerade:
joe: $ apr1 $ QneYj / ... $ 0G9cBfG2CdFGwia.AHFtR1
Din produktion kan vara annorlunda, det är okej. Lösenorden är hashed med
ett slumpmässigt salt för att göra dem lite mer unika och säkra. En gång ditt användarnamn
och lösenordskombinationen har lagts till i .htpasswd-filen, då borde du
lägg till följande rader i din fil:
# Aktivera grundläggande autentisering AuthType Basic # Det här är vad som kommer att visas för användaren i inloggningsdialogrutan. AuthName "Åtkomst till de dolda filerna" # Det här måste du redigera. Det är den absoluta vägen till .htpasswd-filen. AuthUserFile /path/to/.htpasswd # Det här låter någon användare från insidan av .htpasswd-filen få åtkomst till # -halten om de anger rätt användarnamn och lösenord. Kräv giltig användare
Dessa kommandon är väl dokumenterade. Den enda verkliga utmaningen är att du
måste ställa in sökvägen till den .htpasswd-filen som du bara har
genererad. Detta är en fullständig absolut väg från den absoluta roten av
server. Dessutom, eftersom .htpasswd-filvägen är absolut är det bra
öva att lägga den i en katalog utanför katalogen där Apache
serverar webbsidor till allmänheten. På så sätt kan skadliga användare inte kunna
för att enkelt få tillgång till den råa listan över användare / lösenord som lagras i .htpasswd.
När det är klart, när någon försöker komma åt sidan kommer de att göra det
få följande dialog:
Grundläggande autentisering är fin och enkel, men det är inte en total lösning.
Lösenorden skickas över kabeln, bas 64 kodad, i vanlig text. Om du
vill ha säkrare autentisering bör du koppla till grundläggande autentisering
med https, en mer
säkert protokoll. Det är ett ämne för en annan tid.
Kärnprotokollet på webben är Hypertext Transfer Protocol (HTTP).
Om du verkligen vill förstå vad resten av Apache-direktiven gäller
hantera, du borde ha lite kunskap om protokollet. Jag är
bara går till su pplya mycket snabb sammanfattning här. Jag ska också göra en ansträngning
att förklara vad de mer komplexa direktiven gör, men det kommer att göra
mer meningsfullt om du förstår HTTP Headers.
Den snabba sammanfattningen är att HTTP är statslös. Med varje förfrågan (från webbläsaren)
och varje svar (från webbservern som Apache) finns det två avsnitt.
En sektion av rubrikinformation, sedan en valfri sektion som innehåller själva data,
om det finns några data.
Begär information om huvudinformation anger ofta vilken fil de är
begär från servern (index.html), vilken statlig information de ska tillhandahålla
(t.ex. cookiedata) och mime-typerna är det villigt att acceptera tillbaka från servern
(text / html eller till och med gzip kodat innehåll).
Svarhuvudinformation anger ofta generisk serverinformation (Apache, PHP,
Perl-versioner etc.), innehållskodning, längd, mime / typ och mer. där
är en uppsjö av HTTP-rubriker för att ange ännu mer detaljer som Cache Control,
Omdirigeringar och statuskoder. Har du någonsin 404? Det var ett resultat av att begära a
filen servern inte kunde hitta, och sålunda skickades den tillbaka en 404
Statuskod i dess
Svar.
Vad har detta att göra med .htaccess? Tja, du kan använda Apache-riktlinjer till
skriv över (lägg till) eller lägg till nya rubriker (lägg till) som skickas tillbaka till klienten
i rubrikens rubrik. Också, som du kommer att se i senare handledning,
mer avancerad funktionalitet som URL-omskrivning handlar om inkommande rubriker.
Låt oss börja enkelt, vi lägger till en rubrik till svaret och se vad som händer:
# Lägg till följande rubrik för varje svar Header add X-HeaderName "Header Value"
Begär en fil i samma katalog som den här .htaccess-filen visar
extra rubrik:
Du trodde antagligen att det var märkligt att jag prefixade den anpassade rubriken med
”X”. Detta är faktiskt en vanlig konvention som utvecklare använder för att beteckna det
rubriken är en icke-standardrubrik. Detta gör det väldigt enkelt att inse att den här rubriken är anpassad. Denna konvention är
kort nämnt här.
På en mer komisk anteckning har vissa människor haft lite kul med rubriker.
Denna sajt
påpekar några ganska ovanliga rubriker som finns över hela webben.
Men jag vill verkligen visa dig hur du skapar Headers så att du kan
använd dem som en felsökningsteknik. Just den andra dagen körde jag ett test till
kolla om vissa moduler skulle aktiveras på en webbserver. jag skrev
följande kontroll:
Header lägg till X-Enabled mod_gzip Header lägg till X-Enabled mod_deflate
När jag gjorde min nästa förfrågan med min webbläsare och kollade på Response Headers, den
visade att ingen av modulerna var påslagen! Jag kontaktade mitt webbhotell, och de kom överens om att möjliggöra gzip-komprimering!
Det finns en skillnad mellan rubrikuppsättning och
Header add. Med Lägg till kommer rubriken alltid lägg till
till svaret. Även om det råkar visas flera gånger i svaret. Detta är oftast
vad du vill ha för anpassade rubriker. Du skulle använda set när du vill
åsidosätta värdet på en av de standardhuvuden som Apache returnerar. En
Exempel skulle överväga den mime / typ som anges av innehållstypen
rubrik för en viss fil. Apache skulle ställa in det interna värdet och sedan
använd det när det skriver ut standardrubriken. Det kommer att finnas nej
dubbletter, och därmed ingen möjlighet att tolka ett fel eller förvirring
av kunden. (Om du undrade, anges i HTTP-specifikationen att, i
Om det gäller dubbletter, ska klienten alltid använda det angivna sista värdet
för den dubbla rubriken.)
Jag har gått över några grundläggande Apache-direktiv i ganska lite detalj. Jag ville få de grundläggande detaljerna ur vägen så att nästa handledning kan diskutera svalare saker. Min nästa artikel kommer att
fokusera på några av de mer användbara funktionerna du kan aktivera med .htaccess.
Dessa ämnen kommer att innehålla:
Och glöm inte, om du kämpar för att följa detta, är ett annat alternativ att försöka .htaccess Builder-verktyget tillgängligt på Envato Market.
Accentsconagua