Rewrite en .htaccess: Verschillen en aandachtspunten bij migratie van NGINX en Apache naar Caddy in ServBay

Achtergrondinformatie

URL Rewrite (vaak kortweg Rewrite of URL-herschrijven genoemd), ook bekend als pseudo-statistieken, is een techniek waarmee het verzoek-URL op de webserver dynamisch wordt aangepast. Dit maakt het mogelijk om een door de gebruiker of zoekmachine opgevraagd origineel URL (bijvoorbeeld /?page=123) intern te herschrijven naar een ander URL (zoals /posts/123/), terwijl de gebruiker nog steeds het herschreven URL in de adresbalk ziet. Deze techniek wordt veel toegepast voor:

• Verschonen van URL-structuren: Creëer leesbare, makkelijk te onthouden en deelbare “netjes uitziende” URLs.
• Verbetering van SEO: Zoekmachines geven de voorkeur aan beschrijvende, helder gestructureerde URLs.
• Verbergen van interne implementatiedetails: Voorkom het blootleggen van bestandsroutes of queryparameters voor meer veiligheid.
• Normaliseren van URLs: Forceer een specifiek URL-formaat (zoals met of zonder www, of dwing gebruik van HTTPS af).
• Realiseer routing: Moderne webframeworks gebruiken rewrites veelvuldig om alle verzoeken naar een centraal indexbestand (zoals index.php) te sturen, zodat het framework de afhandeling overneemt.

Het begrijpen en goed configureren van Rewrite-regels is een basisvaardigheid in webontwikkeling.

ServBay-ondersteuning voor NGINX en Apache

ServBay heeft ingebouwde, volledige ondersteuning voor zowel NGINX als Apache als webserver. Je kunt eenvoudig schakelen tussen de standaard webserver op basis van projectvereisten of persoonlijke voorkeur.

Zie de documentatie voor instructies over het wisselen van de standaard webserver: Hoe stel je de standaard webserver in

ServBay biedt ontwikkelaars meerdere populaire webserver-opties zoals Caddy, NGINX en Apache. Om het opzetten van lokale ontwikkelomgevingen te vereenvoudigen, levert ServBay vooraf ingestelde rewrite-regels voor Caddy en NGINX, waarmee in de meeste behoefte van moderne webframeworks en CMS-en wordt voorzien. Dit betekent dat je voor veel toepassingen, zoals PHP-gebaseerde WordPress, Laravel, Symfony, binnen ServBay meestal direct aan de slag kunt zónder extra rewrite-configuraties. Zo geniet je dus van “out-of-the-box” functionaliteit.

Maar voor ontwikkelaars die gewend zijn aan Apache of NGINX en hun huidige websites of projecten willen migreren naar de ingebouwde Caddy-server van ServBay, is het van essentieel belang om de verschillen in configuratie van Rewrite-regels goed te begrijpen. In dit artikel bespreken we de verschillende aanpakken van Apache, NGINX en Caddy op het gebied van Rewrite-configuratie, en bieden we aandachtspunten voor een soepele migratie.

Out-of-the-box Rewrite-regels: het voordeel van ServBay

Belangrijke tip

Een van de kernprincipes achter ServBay is het vereenvoudigen van het opzetten en configureren van lokale ontwikkelomgevingen. Voor de meeste populaire webapps en frameworks levert ServBay standaard goed ingestelde rewrite-regels mee. Dat houdt in dat je deze toepassingen doorgaans niet zelf handmatig hoeft te voorzien van rewrite-regels als je ze in ServBay draait. Belangrijke, maar basale configuraties zijn al voor je afgehandeld.

Taken je echter een bestaande site van Apache of NGINX over naar de Caddy-omgeving van ServBay en heb je complexe, aangepaste rewrite-regels, raadpleeg dan zeker onderstaande gedetailleerde migratiehandleidingen:

• NGINX-site migreren naar ServBay (Caddy)
• Apache-site migreren naar ServBay (Caddy)

Inleiding tot webserver-rewrite-regels

Elke webserver hanteert een eigen syntaxis en bestandsstructuur voor rewrite-regels. Deze verschillen vormen de basis voor een geslaagde migratie tussen servers. In dit deel volgt een kort overzicht van de configuratiewijze per server: Apache, NGINX en Caddy.

Apache: het .htaccess-bestand

De Apache HTTP Server gebruikt het .htaccess-bestand om rewrite-regels te definiëren. Dit is een distributief (meestal per map) configuratiebestand dat je meestal in de root- of submap van je website plaatst. Het zorgt ervoor dat je op mappeniveau de hoofdconfiguratie kunt overschrijven (tenzij er in de submap een eigen .htaccess is). Apache verwerkt rewrites via de mod_rewrite module.

Basisvoorbeeld

Hieronder zie je een veelvoorkomende .htaccess-configuratie waarbij alle verzoeken die niet naar bestaande bestanden of mappen gaan, worden herschreven naar index.php (typisch voor veel PHP-frameworks en CMS’en):

