Share
.htaccess-filer brukes til å konfigurere Apache, samt en rekke andre webservere. Til tross for .htaccess filtype-utvidelse, de er bare tekstfiler som kan redigeres ved hjelp av hvilken som helst tekstredigerer. I denne artikkelen vurderer vi hva de er, og hvordan du kan bruke dem i prosjektene dine.
Vær oppmerksom på at .htaccess-filer ikke fungerer på Windows-baserte systemer, selv om de kan redigeres og lastes opp til en kompatibel webserver, og på Linux-baserte systemer er de gjemt som standard.
For å kunne jobbe med htaccess-filer lokalt, for å se hvordan de fungerer og generelt leker med dem, kan vi bruke XAMPP (eller MAMP) på Mac - en pakke som installerer og konfigurerer Apache, PHP og MySQL. For å redigere disse .htaccess-filene på Mac, bør vi bruke et tekstredigeringsprogram som tillater åpning av skjulte filer, for eksempel TextWrangler.
En .htaccess-fil følger samme format som Apaches hovedkonfigurasjonsfil: httpd.conf. Mange av innstillingene som kan konfigureres ved hjelp av hovedkonfigurasjonsfilen, kan også konfigureres med dem, og omvendt.
En innstilling som er konfigurert i en .htaccess-fil, vil tilsidesette den samme innstillingen i hovedkonfigurasjonsfilen for katalogen som inneholder filen, samt alle dens underkataloger.
De kalles noen ganger som dynamiske konfigurasjonsfiler fordi de leses av serveren på hver forespørsel til katalogen de er inneholdt i. Dette betyr at eventuelle endringer i en .htaccess-fil vil tre i kraft umiddelbart uten å kreve en omstart av serveren, i motsetning til endringer som er gjort i den globale konfigurasjonsfilen. Det betyr også at du betaler en liten ytelse hit for å bruke dem, men de kan være nyttige når du ikke har tilgang til serverens hovedkonfigurasjonsfil.
Så nå vet vi alle hva .htaccess-filer er, hvordan de redigeres og jobbet med, og noen av deres fordeler og ulemper, la oss se på hvordan de kan brukes og noen av de kule tingene de kan gjøre.
En populær bruk av .htaccess-filer er å utføre omadresser eller omskrive nettadresser. Dette kan hjelpe til med SEO etter en endring av domenenavn, eller omstrukturering av filstruktur, eller kan gjøre lang ugyldig nettadresse mer vennlig og minneverdig..
En omadressering kan være så enkelt som følgende:
Omdirigere 301 ^ gamle \ .html $ http: //localhost/new.html
Dette setter HTTP-statuskoden til 301 (flyttes permanent) og omdirigerer alle forespørsler til old.html gjennomsiktig til new.html. Vi bruker et vanlig uttrykk for å matche nettadressen for å omdirigere, noe som gir oss en fin grad av kontroll for å sikre at bare den riktige nettadressen er tilpasset omdirigering, men legger til kompleksitet i konfigurasjonen og administrasjonen av den. Den fullstendige nettadressen til ressursen som viderekobles til, kreves.
En omskrivningsregel kan være så enkelt som dette:
RewriteEngine på RewriteRule ^ old \ .html $ new.html
I dette eksemplet gir vi bare en enkel fil omdirigering fra en fil til en annen, som også vil bli utført transparent uten å endre det som vises i adressefeltet. Det første direktivet, Skriv om på nytt, bare sikrer at omskrivningsmotoren er aktivert.
For å oppdatere det som vises i adressefeltet til den besøkende nettleseren, kan vi bruke R flagg på slutten av RewriteRule f.eks.
RewriteRule ^ old \ .html $ http: //hostname/new.html [r = 301]
De r flagg fører til ekstern omdirigering, og derfor er hele URL-adressen (et eksempel-URL her) til den nye siden gitt. Vi kan også angi statuskoden når du bruker flagget. Dette får adresselinjen til å bli oppdatert i den besøkende nettleseren.
En av de mulige bruksområder for URL-omskrivning jeg ga i begynnelsen av denne delen, var å lage ugyldige nettadresser (som inneholder spørringsstrengsdata) vennligere for besøkende og søkemotorer. La oss se dette i gang nå:
RewriteRule ^ produkter / ([^ /] +) / ([^ /] +) / ([^ /] +) product.php? Cat = $ 1 & brand = $ 2 & prod = $ 3
Denne regelen tillater besøkende å bruke en nettadresse som produkter / turntables / teknikk / sl1210, og har det forvandlet til product.php? cat = turntables &$ 1, $ 2 og $ 3 henholdsvis. De [^ /]+ tegnklasse innenfor parentes betyr at alle tegn er unntatt en forward-slash 1 eller flere ganger.
I praksis kan URL-omskrivning være (og vanligvis er) mye mer komplekst og oppnå langt større ting enn dette. URL-omskrivning er bedre forklart ved hjelp av hele opplæringen, så vi vil ikke se nærmere på dem her.
Det er bare ikke kult å vise standard 404-siden lenger. Mange nettsteder benytter seg av en fil som ikke fant feil for å injisere litt humor inn på nettstedet deres, men i det minste forventer folk at 404-siden på et nettsted for minst samsvarer med stilen og temaet på en hvilken som helst annen side av nettstedet.
Svært nært relatert til URL-omskrivning, som viser en tilpasset feilside i stedet for standard 404-siden, er enkel med en .htaccess-fil:
ErrorDocument 404 "/404.html"
Det er alt vi trenger; Når en 404-feil oppstår, vises den angitte siden. Vi kan konfigurere sider som skal vises for mange andre serverfeil også.
Ved hjelp av .htaccess-filer kan vi aktivere passordbeskyttelse av enhver fil eller katalog, til alle brukere, eller basert på ting som domene eller IP-adresse. Dette er jo en av deres kjernevirkninger. For å hindre tilgang til en hel katalog, kan vi enkelt opprette en ny .htaccess-fil, som inneholder følgende kode:
AuthName "Brukernavn og passord kreves" AuthUserFile /path/to/.htpasswd Krev gyldig bruker AuthType Basic
Denne filen skal da lagres i katalogen vi ønsker å beskytte. De AuthName Direktivet angir meldingen som skal vises i dialogboksen brukernavn / passord, AuthUserFile bør være banen til .htpasswd-filen. De Krev Direktivet angir at kun autentiserte brukere får tilgang til den beskyttede filen mens AuthType er satt til grunn~~POS=TRUNC.
For å beskytte en bestemt fil kan vi pakke inn koden ovenfor i en
AuthName "Brukernavn og passord kreves" AuthUserFile /path/to/.htpasswd Krev gyldig bruker AuthType Basic
Vi krever også en .htpasswd-fil for disse typene autentisering, som inneholder en kolon-separert liste over brukernavn og kryptert passord som kreves for å få tilgang til beskyttede ressursene. Denne filen skal lagres i en katalog som ikke er tilgjengelig for Internett. Det finnes en rekke tjenester som kan brukes til å generere disse filene automatisk, da passordet skal lagres i kryptert form.
En annen bruk av .htaccess-filer er å raskt og enkelt blokkere alle forespørsler fra en IP-adresse eller brukeragent. For å blokkere en bestemt IP-adresse, legg ganske enkelt til følgende direktiver til .htaccess-filen din:
rekkefølge tillat, nekte å nekte fra 192.168.0.1 tillate fra alle
De rekkefølge Direktiv forteller Apache i hvilken rekkefølge å vurdere tillatelse / nekte direktiver. I dette tilfellet, tillate blir evaluert først da benekte. De tillat fra alle Direktivet vurderes først (selv om det vises etter benekte direktivet) og alle IP-adresser er tillatt, så hvis klientens IP samsvarer med den som er spesifisert i benekte Direktivet er tilgang forbudt. Dette lar alle med unntak av spesifisert IP. Merk at vi også kan nekte tilgang til hele IP-blokkene ved å levere en kortere IP, f.eks. 192.168.
For å nekte forespørsler basert på brukeragent, kan vi gjøre dette:
RewriteCond% HTTP_USER_AGENT ^ OrangeSpider RewriteRule ^ (. *) $ Http: //% REMOTE_ADDR / $ [r = 301, l]
I dette eksemplet kan enhver klient med en HTTP_USER_AGENT streng starter med OrangeSpider (en dårlig bot) blir omdirigert tilbake til adressen den stammer fra. Det vanlige uttrykket samsvarer med et enkelt tegn (.) null eller flere ganger (*) og omdirigerer til % REMOTE_ADDR miljøvariabel. De l flagget vi brukte her instruerer Apache å behandle denne kampen som den siste regelen, så det vil ikke behandle noen andre før du skriver omskrivningen.
Ved siden av å kontrollere hvordan serveren reagerer på bestemte forespørsler, kan vi også gjøre ting til den besøkende nettleser, for eksempel å tvinge IE til å gjengi sider ved hjelp av en bestemt renderingsmotor. For eksempel kan vi bruke mod_headers modul, hvis den er til stede, for å stille inn X-UA-Compatible Overskrift:
Header sett X-UA-kompatibel "IE = Edge"
Hvis du legger til denne linjen i en .htaccess-fil, vil den instruere IE å bruke den høyeste gjengivelsesmodusen som er tilgjengelig. Som demonstrert av HTML5 Boilerplate, kan vi også unngå å sette inn denne overskriften på filer som ikke krever det ved å bruke en
Header unset X-UA-kompatibel
Caching er enkelt å sette opp og kan gjøre at nettstedet ditt lastes raskere.
Caching er enkelt å sette opp og kan gjøre at nettstedet ditt lastes raskere. Sa Nuff! Ved å sette en langt fremtid utløper dato på elementer av nettsteder som ikke endres veldig ofte, kan vi forhindre at nettleseren fra å be om uendrede ressurser på hver forespørsel.
Hvis du kjører nettstedet ditt via Google PageSpeed eller Yahoo's YSlow, og du får meldingen om å sette langt fremtidige utløpsoverskrifter, så løser du det:
ExpiresActive on ExpiresActive på ExpiresByType image / gif "tilgang pluss 1 måned" ExpiresByType image / png "tilgang pluss 1 måned" ExpiresByType image / jpg "tilgang pluss 1 måned" ExpiresByType image / jpeg "tilgang pluss 1 måned" ExpiresByType video / ogg "tilgang pluss 1 måned "ExpiresByType audio / ogg" tilgang pluss 1 måned "ExpiresByType video / mp4" tilgang pluss 1 måned "ExpiresByType video / webm" tilgang pluss 1 måned "
Du kan legge til annerledes ExpiresByType direktiver for innhold som er oppført i ytelsesverktøyet du bruker, eller noe annet du vil kontrollere caching på. Det første direktivet, ExpiresActive on, bare sikrer at genereringen av Expires-overskrifter er slått på. Disse direktivene er avhengig av Apache som har mod_expires modul lastet.
En annen advarsel vi kan få i en ytelseskontroll refererer til å aktivere komprimering, og dette er også noe vi kan fikse rett og slett ved å oppdatere vår .htaccess-fil:
FilterDeclare COMPRESS FilterProvider COMPRESS DEFLATE resp = Innholdstype $ tekst / html FilterProvider COMPRESS DEFLATE resp = Innholdstype $ text / css FilterProvider COMPRESS DEFLATE resp = Innholdstype $ tekst / javascript FilterChain COMPRESS FilterProtocol COMPRESS DEFLATE change = ja; byteranges = nei
Denne kompresjonsplanen fungerer på nyere versjoner av Apache (2.1+) ved hjelp av mod_filter modul. Den bruker deflate komprimeringsalgoritme for å komprimere innhold basert på dens responsinnholdstype, i dette tilfellet spesifiserer vi text / html, text / css og text / javascript (som sannsynligvis vil være typer filene flagget i PageSpeed / Yslow uansett).
I eksempelet ovenfor begynner vi ved å deklarere filteret vi ønsker å bruke, i dette tilfellet KOMPRIMERE, bruker FilterDeclare direktiv. Vi lister deretter innholdstypene vi ønsker å bruke dette filteret. De FilterChain Direktivet instruerer da serveren å bygge en filterkjede basert på FilterProvider direktiver vi har oppført. De FilterProtocol Direktivet gir oss mulighet til å angi alternativer som brukes på filterkjeden når den kjøres, alternativene vi trenger å bruke er endring = yes (innholdet kan endres av filteret (i dette tilfellet komprimert)) og byteranges = ingen (filteret må kun brukes for å fullføre filer).
På eldre versjoner av Apache, mod_deflate Modulen brukes til å konfigurere DEFLATE komprimering. Vi har mindre kontroll over hvordan innholdet blir filtrert i dette tilfellet, men direktiverne er enklere:
SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE tekst / html tekst / css text / javascript
I dette tilfellet har vi bare satt komprimeringsalgoritmen ved hjelp av SetOutputFilter direktivet, og angi deretter innholdstypene vi ønsker å komprimere ved hjelp av AddOutputFilterByType direktiv.
Vanligvis vil webserveren bruke en av disse modulene avhengig av hvilken versjon av Apache som er i bruk. Vanligvis vil du vite dette på forhånd, men hvis du lager en generell .htaccess-fil som du kan bruke på en rekke nettsteder, eller som du kanskje deler med andre mennesker, og derfor ikke vet hvilke moduler som kan brukes, Du kan ønske å bruke begge de ovennevnte blokkene med kode innpakket i
Vi så på noen av de vanligste bruksområder for .htaccess-filer, og gjennomgikk hvordan vi kan oppnå bestemte oppgaver som, som byggherrer / web-leverandører, er av spesiell interesse for oss. Som det er tilfelle med noen introduksjonsveiledning av denne art, presenteres emnene vi har dekket som introduksjoner til et bestemt emne. Det er mange andre alternativer og konfigurasjoner enn vi har vært i stand til å se på, så jeg vil sterkt anbefale videre lesing om ethvert emne som er av spesiell interesse.
Accentsconagua