2020 Komplett guide till .HTACCESS – från grunderna till avancerat lärande

Avslöjande: Ditt stöd hjälper till att hålla webbplatsen igång! Vi tjänar en remissavgift för några av de tjänster vi rekommenderar på denna sida.


Med hjälp av .htaccess-filen kan du styra många aspekter av Apache-webbservern (och dess många varianter). Nedan lär du dig allt du behöver veta ställa in speciella felsidor, kataloger med lösenordsskydd, omdirigering och mycket mer.

Contents

Så här använder du den här guiden

Den här guiden byggdes för att fungera som en omfattande resurs för användning av .htaccess. Om du är helt ny på att använda .htaccess – kanske du vill börja med det första kapitlet “.htaccess Basics” nedan.

Om du söker efter specifika kodprover eller självstudier tittar du på navigeringen till höger på denna sida för att hoppa direkt till underavsnitt på denna sida.

.htaccess Grunderna

Låt oss bekanta oss med några .htaccess-grundläggande innan vi dyker in i kommandon.

Vad är .htaccess?

.Htaccess-filen är en konfigurationsfil som styr hur en webbserver svarar på olika förfrågningar. Det stöds av flera webbserver, inklusive den populära Apache webbservern som används av de flesta kommersiella webbhotellleverantörer.

.htaccess-filer fungerar på en katalognivå, vilket gör att de kan åsidosätta globala konfigurationsinställningar för .htaccess-direktiv högre i katalogträdet.

Hur används .htaccess?

Några vanliga användningar för .htaccess inkluderar omdirigering av URL: er, vilket möjliggör lösenordsskydd för webbplatser (eller webbplatser); visa anpassade felsidor (t.ex. 404 sidor); och öka SEO genom en konsekvent slash-policy.

I det senare fallet kan webbansvarig välja att antingen kräva en släp i slutet av varje URL på en webbplats eller inte.

Varför kallas det .htaccess?

.htaccess står för “hypertext access.” Namnet härstammar från verktygets ursprungliga användning som var att kontrollera användaråtkomst till vissa filer per katalogbasis.

Med hjälp av en delmängd av Apaches http.conf-inställningsdirektiv, tillät .htaccess en systemadministratör att begränsa åtkomst till enskilda kataloger till användare med ett namn och lösenord som anges i en bifogad .htpasswd-fil.

Medan .htaccess-filer fortfarande används för detta, används de också för ett antal andra saker som vi kommer att täcka i den här guiden.

Var är .htaccess-filen?

I teorin kan varje mapp (katalog) på din server ha en. Men i allmänhet finns det en i din webbrotmapp – det är den mapp som innehåller allt innehåll på din webbplats och vanligtvis är märkt som public_html eller www.

Om du har en enda katalog som innehåller flera underkataloger för webbplatser kommer det vanligtvis att finnas en .htaccess-fil i huvudrotkatalogen (public_html) och även en i varje underkatalog (/ sitename).

Varför kan jag inte hitta min .htaccess-fil?

I de flesta filsystem är filnamn som börjar med en punkt (.) Dolda filer. Det betyder att de inte vanligtvis är synliga som standard.

Men de är inte svåra att komma till. Din FTP-klient eller filhanterare bör ha en inställning för “visa dolda filer.” Detta kommer att finnas på olika platser i olika program, men är vanligtvis i “Inställningar”, “Inställningar” eller “Mappalternativ.” Någon gång hittar du det i “Visa” -menyn.

Vad händer om jag inte har en .htaccess-fil?

Först och främst, se till att du har aktiverat ”visa dolda filer” (eller motsvarande) så att du kan vara säker på att du faktiskt inte har en. Ofta skapas .htaccess-filer automatiskt, så du har vanligtvis en. Men detta är inte alltid fallet.

Om du verkligen inte har en kan du enkelt skapa en:

  • Starta en ny fil i en vanlig textredigerare.
  • Spara det i ASCII-format (inte UTF-8 eller något annat) som .htaccess.
    • Se till att det inte är htaccess.txt eller något liknande. Filen bör bara ha namnet .htaccess utan ytterligare filändelse.
  • Ladda upp den till rätt katalog via FTP eller din webbläsarbaserade filhanterare.

Felhantering

Att använda .htaccess-filer för att specificera feldokument är mycket enkelt, en av de enklaste saker du kan göra med den här funktionen.

Vad är en felkod?

När en begäran görs till en webbserver försöker den att svara på den begäran, vanligtvis genom att leverera ett dokument (i fallet med HTML-sidor), eller genom att få åtkomst till en applikation och returnera utdata (i fallet med Content Management Systems och andra webbappar).

Om något går fel med detta genereras ett fel. Olika typer av fel har olika felkoder. Du känner förmodligen 404-felet, som returneras om dokumentet inte kan hittas på servern.

Det finns många andra felkoder som en server kan svara med.

Klientbegäran fel

  • 400 Dålig Förfrågan
  • 401 – Behörighet krävs
  • 402 – Betalning krävs (har inte använts ännu)
  • 403 – Förbjuden
  • 404 Ej Hittad
  • 405 – Metod ej tillåten
  • 406 – Ej acceptabelt (kodning)
  • 407 – Proxy-verifiering krävs
  • 408 – Begäran avbruten
  • 409 – Konfliktförfrågan
  • 410 – Borta
  • 411 – Innehållslängd krävs
  • 412 – Förutsättningen misslyckades
  • 413 – Begär enhet för lång
  • 414 – Begär URI för länge
  • 415 – Medietyp som inte stöds.

Serverfel

  • 500 – Internt serverfel
  • 501 – Ej genomförd
  • 502 – Bad Gateway
  • 503 Tjänst Otillgänglig
  • 504 Gateway Time-out
  • 505 – HTTP-version stöds inte.

Standardfelhantering

Om du inte anger någon typ av felhantering returnerar servern helt enkelt meddelandet till webbläsaren och webbläsaren visar ett generiskt felmeddelande till användaren. Detta är vanligtvis inte idealiskt.

Ange felhandlingar

Skapa ett HTML-dokument för varje felkod du vill hantera. Du kan namnge vad du vill, men det är bra att namnge dem något som hjälper dig att komma ihåg vad de är till för, som not-found.html eller helt enkelt 404.html.

Sedan anger du i .htaccess-filen vilket dokument som ska användas för varje felstyp.

ErrorDocument 400 /errors/bad-request.html
ErrorDocument 401 /errors/auth-reqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/not-found.html
ErrorDocument 500 /errors/server-err.html

Lägg märke till att varje direktiv placeras på sin egen linje.

Och det är allt. Väldigt enkelt.

alternativ till .htaccess för felhantering

De flesta innehållshanteringssystem (CMS) som WordPress och Drupal och de flesta webbappar kommer att ha sitt eget sätt att hantera de flesta av dessa felkoder.

Lösenordsskydd med .htaccess