# Schakel de rewrite-engine in
RewriteEngine On

# Als het gevraagde bestand of map niet bestaat, pas dan de rewrite toe
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# Herschrijf alle verzoeken naar index.php met behoud van querystring
RewriteRule ^(.*)$ index.php [L,QSA]

Toelichting:

• RewriteEngine On: Activeert de rewrite-functie voor de huidige map.
• RewriteCond %{REQUEST_FILENAME} !-f: Voorwaarde: controleert of het gevraagde pad geen bestaand bestand is.
• RewriteCond %{REQUEST_FILENAME} !-d: Voorwaarde: controleert of het gevraagde pad geen bestaande map is.
• RewriteRule ^(.*)$ index.php [L,QSA]:
  • ^(.*)$: Komt overeen met elk URL-pad.
  • index.php: Herschrijft het pad naar index.php.
  • [L]: Last – geef aan dat dit de laatste regel is; verdere regels worden niet toegepast.
  • [QSA]: Query String Append – voegt de oorspronkelijke querystring toe aan het herschreven URL.

NGINX-rewrite-regels

NGINX gebruikt het hoofdconfiguratiebestand (nginx.conf) of aparte sitebestanden (meestal in conf.d, sites-available/sites-enabled) voor rewrite-regels. NGINX-regels worden typisch ingesteld in het server-blok (virtual host) of in een location-blok (voor specifieke paden). De rewrite-mogelijkheden van NGINX (via ngx_http_rewrite_module) zijn krachtig, maar verschillen sterk van Apache qua syntaxis.

Basisvoorbeeld

Hieronder vind je een NGINX-configuratiefragment waarin alle verzoeken die niet naar bestaande bestanden of mappen verwijzen, worden herschreven naar index.php:

server {
    listen 80;
    server_name servbay.demo; # Voorbeeld domeinnaam van merk ServBay

    root /Applications/ServBay/www/demo; # Voorbeeld rootmap van de website

    # Probeer achtereenvolgens het bestand, de map, dan herschrijf naar index.php
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Afhandeling van .php-bestanden: stuur verzoeken door naar PHP-FPM/FastCGI
    location ~ \.php$ {
        # Controleer of bestand bestaat, voorkom willekeurige file execution
        try_files $uri =404;
        include fastcgi_params;
        # Standaard pad voor PHP FastCGI socket in ServBay
        fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Toelichting:

• location /: Matcht alle verzoeken op de root van de website.
• try_files $uri $uri/ /index.php?$query_string;: NGINX-instructie die het volgende doet:
  1. Zoekt het gevraagde bestand ($uri).
  2. Zoekt de gevraagde map ($uri/).
  3. Indien beide niet bestaan, herschrijf dan intern naar /index.php met behoud van querystring (?$query_string).
• location ~ \.php$: Regex voor alle verzoeken die eindigen op .php.
• fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;: Verzendt PHP-verzoeken naar de FastCGI-handler van ServBay.

Caddy-rewrite-regels

Caddy gebruikt een eigen Caddyfile voor configuratie. Het doel van deze indeling is eenvoud, leesbaarheid en kracht. De syntaxis wijkt sterk af van Apache en NGINX, maar is doorgaans intuïtiever. Caddy biedt rewrites via het rewrite-commando en flexibele matchers.

Basisvoorbeeld

Hier zie je een Caddyfile-fragment waar alle verzoeken – mits niet naar een bestaand bestand of map – worden herschreven naar index.php:

servbay.demo { # Voorbeeld domeinnaam van ServBay
    root * /Applications/ServBay/www/demo # Voorbeeld rootmap van de website

    # Zend PHP-verzoeken door naar de standaard PHP FastCGI-handler van ServBay
    php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock

    # Statische bestanden aanbieden
    file_server

    # Definieer een matcher @notStatic: wanneer bestand of map NIET bestaat
    @notStatic {
        not {
            file {
                # Probeert bestand {path} of map {path}/ te vinden
                # Indien niet gevonden, activeert deze matcher (@notStatic)
                try_files {path} {path}/
            }
        }
    }

    # Indien @notStatic van toepassing: herschrijf naar /index.php
    rewrite @notStatic /index.php
}

Toelichting:

• servbay.demo { ... }: Definieert een siteblok, toepasbaar op het domein servbay.demo.
• root * /Applications/ServBay/www/demo: Stelt de root directory van de site in, geldend voor alle paden.
• php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock: Caddy-instructie voor het doorsturen van .php-verzoeken of andere naar PHP-verwerker van ServBay.
• file_server: Biedt statische bestanden aan door alle paden te matchen op bestanden/mappen.
• @notStatic { ... }: Een matcher met naam notStatic.
• not { file { try_files {path} {path}/ } }: Logica: als {path} NIET overeenkomt met een bestand, of {path}/ met een map, is deze matcher waar.
• rewrite @notStatic /index.php: Indien notStatic waar is (bestand of map is er niet), intern herschrijven naar /index.php.

In de standaardconfiguratie van ServBay bevat de php_fastcgi-instructie reeds een vergelijkbare try_files-afhandeling, en zal ServBay automatisch een basis Caddyfile configureren voor een nieuwe website, zodat de meeste frameworks direct werken. Dit voorbeeld is vooral bedoeld om te tonen hoe je deze logica met de Caddy-syntaxis zelf zou opzetten.

Belangrijke aandachtspunten bij migratie van Apache of NGINX naar Caddy binnen ServBay

Bij de overgang van Apache of NGINX naar Caddy in ServBay is het converteren van rewrite-regels vaak de belangrijkste stap. Hoewel ServBay al de meeste gangbare regels vooraf instelt, zijn bij projecten met veel maatwerkregels aanpassingen handmatig vereist.

Raadpleeg altijd de gedetailleerde migratiedocumentatie:

• Apache-site migreren naar ServBay (Caddy)
• NGINX-site migreren naar ServBay (Caddy)

Belangrijke verschillen om op te letten tijdens de migratie:

1. Syntaxis en locatie van Rewrite-regels:

   • Apache: Gebruikt .htaccess-bestanden (gedistribueerd, per map) of het hoofdconfiguratiebestand (httpd.conf/siteconfig). Regels zijn vaak gebaseerd op RewriteRule en RewriteCond, met reguliere expressies.
   • NGINX: Gebruikt het hoofdconfiguratiebestand (nginx.conf) of per-site-bestanden (gecentraliseerd), met location-blokken, rewrite- en try_files-instructies, en specifieke syntaxis.
   • Caddy: Alles in de Caddyfile (gecentraliseerd). Regels via rewrite gecombineerd met flexibele matchers (zoals file, path, header). Zeer leesbare, beknopte syntaxis.
   • Omzetten: Zet regels uit .htaccess of NGINX-configuraties om naar Caddyfile-syntaxis. Door de uiteenlopende expressiemogelijkheden is deze omzetting meestal handwerk. Een “één-op-één” conversie is zelden mogelijk. Raadpleeg bij voorkeur de officiële Caddy-documentatie over rewrites en matchers voor een goed begrip.

2. Structuur van de configuratiebestanden:

   • Apache: Kan per map verschillende .htaccess-bestanden gebruiken of alles in hoofdconfiguratie/VirtualHost regelen.
   • NGINX: Alles centraal in nginx.conf plus sitebestanden, georganiseerd in server- en location-blokken.
   • Caddy: Alles centraal in de Caddyfile, groepeert per domeinadres (zoals servbay.demo), eenvoudige rechtlijnige structuur.

3. Overeenkomende modules en instructies:

   • Zowel Apache als NGINX bieden vele modules en instructies. Caddy beschikt eveneens over een krachtig instructiesysteem, zij het met andere namen en werkingen. Apache’s mod_rewrite wordt in Caddy gerealiseerd met rewrite en matchers; NGINX’s try_files vind je terug in Caddy als een instructie binnen matchers of ingebouwd in opdrachten zoals php_fastcgi.
   • Zoek bij de migratie de relevante commando’s in de Caddy-documentatie op en begrijp hun toepassing.

4. Standaardgedrag en prioriteiten:

   • Elke server heeft een eigen manier van verzoekafhandeling en volgorde van regelgeving. Apache verwerkt .htaccess op een bepaalde manier; NGINX hanteert prioriteiten in location; Caddy’s instructies worden in Caddyfile vooral op volgorde uitgevoerd.
   • Test na de migratie alle URL-paden grondig zodat rewrites werken zoals bedoeld. Let erop dat ServBay’s Caddy-standaardinstellingen al veel basisregels bevatten, om dubbele of conflicterende instellingen te voorkomen.

Samenvatting

ServBay voorziet in drie krachtige webservers voor lokale ontwikkeling: Caddy, NGINX en Apache. Hoewel ServBay Caddy en NGINX al standaard voorziet van veelgebruikte rewrite-regels zodat de meeste populaire toepassingen meteen werken, moeten ontwikkelaars die overstappen van een (maatwerk) Apache- of NGINX-configuratie naar Caddy rekening houden met de verschillen in rewrite-regelconfiguratie.

Apache werkt met .htaccess en RewriteRule/RewriteCond in een distributief model; NGINX gebruikt centrale configuratie met location-, rewrite- en try_files-instructie; Caddy biedt een krachtige maar beknopte Caddyfile met het rewrite-commando en flexibele matchers.

De sleutel tot een geslaagde migratie is het zorgvuldig omzetten van bestaande rewrite-logica uit Apache of NGINX naar de Caddyfile-syntaxis. Hoewel dit wat leercurve en handmatig werk vereist, maakt de eenvoud van Caddy en de standaardinstellingen plus documentatie van ServBay het proces overzichtelijk. Dit artikel helpt je hopelijk om deze verschillen vlot te begrijpen en razendsnel van start te gaan met webontwikkeling in ServBay!