Share
De .htaccess-configuratiebestanden van Apache hebben talloze ontwikkelaars verbijsterd. Deze tutorial is bedoeld om deze verwarring te doorbreken door te focussen op voorbeelden en grondige beschrijvingen. Een van de voordelen van het leren .htaccess-configuratie is automatisch gzippen van uw inhoud, het aanbieden van vriendelijkere URL's, het voorkomen van hotlinking, het verbeteren van caching en meer.
Dit artikel leert je over het handmatig configureren van je .htaccess-bestanden, maar als je een eenvoudige, snelle oplossing wilt, probeer dan .htaccess Builder van Envato Market te downloaden. Hiermee kunt u snel en moeiteloos een htaccess-bestand leveren zonder dat u zich iets hoeft te herinneren over de Apache-servertaal die is gebruikt om het htaccess-bestand samen te stellen!
.htaccess Builder op Envato Market Ik heb een aantal .htaccess-artikelen online gelezen. Ik zal het schaamteloos toegeven
Ik ben niet verder gekomen dan de voorpagina van Google-resultaten. Ik was geschokt toen
Ik las de artikelen en ontdekte dat geen van hen verklaarde wat Apache eigenlijk was
aan het doen. Ze waren slechts een verzameling populaire of nuttige trucs of
fragmenten van herbruikbare code. Dat is allemaal goed en wel, maar de klassieker
argument is:
"Geef een man een vis en hij eet een dag. Leer een man om te vissen en hij
zal een leven lang eten. "
- Confucius
In dit artikel ga ik proberen om u niet alleen voorbeelden van nuttig te laten zien
.htaccess-richtlijnen, maar leg uit wat er precies is
aan de hand. Op deze manier zult u de kernprincipes begrijpen en kunt u de
voorbeelden of maak nieuwe opdrachten voor uw eigen gebruik op welke creatieve of nuttige manier dan ook
je kunt verzinnen.
Mijn focus ligt op Apache 2, maar veel hiervan zal van toepassing zijn
naar Apache 1.3 en ik zal proberen om eventuele verschillen aan te duiden die ik ken.
Eindelijk, deze tutorial zal het meest logisch zijn als je het op volgorde leest.
Ik probeer mijn voorbeelden samen te binden en van hen af te bouwen, in zo een
manier waarop u ze zelf kunt proberen en kunt volgen.
Om Apache te citeren:
.htaccess-bestanden (of "gedistribueerde configuratiebestanden") bieden een manier om te maken
configuratiewijzigingen per map. Een bestand met een of meer
configuratierichtlijnen, wordt in een bepaalde documentdirectory geplaatst en de
richtlijnen zijn van toepassing op die map en alle submappen daarvan.
"Richtlijnen" is de terminologie die Apache gebruikt voor de opdrachten in Apache's
configuratiebestanden. Het zijn meestal relatief korte opdrachten, meestal
sleutelwaardeparen, die het gedrag van Apache wijzigen. Een .htaccess-bestand maakt het mogelijk
ontwikkelaars om een aantal van deze richtlijnen uit te voeren zonder toegang te vereisen
Apache's kernserverconfiguratiebestand, vaak httpd.conf genoemd. Dit bestand,
httpd.conf wordt meestal het "global configuration file" genoemd en ik zal dat doen
verwijs ernaar met die naam of het korte bestandsnaamequivalent.
Deze functie is ideaal voor veel hostingbedrijven die een shared hosting inzetten
milieu. Het hostingbedrijf staat zijn klanten geen toegang toe tot de
globaal configuratiebestand, dat uiteindelijk van invloed is op alle klanten die worden gehost
die server. In plaats daarvan geven zij elk van hun klanten toegang door .htaccess in te schakelen
de kracht om hun eigen Apache-richtlijnen in hun eigen te specificeren en uit te voeren
mappen en submappen. Natuurlijk is het ook nuttig voor de single
ontwikkelaar, zoals je zult zien.
Het is de moeite waard te vermelden dat alles wat kan worden gedaan met een .htaccess-bestand kan
worden gedaan in het bestand httpd.conf. Echter, NIET alles wat er in gedaan kan worden
httpd.conf kan worden gedaan in een .htaccess-bestand. In feite .htaccess-bestanden moeten zijn
ingeschakeld in het httpd.conf-bestand om überhaupt te kunnen worden uitgevoerd. Eenmaal ingeschakeld,
hun macht kan worden beperkt tot bepaalde 'contexten', zodat ze kunnen worden toegestaan
om sommige instellingen te overschrijven, maar niet voor andere. Dit geeft de systeembeheerders
meer controle over waar ze andere ontwikkelaars mee weg laten komen in hun
.htaccess-bestanden.
.htaccess-bestanden zijn normaal gesproken standaard ingeschakeld. Dit wordt feitelijk gecontroleerd
door de AllowOverride-richtlijn in het httpd.conf-bestand. Deze richtlijn
kan alleen in een
u. Het typische httpd.conf-bestand definieert een DocumentRoot en de meerderheid
van het bestand bevat richtlijnen in een
met die map. Dit omvat de AllowOverride-richtlijn.
De standaardwaarde is eigenlijk "Alle" en dus .htaccess-bestanden worden ingeschakeld door
standaard. Een alternatieve waarde zou "Geen" zijn, wat zou betekenen dat ze dat wel zijn
volledig uitgeschakeld. Er zijn talloze andere waarden die de configuratie van alleen beperken
bepaalde contexten. Sommige zijn:
Ik zal enkele voorbeelden laten zien, zonder hun overeenkomstige
Hier is een voorbeeld dat volledige .htaccess-overschrijving mogelijk maakt:
# Toestaan dat .htaccess-bestanden hun volledige kracht toestaan AllowOverride All
En hier is een voorbeeld dat een meer fijnmazige aanpak vereist en alleen toestaat
het overschrijven van de autorisatie- en indexcontexten maar verder niets:
# Alleen .htaccess-bestanden toestaan om autorisatie en indexen op te heffen AllowOverride AuthConfig-indexen
De eerste regel in beide voorbeelden zijn Apache-opmerkingen. Reacties beginnen
met het symbool "#". Dit is gebruikelijk in veel configuratiebestanden en scripting
talen. Ik heb genoeg reacties in mijn voorbeelden om te helpen verklaren wat dingen doen.
Ze zijn echter niet verplicht, en het is eigenlijk gewoon persoonlijke voorkeur voor hoeveel jij
wil reageren. Opmerkingen zijn niet vereist.
De tweede regel is de AllowOverride-richtlijn zelf. Dit is de gebruikelijke syntaxis van een
Apache-richtlijn. Eerst is er de Richtlijn naam "AllowOverride" gevolgd door een spatie
gescheiden lijst met waarden. Hoewel deze syntaxis nogal los lijkt; wees altijd voorzichtig.
Soms resulteert zelfs een enkele fout in uw bestand httpd.conf of .htaccess in een
tijdelijke meltdown van de server, en gebruikers zullen 500 zien - Internal Server Error-pagina's.
Alleen al om die reden is het een goede gewoonte om altijd een back-up te maken van je httpd.conf en .htaccess-bestanden voordat je een wijziging of toevoeging aanbrengt. Op deze manier, als er iets misgaat met een wijziging, dan heb je
Niets om je zorgen over te maken, omdat je terug kunt keren naar je vorige werkende versie. ik zal
moedig u ook aan om telkens kleine wijzigingen aan te brengen en te controleren of de wijzigingen werken
incrementen in plaats van een aantal wijzigingen tegelijk door te voeren. Op deze manier, als je het doet
een fout, het zal veel gemakkelijker zijn om te achterhalen wat er mogelijk de oorzaak van is geweest.
Als u ooit verward bent over de syntaxis van een richtlijn, ga dan onmiddellijk naar
Apache-richtlijn en bekijk de "syntaxis" die ze in de tabel hebben vermeld
voor elke afzonderlijke richtlijn. Ik zal mijn best doen om het hier uit te leggen
(Ik probeer les te geven) maar mijn uitleg kan nooit zo goed zijn als de
formele technische documentatie zelf. Wees nooit bang voor de documentatie, dat is het wel
uw meest betrouwbare en betrouwbare referentie. Ik zal proberen dingen interessanter te maken
hier (woohoo!), maar uiteindelijk zet ik gewoon een andere draai in die documenten.
Het is heel goed mogelijk, in feite is het zeer waarschijnlijk dat uw hostingbedrijf dat niet doet
geeft u toegang tot het bestand httpd.conf. Dus hoe weet je of .htaccess-ondersteuning is ingeschakeld
of niet? Maak je geen zorgen, .htaccess is een veel voorkomende en nuttige functie die de meeste bedrijven zullen hebben
hebben ingeschakeld of zullen inschakelen als u het beleefd vraagt.
Het beste ding om te doen zou zijn om gewoon contact op te nemen met uw hostingbedrijf. Als het niet expliciet is
overal in uw hostingplan vermeld, maak vervolgens een e-mail met hun ondersteuning. Dit komt relatief veel voor
vraag, zodat ze waarschijnlijk al een antwoord voor u klaar hebben staan. Ze zullen waarschijnlijk bereid zijn
om de dienst in te schakelen of op zijn minst een reden te geven waarom ze het niet toestaan.
In elk geval kun je het altijd proberen en kijken of een eenvoudig .htaccess-bestand werkt!
Inbegrepen in de voorbeelddownload van deze tutorial zijn twee manieren waarop u kunt controleren of .htaccess
ondersteuning is ingeschakeld. De twee mappen zijn "is_htaccess_enabled" en "is_htaccess_enabled_2".
Geef ze een kans, ik zal uitleggen wat iedereen hier doet.
Deze testcase is heel eenvoudig. Het gebruikt een richtlijn om Apache er uit te laten zien
eerst voor de "indexgood.html "bestand voor" index.html. "Als ondersteuning voor .htaccess is
ingeschakeld, wanneer u uw browser naar de map verwijst, laadt Apache het .htaccess-bestand en weet dat
het zou de "index" moeten weergevengood.html "pagina met een groen bericht met de tekst Gefeliciteerd!
Als ondersteuning voor .htaccess niet is ingeschakeld, negeert Apache standaard de .htaccess
bestand en zoek onmiddellijk naar een index.html-bestand.
# Deze richtlijn zorgt ervoor dat Apache eerst # ziet voor "index_good.html" voordat zoekt naar "index.html" DirectoryIndex index_good.html index.html
De DirectoryIndex-instructie neemt een door spaties gescheiden lijst van mogelijke bestandsnamen.
Wanneer Apache een URL van een directory wordt gegeven en niet een directe pagina (bijvoorbeeld
http://www.example.com en niet http://www.example.com/index.html) Apache zal dit gebruiken
lijst met bestanden om te zoeken naar de juiste pagina om te laden. Apache gaat op zoek naar de bestanden
de waarden in de lijst van links naar rechts gebruiken. Het eerste bestand dat Apache ziet bestaat
wordt het bestand dat wordt geladen en weergegeven aan de client.
Met behulp van het bovenstaande .htaccess-bestand is hier een voorbeeld van de goede (ingeschakelde) en slechte (uitgeschakelde) gevallen:
Zoals ik eerder al zei, veroorzaakt een syntaxisfout in uw .htaccess-bestand dat de server vastloopt.
U kunt dit in uw voordeel gebruiken om te testen of uw server ondersteuning voor .htaccess heeft ingeschakeld!
Hier is een voorbeeld van een .htaccess-bestand dat moet worden opgeblazen.
# Dit bestand is bedoeld om Apache op te blazen. Dit helpt # bepalen of. Htaccess is ingeschakeld of niet! AHHHHHHH
Het is vrij duidelijk dat "AHHHHHHH" geen geldige Apache-richtlijn is. Dit zal veroorzaken
een foutmelding als Apache het .htaccess-bestand probeert te lezen! Dus, als je een pagina terugschreeuwt
"Internal Server Error", dan is uw server op zoek naar .htaccess-bestanden! Als je dat echt bent
zie de inhoud van het index.html-bestand, dan is het waarschijnlijk dat ze zijn uitgeschakeld. Ook hier zijn de goede en slechte gevallen:
Ten slotte is het nog steeds mogelijk dat. Htaccess-ondersteuning nog steeds is ingeschakeld, net met
unieke instellingen. Systeembeheerders kunnen de naam van het .htaccess-bestand juist wijzigen
zoals we de naam hebben veranderd van het standaardbestand waar Apache naar zoekt. Dit is mogelijk door
gebruik van de AccessFileName
richtlijn in het algemene configuratiebestand. Nogmaals, het beste ding om te doen in dat geval zou zijn om
neem contact op met uw hostingbedrijf voor meer informatie.
Voordat ik inga op enkele coole dingen die je kunt doen met .htaccess-bestanden, moet ik dat doen
vertel je waar je aan begint. Zoals ik eerder al zei, sta je toe
het overschrijven van serverinstellingen voor een map en al zijn subdirectories. Altijd
Houd er rekening mee dat u alle submappen en de huidige beïnvloedt
directory.
Als de server is ingeschakeld, neemt deze ook een potentiële prestatieshit. De reden is omdat, elk server aanvraag, als .htaccess ondersteuning is ingeschakeld, wanneer Apache het gevraagde bestand gaat ophalen voor de client, moet het zoeken naar een .htaccess-bestand in elke map die leidt naar waar het bestand wordt opgeslagen.
Dit betekent een aantal dingen. Ten eerste omdat Apache altijd naar de .htaccess-bestanden zoekt
bij elke aanvraag worden alle wijzigingen in het bestand onmiddellijk doorgevoerd.
Apache slaat ze niet in de cache op en zal uw wijzigingen meteen zien in het volgende verzoek.
Dit betekent echter ook dat Apache voor elk verzoek wat extra werk zal moeten doen.
Als een gebruiker bijvoorbeeld /www/supercool/test/index.html vraagt, dan is uw server
zou controleren op de volgende .htaccess-bestanden:
/www/.htaccess /www/supercool/.htaccess /www/supercool/test/.htaccess
Deze potentiële toegang tot bestanden (mogelijk omdat de bestanden mogelijk niet bestaan) en hun
uitvoering (als ze zouden bestaan) kost tijd. Nogmaals, mijn ervaring is dat het zo is
onmerkbaar en het weegt niet op tegen de voordelen en flexibiliteit die .htaccess
bestanden bieden ontwikkelaars.
Echter, als dit u betreft, zolang u toegang heeft tot het bestand httpd.conf
dan kun je altijd je richtlijnen daar neerleggen. Door AllowOverride in te stellen op "Geen"
Apache zal niet zoeken naar die .htaccess-bestanden. Als je echt wilt, kun je zetten
de richtlijnen die je in je /www/supercool/test/.htaccess-bestand wilde zetten
rechtstreeks in httpd.conf zoals zo:
# Zet richtlijnen hier
Het nadeel van deze aanpak is dat je de Apache-server opnieuw moet opstarten
bij elke wijziging zodat de nieuwe configuratie opnieuw wordt geladen.
Uiteindelijk komt het neer op persoonlijke voorkeur of wat je gastheer ook maar toestaat.
Ik gebruik liever .htaccess-bestanden omdat ik de flexibiliteit heb om ze waar te plaatsen
Ik wil, en hun effecten zijn direct live zonder dat een server-reset nodig is.
Voordat we ingaan op een van de complexe functies, laten we beginnen met iets
eenvoudig, maar nuttig, zodat u een gevoel kunt krijgen voor het werken met .htaccess-bestanden.
Directoryvermeldingen zijn zo gewoon dat je ze waarschijnlijk veel tegenkomt
keer surfen op het web.
Wanneer een gebruiker een map opvraagt, zoekt Apache eerst naar het standaardbestand. Meestal wordt dit "index.html" of "index.php" of iets dergelijks genoemd. Wanneer dat niet het geval is
zoek een van deze bestanden, het valt terug op de mod_autoindex module om
een lijst weergeven van de bestanden en mappen in die map. Soms dit
is ingeschakeld, soms uitgeschakeld en soms ook wel
maak aanpassingen. Nou, met .htaccess kunt u deze vermeldingen eenvoudig manipuleren!
Standaard zijn directoryvermeldingen ingeschakeld. Hier is een voorbeeldscenario.
Stel dat je een aantal mediabestanden hebt die je opslaat op je webserver,
en je wilt ze verbergen voor het publiek en zoekmachines, zodat niemand dat kan
deze bestanden stelen. Dat is heel gemakkelijk om te doen! Maak eenvoudig een .htaccess-bestand
in de map die u wilt verbergen en voeg de volgende instructie toe:
# Directoryvermeldingen uitschakelen in deze map en submappen # Hiermee worden de bestanden van het publiek verborgen, tenzij ze directe URL's kennen. Opties -Indexen
Als we dit onderbreken, gebruiken we de Options-richtlijn.
Deze richtlijn kan een aantal waarden aannemen (eerder genoemd). Als u de waarden opgeeft
met een + of - zoals ik deed met -Indexes, dan zal dit het
Opties die zijn ingeschakeld in hogere mappen en de algemene configuratie!
Als u geen + of - opgeeft, wordt de lijst die u opgeeft
de enkel en alleen opties ingeschakeld voor die map en zijn submappen. Geen andere opties zullen worden ingeschakeld. Omdat u misschien niet weet welke opties eerder zijn ingeschakeld, zult u dit waarschijnlijk doen
gebruik de + of - syntaxis, tenzij je absoluut zeker bent enkel en alleen wil bepaalde opties.
Nu, met die richtlijn in uw .htaccess-bestand, wanneer u uw browser naar die map richt
je zult de bestanden niet meer kunnen zien. Dit is het voor en na:
Oké, misschien is het volledig uitschakelen van de indexlijst niet wat je wilt. Het is meer
waarschijnlijk dat u de indexen wilt behouden maar alleen bepaalde personen toegang wilt geven.
Dat is waar basisverificatie erg handig kan zijn. Dit is de meest voorkomende
type verificatie op internet. Wanneer de gebruiker probeert toegang te krijgen tot de pagina ze
zal het bekende gebruikersnaam / wachtwoord-dialoogvenster zien. Alleen een gebruiker met de juiste
inloggegevens kunnen toegang krijgen tot de inhoud.
Voor basisverificatie zijn er slechts twee stappen.
Traditioneel hebben webontwikkelaars het bestand genoemd waarin de gebruikersnamen en worden opgeslagen
wachtwoorden ".htpasswd". Dit komt omdat het opdrachtregelhulpprogramma wordt meegeleverd
Apache dat het juiste versleutelde gebruikersnaam / wachtwoord-paar genereert is eigenlijk
genaamd htpasswd! Als u zich op uw gemak voelt op de opdrachtregel, kunt u de htpasswd gebruiken
tool, maar er zijn tal van online tools die de uitvoer net zo gemakkelijk genereren.
Ik heb een voorbeeld gemaakt van .htpasswd voor een gebruiker "joe" met wachtwoord "cool".
Ik gooide die waarden in de gekoppelde online tool en produceerde:
joe: $ apr1 $ QneYj / ... $ 0G9cBfG2CdFGwia.AHFtR1
Uw uitvoer kan anders zijn, dat is goed. De wachtwoorden zijn gehasht met
een willekeurig zout om ze een beetje meer uniek en veilig te maken. Zodra uw gebruikersnaam
en wachtwoordcombinatie is toegevoegd aan het .htpasswd-bestand, dan zou u dat moeten doen
voeg de volgende regels toe aan uw bestand:
# Basisverificatie inschakelen AuthType Basic # Dit wordt weergegeven aan de gebruiker in het aanmeldingsdialoogvenster. AuthName "Toegang tot de verborgen bestanden" # Dit moet je bewerken. Het is het absolute pad naar het .htpasswd-bestand. AuthUserFile /path/to/.htpasswd # Hiermee kan elke gebruiker vanuit het .htpasswd-bestand toegang krijgen tot de # content als deze de juiste gebruikersnaam en wachtwoord opgeeft. Vereist geldige gebruiker
Die commando's zijn goed gedocumenteerd. De enige echte uitdaging is dat jij
moet het pad naar het .htpasswd-bestand juist instellen
gegenereerd. Dit is een volledig absoluut pad van de absolute wortel van de
server. Omdat het .htpasswd-bestandspad absoluut is, is het ook goed
oefen om het in een map buiten de map waar Apache
dient webpagina's voor het publiek. Op die manier kunnen kwaadwillende gebruikers niet in staat zijn
om eenvoudig toegang te krijgen tot de onbewerkte lijst van gebruikers / wachtwoorden die zijn opgeslagen in de .htpasswd.
Als alles eenmaal is ingesteld, wanneer iemand de pagina probeert te openen
ontvang het volgende dialoogvenster:
Basisverificatie is leuk en gemakkelijk, maar het is geen totale oplossing.
Wachtwoorden worden via de draad verzonden, Base 64 gecodeerd, in platte tekst. als jij
wil je meer beveiligde authenticatie, dan moet je Basic Authentication koppelen
met https, een meer
beveiligd protocol. Dat is een onderwerp voor een andere keer.
Het kernprotocol van het web is het Hypertext Transfer Protocol (HTTP).
Als je echt wilt begrijpen wat de rest van de Apache-richtlijnen zijn
omgaan met, moet u enige kennis van het protocol hebben. Im
alleen maar naar su pplya zeer snelle samenvatting hier. Ik zal ook een inspanning leveren
om uit te leggen wat de meer complexe richtlijnen doen, maar het zal maken
meer zin als u HTTP-headers begrijpt.
De snelle samenvatting is dat HTTP staatloos is. Bij elk verzoek (vanuit de browser)
en elk antwoord (van de webserver zoals Apache) bestaat uit twee delen.
Een sectie Header-informatie en vervolgens een optionele sectie met de gegevens zelf,
als er gegevens zijn.
Informatie over de aanvraag van de header specificeert vaak het bestand dat ze zijn
het aanvragen van de server (index.html), elke toestandsinformatie die zij zouden moeten verschaffen
(zoals cookiegegevens) en de mime-typen die het bereid is terug te accepteren van de server
(tekst / html of zelfs gzip gecodeerde inhoud).
Response header-informatie specificeert vaak generieke serverinformatie (Apache, PHP,
Perl-versies enz.), De inhoudscodering, lengte, mime / type en meer. Er
zijn een overvloed aan HTTP-headers om nog meer details te specificeren, zoals Cache Control,
Omleidingen en statuscodes. Ooit een 404 gekregen? Dat was het resultaat van het aanvragen van een
bestand dat de server niet kon vinden, en dus heeft het een 404 teruggestuurd
Statuscode in zijn
antwoord.
Wat heeft dit met .htaccess te maken? Nou, je kunt Apache-richtlijnen gebruiken om
overschrijf (set) of voeg nieuwe headers toe (add) die naar de client worden teruggestuurd
in de sectie Header van de reactie. Ook, zoals je zult zien in latere tutorials,
geavanceerdere functionaliteit zoals URL Rewriting gaat over de binnenkomende headers.
Laten we eenvoudig beginnen, we zullen een header toevoegen aan de Response en zien wat er gebeurt:
# Voeg de volgende koptekst toe aan elk antwoord Koptekst X-HeaderName toevoegen "Header Value"
Het aanvragen van een bestand in dezelfde map als dit .htaccess-bestand toont de
extra kop:
Je dacht waarschijnlijk dat het eigenaardig was dat ik de aangepaste koptekst prefixde
"X-". Dit is eigenlijk een gebruikelijke conventie die ontwikkelaars gebruiken om dat aan te duiden
de header is een niet-standaard header. Dit maakt het heel gemakkelijk om te beseffen dat deze header op maat is. Deze conventie is
hier kort genoemd.
Op een meer komische toon, hebben sommige mensen een beetje plezier gehad met headers.
Deze site
wijst op een aantal nogal ongebruikelijke headers die overal op internet te vinden zijn.
Ik wil u echter echt laten zien hoe u kopteksten maakt, zodat u dat kunt
gebruik ze als een foutopsporingstechniek. Laatst heb ik een test gedaan
controleer om te zien of bepaalde modules zijn ingeschakeld op een webserver. ik schreef
de volgende controle:
Header add X-Enabled mod_gzip Header X-enabled mod_deflate toevoegen
Toen ik mijn volgende verzoek met mijn browser deed en de Response Headers controleerde, het
toonde aan dat geen van de modules was ingeschakeld! Ik heb contact opgenomen met mijn hostingbedrijf en zij zijn overeengekomen om gzip-compressie in te schakelen!
Er is een verschil tussen koptekstset en
Header toevoegen. Met toevoegen, zal de kopbal altijd wordt toegevoegd
naar de reactie. Zelfs als het gebeurt om meerdere keren in het antwoord te verschijnen. Dit is meestal
wat je zou willen voor aangepaste headers. U zou set gebruiken wanneer u dat wilt
overschrijven de waarde van een van de standaard headers die Apache retourneert. Een
voorbeeld zou de mime / type overschrijven die wordt gespecificeerd door het inhoudstype
header voor een bepaald bestand. Apache zou de interne waarde instellen en dan
gebruik dat wanneer de standaardkop wordt afgedrukt. Er zal geen .... zijn
duplicaten, en dus geen mogelijkheid om een fout of verwarring te interpreteren
door de klant. (In het geval u zich afvroeg, staat in de HTTP-specificatie dat, in
In het geval van duplicaten moet de client altijd de laatst opgegeven waarde gebruiken
voor die dubbele kop.)
Ik heb enkele basisrichtlijnen van Apache in vrij klein detail besproken. Ik wilde de fundamentele details uit de weg halen, zodat de volgende tutorial over coolere dingen kan praten. Mijn volgende artikel zal
focus op enkele van de meer handige functies die u met .htaccess kunt inschakelen.
Deze onderwerpen omvatten:
En vergeet niet, als je moeite hebt om dit te volgen, is een andere optie om het .htaccess Builder-hulpprogramma te proberen dat beschikbaar is op Envato Market.
Accentsconagua