Det ursprungliga syftet med .htaccess-filer var att begränsa åtkomsten till vissa kataloger per användare (därav namnet, hypertextåtkomst). Så vi kommer att titta på det först.

.htpasswd

Användarnamn och lösenord för .htaccess-systemet lagras i ett filnamn .htpasswd.

Dessa lagras var och en på en enda rad i formen:

Användarnamn: encryptedpassword

till exempel:

johnsmith: F418zSM0k6tGI

Det är viktigt att inse att lösenordet som lagras i filen inte är det faktiska lösenordet som används för att logga in. Det är snarare en kryptografisk hash för lösenordet.

Detta innebär att lösenordet har körts genom en krypteringsalgoritm och resultatet lagras. När en användare loggar in, anges lösenordet med vanlig text och körs genom samma algoritm. Om ingången är densamma matchar lösenorden och användaren ges åtkomst.

Att lagra lösenord på detta sätt gör dem säkrare – om någon skulle få tillgång till din .htpasswd-fil skulle de bara se hashade lösenord, inte originalen. Och det finns inget sätt att rekonstruera original från hash – det är en envägskryptering.

Flera olika hashningsalgoritmer kan användas:

  • Säkra algoritmer – Använd en av dessa
    • bcrypt – Detta är det säkraste, men också det långsammaste att beräkna. Det stöds av Apache och Nginx.
    • md5 – Detta är den standard hash-algoritmen som används av nuvarande versioner av Apache. Det stöds inte av Nginx.
  • Osäkra algoritmer – Använd inte
    • crypt () – Det brukade tidigare vara hash-funktionen, men den är inte särskilt säker.
    • SHA och saltad SHA.

Skapa användarnamn och lösenord på kommandoraden

Du kan skapa en .htpasswd-fil och lägga till användarnamn-lösenordspar till den direkt från kommandoraden eller SSH-terminalen.

Kommandot för att hantera .htpasswd-filen är helt enkelt htpasswd.

För att skapa en ny .htpasswd-fil använder du kommandot med alternativet -c (för att skapa) och skriver sedan sökvägen till katalogen (inte URL: n, den aktuella sökvägen på servern). Du kan också inkludera en användare som du vill lägga till.

> htpasswd -c /usr/local/etc/.htpasswd johnsmith

Detta skapar en ny .htpasswd-fil i katalogen / etc / och lägger till en post för en användare med namnet johnsmith. Du blir ombedd att få ett lösenord som också kommer att lagras med md5-krypteringen.

Om det redan finns en .htpasswd-fil på den angivna platsen skapas inte en ny – den nya användaren läggs helt enkelt till den befintliga filen.

Om du föredrar att använda hasc-algoritmen bcrypt använder du alternativet -b.

Lösenord Hashing utan kommandoraden

Om du inte trivs med att använda kommandoraden eller SSH-terminalen (eller om du av någon anledning inte har tillgång till den) kan du helt enkelt skapa en .htpasswd-fil och fylla den med en vanlig textredigerare och ladda upp den via FTP eller filhanterare.

Men då måste du kryptera dina lösenord på något sätt, eftersom htpasswd-kommandot tog hand om det åt dig.

Det finns många .htpasswd-krypteringsverktyg tillgängliga online. Den bästa är förmodligen htpasswd-generatorn på Aspirine.org.

Detta ger dig flera alternativ för hash-algoritm och lösenordsstyrka. Du kan helt enkelt kopiera och klistra in utmatningen därifrån till din .htpasswd-fil.

Var du ska behålla din .htpasswd-fil

Du behöver inte ha en separat .htpasswd-fil för varje .htaccess-fil. I själva verket borde du inte göra det. Under de flesta normala omständigheter bör du ha ett för hela webbhotellkontot eller huvudserverkatalogen.

.Htpasswd-filen bör inte finnas i en offentligt tillgänglig katalog – inte public_html eller www eller någon underkatalog. Det borde ligga över dem, i en mapp som bara är tillgänglig från själva servern.

Hur man använder .htpasswd med .htaccess

Varje katalog kan ha sin egen .htaccess-fil, med en egen uppsättning användare som får komma åt den.

Om du vill att någon (inklusive användare som inte är inloggade) ska komma åt katalogen och dess filer, gör helt enkelt ingenting – det är standard.

För att begränsa åtkomst måste du lägga till följande i .htaccess-filen:

AuthUserFile /usr/local/etc/.htpasswd
AuthName "Namn på det säkra området"
AuthType Basic

kräver giltig användare

Den första raden anger sökvägen och filnamnet till din lista med användarnamn och lösenord. Den andra raden anger ett namn för det säkrade området. Detta kan vara vad du vill. Den tredje raden anger “Grundläggande” autentisering, vilket är vad du vanligtvis behöver.

Taggen anger vad som kommer att begränsas (i detta fall möjligheten att GET eller POST till vilken fil som helst i katalogen). Inom paret av taggar finns en lista över vem som har åtkomst till filer.

I exemplet ovan kan alla giltiga användare komma åt filer. Om du vill begränsa åtkomsten till en viss användare eller få användare kan du namnge dem.

AuthUserFile /usr/local/etc/.htpasswd
AuthName "Namn på det säkra området"
AuthType Basic

kräver användar johnsmith
kräver användar janedoe

Du kan också placera användare i grupper och tillåta åtkomst baserat på grupp. Detta görs genom att lägga till en annan fil som anger grupperna.

Gruppfilen som kan namnges (till exempel) .htgroups ser ut så här:

admin: johnsmith janedoe
personal: jackdoe cindysmith

Sedan kan du ange den i din .htaccess-fil:

AuthUserFile /usr/local/etc/.htpasswd
AuthGroupFile /usr/local/etc/.htgroup
AuthName "Administratörsområde"
AuthType Basic

kräver gruppadministratör

Alternativ till .htpasswd

Att använda .htaccess och .htpasswd för att begränsa åtkomst till vissa filer på din server är bara riktigt meningsfullt om du har en hel del statiska filer. Funktionen utvecklades när webbplatser vanligtvis var en samling av HTML-dokument och relaterade resurser.

Om du använder ett innehållshanteringssystem (CMS) som WordPress eller Drupal kan du använda de inbyggda användarhanteringsfunktionerna för att begränsa eller ge åtkomst till innehåll.

Aktivera serversidan inkluderar (SSI)

Låt oss nu veta vad serversidan inkluderar och hur du kan använda dem.

Vad är serversidan inkluderar?

SSI, eller Server Side Includes, är ett lätt skriptspråk som främst används för att bädda in HTML-dokument i andra HTML-dokument. Detta gör det enkelt att återanvända vanliga element, till exempel sidhuvuden, sidfot, sidofält och menyer. Du kan tänka på det som en föregångare till dagens system för mallar och innehållshantering.


SSI har också villkorade direktiv (om, annat osv.) Och variabler, vilket gör det till ett komplett, om något svårt att använda, skriptspråk. (Vanligtvis kommer alla projekt som är mer komplicerade än en handfull medför att en utvecklare väljer ett mer robust språk som PHP eller Perl.)

Aktiverar SSI

Vissa webbhotellserver har Server Side Inclays aktiverat som standard. Om inte, kan du aktivera den med din .htaccess-fil, så:

AddType text / html .shtml
AddHandler server-parsed .shtml
Alternativ Index FollowSymLinks Inkluderar

Detta bör aktivera SSI för alla filer som har .shtml-förlängningen.

SSI på .html-filer

Om du vill aktivera SSI-parsing på .html-filer kan du lägga till ett direktiv för att göra det:

AddHandler server-parsed .html

Fördelen med att göra detta är att du kan använda SSI utan att låta världen veta att du använder den. Om du ändrar implementeringar i framtiden kan du behålla dina .html-filändelser.

Nackdelen med detta är att varje .html-fil kommer att analyseras med SSI. Om du har många .html-filer som faktiskt inte behöver någon SSI-parsing, kan detta introducera en hel del onödiga serverkostnader, bromsa dina sidbelastningstider och använda CPU-resurser.

SSI på din indexsida

Om du inte vill analysera alla .html-filer, men du vill använda SSI på din indexsida (hemsida) måste du ange det i din .htaccess-fil.

Det beror på att när webbservern letar efter en katalogs indexsida letar den efter index.html, såvida du inte säger något annat.

Om du inte analyserar .html-filer behöver du din indexsida för att få namnet index.shtml för att SSI ska fungera och servern vet inte att leta efter det som standard.

För att aktivera det, lägg bara till:

DirectoryIndex index.shtml index.html

Detta varnar webbservern om att filen index.shtml är huvudindexfilen för katalogen. Den andra parametern, index.html är en säkerhetskopia, om index.shtml inte kan hittas.

IP-svartlistning och IP-vitlistning

Du kan använda .htaccess för att blockera användare från en specifik IP-adress (svartlista). Detta är användbart om du har identifierat enskilda användare från specifika IP-adresser som har orsakat problem.

Du kan också göra omvänt och blockera alla utom besökare från en specifik IP-adress (vitlista). Detta är användbart om du behöver begränsa åtkomst till endast godkända användare.

Svartlista efter IP

För att blockera specifika IP-adresser använder du bara följande direktiv med lämpliga IP-adresser:

beställ tillåta, förneka
förneka från 111.22.3.4
förneka från 789.56.4.
tillåta från alla

I den första raden anges att tillståndsdirektiven kommer att utvärderas först innan direktivet förnekas. Detta innebär att tillåtelse från alla kommer att vara standardtillståndet, och då kommer bara de som matchar förnekningsdirektiven att nekas.

Om detta vändes för att beställa förneka, tillåta, så skulle det sista som utvärderats vara tillåtet från allt direktiv, vilket skulle tillåta alla, åsidosätta förnekande uttalanden.

Lägg märke till den tredje raden, som har förnekats från 789.56.4. – det är inte en fullständig IP-adress. Detta avvisar alla IP-adresser inom det blocket (alla som börjar med 789.56.4).

Du kan inkludera så många IP-adresser du vill, en på varje rad, med ett förnekande från direktivet.

Vitlista efter IP

Det motsatta av svartlistan är vitlista – begränsar alla utom de du anger.

Som ni kan gissa måste orderdirektivet omvändas så att alla först nekas, men då är vissa adresser tillåtna.

beställ neka, tillåt
förneka från alla
tillåt från 111.22.3.4
tillåt från 789.56.4.

Blockera åtgärder

.htaccess kan användas för att blockera användare efter domän eller referens. Och du kan använda den för att blockera bots och skrapor. Låt oss ta reda på hur.

Hur man blockerar användare efter domän

Du kan också blockera eller tillåta användare baserat på ett domännamn. Detta kan hjälpa till att blockera människor även när de går från IP-adress till IP-adress.

Detta kommer emellertid inte att fungera mot människor som kan kontrollera deras IP-adresskartläggning för omvänd DNS.

beställ tillåta, förneka
förneka från exempel.com
tillåta från alla

Detta fungerar också för underdomäner – i föregående exempel kommer besökare från xyz.example.com också att blockeras.

Så här blockerar du användare med hänvisare

En hänvisare är webbplatsen som innehåller en länk till din webbplats. När någon följer en länk till en sida på din webbplats är webbplatsen de kom från referensen.

Men detta fungerar inte bara för klickbara hyperlänkar till din webbplats.

Sidor var som helst på internet kan länka direkt till dina bilder (“hotlinking”) – med hjälp av din bandbredd och eventuellt kränka din upphovsrätt, utan att ge dig någon fördel för trafiken. De kan också hotlänk till dina CSS-filer, JS-skript eller andra resurser.

De flesta webbplatsägare är okej med det här när det händer bara lite, men ibland kan den här typen av saker förvandlas till missbruk.

Dessutom är ibland faktiska inklickbara hyperlänkar problematiska, till exempel när de kommer från fientliga webbplatser.

Av något av dessa skäl kanske du vill blockera förfrågningar som kommer från specifika referenser.

För att göra detta behöver du mod_rewrite-modulen aktiverad. Detta är som standard aktiverat för de flesta webbhotell, men om det inte är det (eller du är osäker) kan du vanligtvis bara fråga ditt webbhotell. (Om de inte kan eller inte aktiverar det, kanske du vill tänka på en ny värd.)

.Htaccess-direktiven som uppnår referensbaserad blockering är beroende av mod_rewrite-motorn.

Koden som ska blockeras med hänvisare ser ut så här:

RewriteEngine on
RewriteCond% ^ http: //.*example.com [NC, OR]
RewriteCond% ^ http: //.*anotherexample.com [NC, OR]
RewriteCond% ^ http: //.*onemoreexample.com [NC]
RewriteRule. * – [F]

Det här är lite knepigt, så låter oss gå igenom det.

Den första raden, RewriteEngine on, varnar parsaren om att en serie direktiv relaterade till omskrivning kommer.

De nästa tre raderna blockerar var och en en referensdomän. Den del du skulle behöva ändra för eget bruk är domännamnet (exempel) och tillägg (.com).

Bakåtstrecket före. Com är ett flyktecken. Mönstermatchningen som används i domännamnet är ett regelbundet uttryck, och punkten betyder något i RegEx, så det måste “undkomma” med back-snedstrecket.

NC i parenteserna anger att matchen inte ska vara skiftlägeskänslig. OR är en bokstavlig “eller” och betyder att det kommer andra regler. (Det vill säga – om webbadressen är den här eller den här eller den här, följ denna omskrivningsregel.)

Den sista raden är den faktiska omskrivningsregeln. [F] betyder “förbjuden.” Eventuella förfrågningar med en referens som matchar dem i listan misslyckas och levererar ett 403 förbjudet fel.

Blockering av bots och skrapor

En av de mer irriterande aspekterna av att hantera en webbplats är att upptäcka att din bandbredd äts upp av besökare som inte är mänskliga – bots, sökrobotar, webbskrapare.

Det här är program som är utformade för att dra ut information från din webbplats, vanligtvis i syfte att publicera den som en del av någon låggradig SEO-operation.

Där är naturligtvis legitima bots – som de från stora sökmotorer. Men resten är som skadedjur som bara äter bort på dina resurser och inte ger dig något värde för dig.

Det identifieras flera hundra bots. Du kommer aldrig att kunna blockera dem alla, men du kan hålla aktiviteten nere till ett tråkigt brus genom att blockera så många du kan.

Det finns en användbar uppsättning omskrivningsregler som blockerar över 400 kända bots som sammanställts av AskApache.

Ange en standardfil för en katalog

När en begäran görs till en webbserver för en URL som inte anger ett filnamn är antagandet inbyggt i de flesta webbservrar att webbadressen refererar till en katalog.

Så om du begär http://example.com, kommer Apache (och de flesta andra webbservrar) att leta i rotkatalogen efter domänen (vanligtvis / public_html eller något liknande, men kanske / exempel-com) som standard fil.

Standardfilen kallas som standard index.html. Detta går långt tillbaka till början av internet när en webbplats bara var en samling av dokument, och “hemsidan” var vanligtvis ett index för dessa dokument.

Men du kanske inte vill att index.html ska vara standardsidan. Du kan till exempel behöva en annan filtyp, som index.shtml, index.xml eller index.php.

Eller så kanske du inte tänker på din hemsida som ett “index” och vill kalla det något annat, till exempel home.html eller main.html.

Ställa in standardkatalogsidan

.htaccess kan du enkelt ställa in standardsidan för en katalog:

DirectoryIndex [filnamn här]

Om du vill att din standard ska vara hem.html är det lika enkelt som:

DirectoryIndex home.html

Ställa in flera standardsidor

Du kan också ange mer än en DirectoryIndex:

DirectoryIndex index.php index.shtml index.html

Så här fungerar det är att webbservern letar efter den första först. Om den inte hittar det ser den efter den andra osv.

Varför skulle du vilja göra detta? Visst vet du vilken fil du vill använda som standardsida, rätt?

Kom ihåg att .htaccess påverkar sin egen katalog och alla underkataloger tills den åsidosätts av en mer lokal fil. Detta innebär att en .htaccess-fil i din rotkatalog kan ge instruktioner för många underkataloger, och var och en kan ha sitt eget standardsidesnamn.

Att kunna placera dessa regler i en enda .htaccess-fil i roten innebär att du inte behöver duplicera alla andra direktiv i filen på varje katalognivå.

URL-omdirigeringar och omskrivning av URL

En av de vanligaste användningarna av .htaccess-filer är URL-omdirigeringar.

URL-omdirigeringar ska användas när webbadressen för ett dokument eller resurs har ändrats. Detta är särskilt användbart om du har omorganiserat din webbplats eller ändrat domännamn.

301 mot 302 omdirigeringar

Ur webbläsarsynpunkt finns det två typer av omdirigeringar, 301 och 302. (Dessa nummer hänvisar till felkoden som genereras av webbservern.)

301 betyder “permanent flyttad”, medan 302 betyder “flyttas tillfälligt.” I de flesta fall vill du använda 301. Detta bevarar alla SEO-kapital som den ursprungliga URL: en hade, och vidarebefordrar den till den nya sidan.

Det kommer också att göra att de flesta webbläsare uppdaterar sina bokmärken. De flesta webbläsare cachar också den gamla till nya kartläggningen, så de kommer helt enkelt att begära den nya URL: en när en länk eller användare försöker komma åt originalet. Om URL: n har ändrats permanent är det alla önskvärda resultat.

Det finns väldigt liten anledning att använda 302 omdirigeringar, eftersom det vanligtvis är mycket liten anledning att tillfälligt ändra en URL. Att ändra en URL någonsin är oönskat, men är ibland nödvändigt. Att ändra det tillfälligt med planen att ändra det senare är en dålig idé och kan nästan alltid undvikas.

Alla exempel i det här avsnittet använder 301-omdirigering.

Omdirigera kontra Omskriva

Det finns två olika sätt att “ändra” en URL med .htaccess-direktiv – Redirect-kommandot och mod_rewrite-motorn.

Redirect-kommandot skickar faktiskt ett omdirigeringsmeddelande till webbläsaren och berättar vilken annan URL du ska leta efter.

Vanligtvis “översätter” mod_rewrite-verktyget en URL (den som tillhandahålls i en begäran) till något som filsystemet eller CMS kommer att förstå, och hanterar sedan begäran som om den översatta webbadressen var den begärda URL: en.

När den används på detta sätt märker webbläsaren inte att någonting har hänt – den får bara innehållet den bad om.

Verktyget mod_rewrite kan också användas för att producera 301 omdirigeringar som fungerar på samma sätt som kommandot Redirect, men med fler alternativ för regler – mod_rewrite kan ha komplexa anpassnings- och omskrivningsinstruktioner för mönster, som Redirect inte kan dra nytta av.

Grundläggande sidomdirigering

För att omdirigera en sida till en annan URL är koden:

Omdirigera 301 /relative-url.html http://example.com/full-url.html

Detta enradiga kommando har fyra delar, vardera separerade med ett enda utrymme:

  • Kommandot Omdirigera
  • Typ av omdirigering (301 – flyttas permanent)
  • Den ursprungliga sidans relativa URL
  • Den nya och fullständiga webbadressen på den nya sidan.

Den relativa URL: en är relativt till katalogen som innehåller .htaccess-filen, som vanligtvis är webbroten eller domänens rot..

Så om http://example.com/blog.php hade flyttats till http://blog.example.com, skulle koden vara:

Omdirigera 301 /blog.php http://blog.example.com

Omdirigera en stor del av din webbplats

Om du har flyttat din katalogstruktur men hållit dina sidnamn på samma sätt, kanske du vill omdirigera alla förfrågningar för en viss katalog till den nya.

Omdirigera 301 / old-directory http://example.com/new-directory

Omdirigera en hel webbplats

Vad händer om hela webbplatsen har flyttat till en ny URL? Lätt.

Omdirigera 301 / http://newurl.com

Omdirigera www till icke-www

I allt större utsträckning flyttar webbplatser bort från underdomänet www.

Det har egentligen aldrig varit nödvändigt, men det var ett utbyte från de dagar då de flesta som driver en webbplats använde en server för att lagra massor av sina egna dokument, och katalogen www eller ”world wide web” användes för innehåll de ville dela med andra.

Idag använder vissa människor det och andra inte. Tyvärr skriver vissa användare fortfarande automatiskt www. framför varje URL av vana. Om du inte använder www, vill du se till att dessa förfrågningar landar på rätt plats.

För att göra detta måste du använda mod_rewrite-modulen, som antagligen redan är installerad på din webbhotell.

Alternativ + FollowSymlinks
RewriteEngine on
RewriteCond% ^ www.example.com [NC]
RewriteRule ^ (. *) $ Http://example.org/$1 [R = 301, NC]

Var försiktig!

Många andra .htaccess- och mod_rewrite-guider erbjuder en viss variation av följande kod för att uppnå detta:

Alternativ + FollowSymlinks
RewriteEngine on
RewriteCond%! ^ Example.com [NC]
RewriteRule ^ (. *) $ Http://example.org/$1 [R = 301, NC]

Ser du problemet med det?

Den omdirigerar alla underdomäner till den primära domänen. Så inte bara www.example.com, utan också blog.example.com och admin.example.com och allt annat. Detta är förmodligen inte det beteende du vill ha.

Omdirigerar till www

Men vad händer om du använder www-underdomänet?

Du bör antagligen skapa en omdirigering för att se till att folk kommer dit de försöker gå. Speciellt nu när färre människor troligen automatiskt lägger till www till början av webbadresser.

Du vänder bara ovanstående kod.

RewriteEngine On
RewriteCond% ^ example.com [NC]
RewriteRule ^ (. *) Http://www.website.com/$1 [R = 301, NC]

Ska jag omdirigera 404-fel till hemsidan?

Flera guider för .htaccess-omdirigeringar innehåller instruktioner om hur man gör 404-fel omdirigering till hemsidan.

Detta är ett bra exempel på hur bara för att du kan göra något, betyder det inte att du ska göra något.

Att omdirigera 404-fel till webbplatsens hemsida är en fruktansvärd idé. Det förvirrar besökare som inte kan förstå varför de ser framsidan på en webbplats istället för en korrekt 404-felsida.

Alla webbplatser bör ha en anpassad 404-sida som tydligt förklarar för användaren att innehållet inte kunde hittas och idealiskt erbjuder vissa sökfunktioner för att hjälpa användaren att hitta det de letade efter.

Varför använda .htaccess istället för alternativ?

Du kan ställa in omdirigering i PHP-filer eller med någon annan typ av skript på serversidan. Du kan också ställa in dem i ditt innehållshanteringssystem (som i princip är samma sak).

Men att använda .htaccess är vanligtvis den snabbaste omdirigeringen. Med PHP-baserade omdirigeringar eller andra skriptspråk på serversidan måste hela begäran vara klar och skriptet tolkas faktiskt innan ett omdirigeringsmeddelande skickas till webbläsaren.

Med .htaccess-omdirigeringar svarar servern direkt på begäran med omdirigeringsmeddelandet. Detta är mycket snabbare.

Du bör dock notera – vissa innehållshanteringssystem hanterar faktiskt omdirigeringar genom att uppdatera .htaccess programmatiskt. WordPress har till exempel omdirigering av plugins som fungerar på detta sätt. (Och WP: s vackra URL-system gör det också.)

Detta ger dig prestanda att använda .htaccess direkt, samtidigt som du ger dig bekvämligheten med hantering från din applikation.

Dölja din .htaccess-fil: Säkerhetshänsyn

Det finns ingen anledning till att någon ska kunna se din .htaccess-fil från webben.

Dessutom finns det några stora anledningar till att du definitivt inte vill att folk ska se din .htaccess-fil.

Det största problemet är att om du använder en .htpasswd-fil stavas dess plats i .htaccess-filen. Att veta var man hittar det gör det lättare att hitta.

Dessutom vill du som regel inte ge allmänheten information om din implementering.

Omskriva regler, kataloginställningar, säkerhet – allt du använder .htaccess för – det är en bra säkerhetspraxis att dölja allt detta bakom kulisserna på din webbserver. Ju mer en hacker kan lära sig om ditt system, desto lättare är det att kompromissa med det.

Det är mycket enkelt att dölja din .htaccess-fil från allmän syn. Lägg bara till följande kod:

beställ tillåta, förneka
förneka från alla

Aktivera MIME-typer

MIME-typer är filtyper. De kallas MIME-typer på grund av deras ursprungliga koppling till e-post (MIME står för ”Multipurpose Internet Mail Extensions”). De kallas inte bara ”filtyper” eftersom MIME innebär ett specifikt format för att ange filtypen.

Om du någonsin har skrivit ett HTML-dokument har du troligtvis angett en MIME-typ, även om du inte visste det:

Typattributet avser en specifik MIME-typ.

MIME-typer på din server

Ibland hittar du att din webbserver inte är konfigurerad för att leverera en viss filtyp. Det fungerar bara inte – förfrågningar om filen misslyckas helt enkelt.

I de flesta fall kan du åtgärda problemet genom att lägga till MIME-typen i din .htaccess-fil.

AddType text / richtext rtx

Detta direktiv har tre delar, vardera separerade med ett utrymme:

  • AddType-komman
  • MIME-typen
  • Filförlängningen.

Om du vill koppla flera olika filändelser till samma MIME-typ kan du göra det på en enda rad.

AddType image / jpeg jpeg jpg jpe JPG

Tvinga nedladdning av MIME-typ

Om du vill att alla länkar till specifika filtyper ska startas som nedladdningar, istället för att öppnas i webbläsaren, gör du det med applikationen MIME-typ / oktettström, så här:

AddType-applikation / octet-stream pdf

Återigen kan du ange flera filändelser med en enda typ:

AddType-applikation / octet-stream pdf doc docx rtf

Lista över filändelser och MIME-typer

Här är en inte helt komplett lista över filformat och tillhörande MIME-typer.

Om du hanterar din egen webbplats och vet vilka filtyper du publicerar resurser på, behöver du inte klistra in hela listan i din .htaccess-fil.

Men om du driver en webbplats som många andra bidrar och publicerar innehåll till, kanske du helt enkelt vill tillåta ett stort antal filtyper på detta sätt för att se till att ingen har en dålig upplevelse.

Detta är särskilt fallet om du driver en webbplats där människor kanske specifikt delar många filer, till exempel en fildelningswebbplats, en projekthanteringsapplikation (där många filer ofta kommer att bifogas projektet) eller en webbapp som hanterar e-post.

AddType-applikation / macbinhex-40 hqx
AddType-applikation / netalive net
AddType-applikation / netalivelink nel
AddType-applikation / octet-stream bin exe
AddType-applikation / oda oda
AddType-applikation / pdf pdf
AddType-applikation / postscript ai eps ps
AddType-applikation / rtf rtf
AddType-applikation / x-bcpio bcpio
AddType-applikation / x-cpio cpio
AddType-applikation / x-csh csh
AddType-applikation / x-director dcr
AddType-applikation / x-director dir
AddType-applikation / x-director dxr
AddType-applikation / x-dvi dvi
AddType-applikation / x-gtar gtar
AddType-applikation / x-hdf hdf
AddType-applikation / x-httpd-cgi cgi
AddType-applikation / x-latex latex
AddType-applikation / x-mif mif
AddType-applikation / x-netcdf nc cdf
AddType-applikation / x-onlive sds
AddType-applikation / x-sh sh
AddType-applikation / x-shar shar
AddType-applikation / x-sv4cpio sv4cpio
AddType-applikation / x-sv4crc sv4crc
AddType-applikation / x-tar tar
AddType-applikation / x-tcl tcl
AddType-applikation / x-tex tex
AddType-applikation / x-texinfo texinfo texi
AddType-applikation / x-troff t tr roff
AddType-applikation / x-troff-man-man
AddType-applikation / x-troff-me me
AddType-applikation / x-troff-ms ms
AddType-applikation / x-ustar ustar
AddType-applikation / x-wais-source src
AddType-applikation / zip-zip
AddType audio / basic au snd
AddType audio / x-aiff aif aiff aifc
AddType audio / x-midi mid
AddType audio / x-pn-realaudio ram
AddType audio / x-wav wav
AddType image / gif gif GIF
AddType-bild / ief ief
AddType image / jpeg jpeg jpg jpe JPG
AddType image / tiff tiff tif
AddType image / x-cmu-raster ras
AddType image / x-portable-anymap pnm
AddType image / x-portable-bitmap pbm
AddType image / x-portable-graymap pgm
AddType image / x-portable-pixmap ppm
AddType image / x-rgb rgb
AddType image / x-xbitmap xbm
AddType image / x-xpixmap xpm
AddType image / x-xwindowdump xwd
AddType text / html html htm
AddType text / vanlig txt
AddType text / richtext rtx
AddType text / tab-separerade-värden tsv
AddType text / x-server-parsed-html shtml sht
AddType text / x-setext etx
AddType video / mpeg mpeg mpg mpe
AddType video / quicktime qt mov
AddType video / x-msvideo avi
AddType video / x-sgi-film
AddType x-world / x-vrml wrl

Blockera hotlinking

Hotlinking är praxis att länka till resurser från andra domäner istället för att ladda upp innehållet till din egen server och servera det själv.

Säg att du hittar en bild på en webbplats som du verkligen gillar och att du vill använda den på din webbplats. Att ignorera upphovsrättsfrågor för tillfället – du kan ladda ner bilden, ladda upp den till din webbplats och bädda in den på din sida som normalt.


Men om du var lat eller försökte spara bandbredd eller inte visste hur du laddar upp en fil kan du bara bädda in den direkt från originalfilen.

Det är hotlinking. Det händer också med CSS- och JS-filer, men bilder är de vanligaste.

Vissa webbplatser / värdar bryr sig inte alls om du gör det – du kan länka bilder från Wikipedia utan att någon blir upprörd. Och vissa webbplatser uppmuntrar det i en eller annan form.

Till exempel tillhandahåller JQuery sina JS-bibliotek via ett CDN (Content Delivery Network), så att du kan länkas direkt till det utan att behöva ladda upp det och servera det från din egen server.

Men många webbhotell anser att hotlinking är en form av bandbredd och stjäl av resurser.

För att vara säker, om du driver en relativt liten webbplats, har du inte råd att ha tusentals, eller tiotusentals, förfrågningar som görs varje dag för resurser som inte har något att göra med faktiska besökare på din webbplats.

Om du har problem med hotlinking kan du inaktivera det med några mod_rewrite-regler som har lagts till i din .htaccess-fil.

RewriteEngine on
OmskrivaCond%! ^ $
RewriteCond%! ^ Http: // (www.)? Example.com /.*$ [NC]
RewriteRule. (Gif | jpg | jpeg | png | js | css) $ – [F]

Se till att byta exempel.com i den tredje raden till ditt faktiska domännamn. Detta kommer att hämta eventuella förfrågningar som inte kommer från din domän och sedan kontrollera om den matchar en av de angivna filändelserna i den fjärde raden. Om det finns en matchning misslyckas begäran.

Om du vill lägga till andra filändelser kan du helt enkelt redigera den sista raden.

Visar upp alternativt innehåll

Om du vill låta världen veta varför deras hotlinking plötsligt har slutat fungera kan du byta ut hotlinkade bilder mot en speciell bild med ett meddelande som “Vi hatar hotlinking!” eller “Originalinnehåll tillgängligt på http://example.com”.

Istället för att misslyckas med begäran, omdirigerar du den till den “speciella” bilden:

RewriteEngine on
OmskrivaCond%! ^ $
RewriteCond%! ^ Http: // (www.)? Example.com /.*$ [NC]
RewriteRule. (Gif | jpg) $ http://www.example.com/no-hotlinking.jpg [R, L]

Om du verkligen vill röra med människor kan du omdirigera JavaScript- eller CSS-filer till specialalternativ som kan ha olyckliga effekter för hotlinkern. Detta rekommenderas dock inte.

RewriteEngine on
OmskrivaCond%! ^ $
RewriteCond%! ^ Http: // (www.)? Example.com /.*$ [NC]
RewriteRule. (Js) $ http://www.example.com/break-everything.js [R, L]

RewriteEngine on
OmskrivaCond%! ^ $
RewriteCond%! ^ Http: // (www.)? Example.com /.*$ [NC]
RewriteRule. (Css) $ http://www.example.com/super-ugly.css [R, L]

Inaktivera eller aktivera index

Vad händer om du har en katalog full av dokument eller andra resurser, ingen index.html-fil och ingen standardkatalogsida anges i .htaccess-filen?

I många fall blir resultatet en generisk kataloglista över alla filer i katalogen.

Det är rätt. Om du har en mapp i din värdkatalog märkt / bilder, och den har ingen index.html-sida, när någon navigerar till http://yousite.com/images, kommer de att kunna se en lista med alla bilder på din webbplats.

Detta är standardbeteendet för de flesta webbservrar, och det är vettigt utifrån den ursprungliga uppfattningen av en webbplats som helt enkelt en plats att hålla och dela dokument. Men detta är inte önskat beteende för de flesta webbplatser.

Inaktivera index

Många webbhotellkonton har inaktiverat detta redan som en del av deras globala konfiguration. Men inte alla gör det.

Om du behöver inaktivera automatiskt genererade kataloglistor är det enkelt:

Alternativ -Indexer

Aktivera index

Om din webbserver har inaktiverat index som en del av den globala konfigurationen, men du vill ha dem, kan du aktivera dem med motsatsen till kommandot ovan.

Alternativ + index

Gömmer några filer från indexet

Om du vill visa kataloglistor, men du vill dölja vissa filtyper från listan, kan du göra det också.

IndexIgnore * .gif * .jpg

* Är en wild-card chracter. Ovanstående direktiv döljer alla filer som har en .gif- eller .jpg-förlängning. Om du ville vara mer specifik kan du:

IndexIgnorera secret-image.jpg

Aktivera CGI överallt

CGI, eller Common Gateway Interface, är en server-sida metod för att inkludera icke-HTML-skript (som Perl eller SSI) på webbsidor.

Vanligtvis lagras CGI-skript i en mapp märkt / cgi-bin. Webbservern är konfigurerad för att behandla alla resurser i den katalogen som ett skript, snarare som en sida.

Problemet med det är tvåfaldigt: URL-adresser som refererar till CGI-resurser måste ha / cgi-bin / i dem, vilket placerar implementeringsdetaljer i din URL – ett antimönster som ska undvikas av ett antal skäl.

En komplex webbplats kan behöva en bättre organisationsstruktur än att bara ha massor av skript fastnat i en enda / cgi-bin-mapp.

Om du vill att din webbserver ska analysera CGI-skript oavsett var de finns i din katalogstruktur, lägg bara till följande i din .htaccess-fil:

AddHandler cgi-script .cgi
Alternativ + ExecCGI

Om du har andra filändelser som du vill bearbeta som CGI-skript kan du lägga till dem i den första raden.

Skript som källkod

För det mesta lägger du till skript i din webbkatalog eftersom du väl vill att de ska köras som skript.

Men ibland är det inte det du vill ha. Ibland vill du visa källkoden för offentliga besökare, istället för att köra skriptet.

Detta kan vara fallet om du driver en fildelningstjänst eller en kodförvaringswebbplats, och du vill att folk ska se källkoden och kunna ladda ner den, men skripten är faktiskt en del av din webbplats funktion.

Detta kan göras i din .htaccess-fil genom att ta bort skripthanteraren för vissa filtyper och ersätta den med en hanterare för text.

Ta bortHandler cgi-script .pl .cgi .php .py
AddType text / vanlig .pl .cgi .php .py

Alternativt, som tidigare nämnts, kan du tvinga filer med dessa extensinos att laddas ner automatiskt, snarare än att visas.

Ta bortHandler cgi-script .pl .cgi .php .py
AddType-applikation / octet-stream .pl .cgi .php .py

Var dock försiktig med något av dessa. Om du bara vill att vissa filer ska visas på detta sätt, men fortfarande använder dessa skript för resten av din webbplats, kommer det att ha en dålig tid om du lägger det direktivet till din webbrots .htaccess-fil.

En bättre praxis skulle vara att placera alla sådana “endast display” -skript i en enda katalog och sedan placera direktivet i en .htaccess-fil där i den mappen.

Konfigurera PHP-inställningar

Ibland måste du justera PHP: s inställningar. Det rätta sättet att göra detta är i en fil som heter php.ini.

Tyvärr tillåter inte alla webbhotellföretag sina kunder att redigera php.ini-filen. Detta gäller särskilt för delade värdleverantörer, där en enda installation av PHP kanske hundratals webbplatser.

Lyckligtvis finns det en lösning – du kan bädda in php.ini-regler i din .htaccess-fil.

Syntaxen ser ut som:

php_value [inställningsnamn] [värde]

Så, till exempel, om du behöver öka den maximala filuppladdningsstorleken (ett vanligt problem), är det lika enkelt som:

php_value upload_max_filesize 10M

Inte alla PHP-inställningar kan anges i .htaccess-filer. Till exempel kan du inte inaktivera_klassificeringar på detta sätt.

För en fullständig lista över alla inställningar för php.ini, se den officiella guide till php.ini-direktiv.

Hur du förhindrar åtkomst till din PHP inkluderar filer

Det finns flera sätt att förhindra obehörig åtkomst till din PHP innehåller filer.

Först kan du lägga in dem i en katalog och ställa in din .htaccess-fil så att den nekar all åtkomst till den katalogen (dvs. Neka från alla om du använder Apache HTTP-servern). Om någon försöker komma åt filen får de en HTTP 403 förbjuden svar.

Alternativt kan du lagra dessa filer utanför den katalog som dina webbplatsfiler serveras från. Det vill säga om din webbserver visar filer som finns i / Srv / home, du kan lägga dina inkludera filer under / Srv / home / includes. Detta gör filerna otillgängliga via URL: er, men du kan komma åt och använda dem på följande sätt: inkludera ‘PATH_TO_YOUR_FILE’

Slutligen kan du definiera en URL-konstant för de filer du vill ha tillgängliga:

definiera (‘WEBSITE_URL’, ‘http://example.com’);

Följ sedan följande kontroll för de filer som du inte vill ha åtkomst till:

if (! definierat (‘WEBSITE_URL’)) {
header ($ _ SERVER ["SERVER_PROTOCOL"] . "403 förbjuden");
utgång;
}

Hur man förhindrar åtkomst till dina PHP-ini-filer

Sättet att förhindra obehörig åtkomst till dina ini-filer är att redigera din .htaccess-fil för att neka åtkomst till ini-filerna (dvs. Neka från alla om du använder Apache).

Så här ställer du in din serverns tidszon

Du kan ställa in serverns tidszon genom att ange den i din .htaccess-fil. För att göra det måste du lägga till följande rad:

php_value date.timezone ‘Region / Zone’

Se till att ersätta region / zon med den tidszon du föredrar.

Spara din fil. Du kan testa dina ändringar genom att skapa en PHP-testfil som innehåller följande i samma katalog som .htaccess-filen:

<?php phpinfo (); ?>

Ladda filen i din webbläsare och sök efter direktivets namn – kolumnen Lokalt värde ska visa din nya tidszoninställning.

När du inte ska använda .htaccess

Att redigera din .htaccess-fil för första gången kan ge dig en plötslig känsla av enorm makt över din webbhotellmiljö. Du känner plötsligt som en sysadmin.

Tyvärr kan den här kraften gå till ditt huvud och du kan hitta dig själv med hjälp av .htaccess-filen på sätt som inte riktigt är bäst.

När du behöver göra något som verkar vara ett .hta-slags jobb, finns det i princip två situationer där du bör sätta det direktivet någon annanstans.

Längre uppströms

När det är möjligt är de typer av direktiv du kan placera i en .htaccess-fil bättre av att vara placerade i httpd.conf-filen, som är en konfigurationsinställningsfil för hela servern.

På liknande sätt tillhör PHP-inställningar mer korrekt i filen php.ini, och de flesta andra språk har liknande konfigurationsinställningsfiler.

Genom att placera direktiv längre uppströms i httpd.conf, php.ini eller annan språkspecifik konfigurationsfil kan dessa inställningar “bakas in” på webbserverns analysmotor. Med .htaccess måste direktiven kontrolleras och tolkas med varje enskild begäran.

Om du har en låg trafikwebbplats med bara en handfull .htaccess-direktiv är detta inte en stor sak. Men om du har mycket trafik och många direktiv kan prestandaförskjutningen verkligen lägga till.

Tyvärr tillåter många delade värdleverantörer inte kunder att få åtkomst till filerna httpd.conf eller php.ini, vilket tvingar användare att lita på den långsammare .htaccess-filen.

Detta ger en dubbel straff jämfört med anpassade VPS-konfigurationer eftersom delad hosting också generellt sett är lågdrivet. Detta är en av anledningarna till att en webbplats med respektabel trafik antagligen bör vara på en VPS-plan istället för delad värdplan.

Längre nedströms

Om du använder ett bra Content Management System (CMS) som WordPress eller Drupal, kan några av de saker du kan göra i en .htaccess-fil – till exempel omdirigera URL: er eller blockera IP-adresser – göras inifrån applikationen.

Ofta fungerar detta i samband med .htaccess-filen, med att programmet programmatisk lägger till direktiv.

När detta är tillgängligt är det vanligtvis bäst att utföra dessa uppgifter inifrån applikationen, snarare än att redigera .htaccess-filen själv. Det är mindre troligt att du introducerar buggar och inkompatibla direktiv om du använder ett väl testat, open source-plugin.

Felsökning

Det kan vara bra att skicka med din .htaccess-fil – men det kan också göra att din server tar tag i och börjar leverera 500 interna serverfelmeddelanden.

Här är några idéer som hjälper dig genom det.

Gör en sak åt gången

Detta borde självklart säga, men – tyvärr – det är en lektion som många av oss måste lära oss om och om igen.

Gör en sak. Testa det sedan. Gör sedan en annan sak. Testa det.

Om du gör flera saker på en gång, och då misslyckas något, vet du inte vilket direktiv som orsakar problemet.

Säkerhetskopiera din fil före varje åtgärd

Tillsammans med att bara göra en sak åt gången, bör du spara din fil mellan varje sak du försöker. Ditt sparade arkiv måste återställas. Det här är inte Microsoft Word där du bara kan ångra – du behöver en sparad kopia av din fil.

Du bör alltid ha den senaste fungerande versionen tillgänglig om du röra något. Alltid, alltid, har alltid förmågan att återställa till en fungerande version.

Detta är lättast om du någon form av källhanteringssystem som git. Du kan begå efter varje förändring och rulla tillbaka om du stöter på problem.

Kontrollera felloggarna

Om du stöter på ett problem och har svårt att ta reda på varför kan du kontrollera Apache-felloggarna. Dessa ger ofta värdefull information om vart man ska titta.

Använd utvecklarforum för att få hjälp

Utvecklarforum och Q&En webbplats som StackOverflow är ovärderliga verktyg för även de mest erfarna utvecklare och sysadmins. Och glöm inte Google. Ofta är skillnaden mellan en dålig webbmaster och stor att inte veta svaret, det är att veta var man hittar svaret.

Vanliga .htaccess-problem

Ibland skapade du en skrivfel. Ibland har du ett esoteriskt och förvirrande problem orsakat av ett sammanflöde av oförutsägbara faktorer.

De flesta problem, och de riktigt frustrerande, är de i mitten – de enkla, vardagliga problemen som är lätta att fixa om du bara visste om dem.

Här är några av dem.

Dåligt filnamn

Det finns bara ett sätt att stava .htaccess – det måste börja med punkten, och det måste vara med alla små bokstäver.

Det verkar dumt, men om din .htaccess-fil inte gör vad du förväntar dig, borde det vara det första du kontrollerar.

.htaccess Inaktiverat eller delvis inaktiverat

Vissa delade värdleverantörer inaktiverar .htaccess helt. Andra tillåter det, men begränsar vissa direktiv från att användas – de ignoreras bara om de ingår.

På samma sätt, även på VPS-planer eller dina egna dedikerade servrar, kan .htaccess vara inaktiverat.

Om du har tillgång till filen httpd.conf eller andra serverinställningar kan du kontrollera detta själv. Om du hittar direktivet AllowOverride None hittade du den skyldige. Byt ut det med AllowOverride All.

Om du inte har tillgång till din httpd.conf-fil (eftersom du till exempel använder delad hosting), kan du behöva kontakta ditt webbhotells tekniska support och se om de kan aktivera den åt dig eller erbjuda dig förslag på ow för att uppnå det du försöker göra på ett annat sätt.

Konflikt eller åsidosatta direktiv

Om du har flera kapslade kapslade är det möjligt för var och en att ha sin egen .htaccess-fil. Varje .htaccess-fil från roten, genom varje kapslad katalog, gäller – de läses i ordning, nedåt i katalogträdet.

Om du ställer in något i din rotkatalog, och sedan något i underkatalogen åsidosätter det, kommer direktivet i .htaccess-filen närmast den begärda filen att ha företräde.

Se även vårt mod-omskrivningsfuskblad!

.htaccess Vanliga frågor

  • Vad är .htaccess-fil i SEO?

    .Htaccess-filen kan användas för att utföra SEO-relaterade uppgifter som omdirigeringar. Omdirigeringar kan användas för att undvika 404-felmeddelanden och för att låta sökmotorns sökrobotar veta vilka sidor de ska indexera. Du kan också ställa in HTTP-rubriker för att förbättra sidhastigheten, vilket kan öka din sökmotors ranking.

    Dessutom kan du använda .htaccess för att anta en konsekvent slash-policy. Detta i kombination med www- och HTTPS-regler kan hjälpa dig att undvika duplikatinnehåll, vilket kan straffas av Google.

  • Hur skapar jag en .htaccess-fil i WordPress?

    För att skapa en .htaccess-fil i WordPress använder du den här koden:

    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /
    RewriteRule ^ index \ .php $ – [L]
    RewriteCond% {REQUEST_FILENAME}! -F
    RewriteCond% {REQUEST_FILENAME}! -D
    Omskriva regel. /index.php [L]

    # END WordPress

    Observera att när du installerar WordPress skapas .htaccess-filen automatiskt. En felaktig plugin kan dock förstöra en .htaccess-fil, vilket resulterar i ett behov av att skapa filen igen.

  • Varför kan jag inte se min .htaccess-fil?

    Om du inte kan se din .htaccess-fil beror den på att den inte finns eller den är dold. För att tvinga din FTP-klient att visa dessa filer måste du ändra dina klientinställningar (dvs. i FileZilla, gå till server > Tvinga fram dolda filer). Om du har gjort den här ändringen och du fortfarande inte ser .htaccess måste du skapa den igen.

  • Hur många .htaccess-filer ska jag ha?

    De flesta webbplatser behöver inte mer än en .htaccess-fil. Det beror på att .htaccess-filerna gör att du kan göra serverkonfigurationsändringar per katalogbasis. Men när värd för flera webbplatser eller komplexa applikationer kan vissa webbansvariga använda mer än en fil per webbplats för att utföra avancerade funktioner.

  • Var är .htaccess i cPanel?

    Logga in på ditt cPanel-konto för att se .htaccess-filen. Gå sedan till filer > Filhanterare. När du blir ombedd att välja katalog, välj Web Root och se till att Visa gömda filer är kontrollerad. Du borde nu kunna se din .htaccess-fil i cPanel.

  • Vad används av .htaccess-filen i CodeIgniter?

    .Htaccess-filen kan användas tillsammans med CodeIgniter för att skapa sökmotorvänliga webbadresser. Som standard innehåller CodeIgniter URL: er index.php-filen. Genom att använda .htaccess kan du radera standardindex.php-filen så att den inte visas i alla applikationens webbadresser.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map