Rewrite ve .htaccess: NGINX ile Apache’den ServBay’deki Caddy’e Geçişte Farklar ve Dikkat Edilmesi Gerekenler

Arka Plan Bilgisi

URL Rewrite (genellikle Rewrite veya URL Yeniden Yazma olarak anılır), web sunucusu katmanında gelen istek URL’sinin dinamik olarak değiştirilmesini sağlayan bir tekniktir. Bu sayede, kullanıcının ya da arama motorlarının eriştiği orijinal URL (ör. /?page=123), sunucu içinde farklı bir URL’ye (ör. /posts/123/) yönlendirilir, fakat kullanıcının tarayıcı adres çubuğunda gördüğü yine de yeniden yazılmış URL olur. Bu teknoloji şu alanlarda yaygın olarak kullanılır:

• URL Yapısını Güzelleştirme: Daha okunabilir, akılda kalıcı ve paylaşılabilir “temiz” veya “güzel” URL’ler oluşturma.
• SEO’yu Geliştirme: Arama motorları, açıklayıcı ve yapısı net URL’leri daha çok tercih eder.
• İçsel Detayları Gizleme: Dosya yolları veya sorgu parametreleri gibi ayrıntıların gizlenmesiyle güvenliğin artırılması.
• URL’yi Standartlaştırma: Belirli bir URL formatının zorunlu kılınması (ör. www’li/ww’suz veya HTTPS kullanımı).
• Routing (Yönlendirme) Sağlama: Modern web çatılarının çoğu, bütün istekleri tek bir giriş dosyasına (örn. index.php) yönlendirmek için Rewrite teknolojisini kullanır ve böylece çatı, isteği işlemeye başlar.

Rewrite kurallarını anlamak ve yapılandırmak, web geliştirme için temel bir beceridir.

ServBay’in NGINX ve Apache Desteği

ServBay, NGINX ve Apache’yi yerleşik olarak tam destekli şekilde sunar. Kullanıcılar, proje gereksinimlerine veya kişisel tercihlerine göre kolayca varsayılan web sunucusunu değiştirebilirler.

Varsayılan web sunucusunun nasıl değiştirileceği için şu dökümana bakabilirsiniz: Varsayılan Web Sunucusu Nasıl Ayarlanır

ServBay, geliştiricilere Caddy, NGINX ve Apache gibi popüler web sunucusu seçenekleri sunar. Yerel geliştirme ortamındaki yapılandırmaları sadeleştirmek adına, ServBay hem Caddy hem de NGINX için yaygın Rewrite kurallarını önceden yapılandırmıştır—bu, modern web çatılarının ve CMS’lerin büyük bölümü için gereklilikleri karşılar. Yani PHP tabanlı WordPress, Laravel, Symfony gibi birçok yaygın uygulamayı ServBay ortamında genellikle ekstra rewrite yapılandırması olmadan, doğrudan çalıştırabilirsiniz: Gerçek “kutu dışı çalışma” sağlar.

Öte yandan, Apache veya NGINX alışkanlığı olan ve mevcut sitesini veya projesini ServBay’deki Caddy’ye taşımak isteyen geliştiriciler için, Rewrite kuralı yapılandırmasındaki farkları anlamak oldukça kritiktir. Bu makale, Apache, NGINX ve Caddy’nin Rewrite kuralı yapılandırmasında ayrışan noktalarını ve geçiş sırasında dikkat edilmesi gereken önemli başlıkları detaylandıracaktır.

Kutu Dışında Kullanıma Hazır Rewrite Kuralları: ServBay’in Avantajı

Önemli Uyarı

ServBay’in en önemli tasarım ilkelerinden biri, yerel geliştirme ortamının kurulmasını ve ayarlanmasını basitleştirmektir. Başlıca web uygulamaları ve çatıları için gereken rewrite kuralı yapılandırması ServBay’de hazır olarak sunulur. Bu, ServBay’de bu uygulamaları çalıştırırken genellikle elle ekstra rewrite kuralı yazmanız ya da değiştirmeniz gerekmediği anlamına gelir—ServBay sizin için bu kritik (ama sıkıcı) işi otomatikleştirir.

Apache veya NGINX üzerinde çalışan bir web sitesini ServBay’in Caddy ortamına taşıyorsanız ve karmaşık, özelleşmiş rewrite kuralları kullanıyorsanız, şu detaylı geçiş rehberlerinden yararlanabilirsiniz:

• NGINX Web Sitesini ServBay’e (Caddy) Taşıma
• Apache Web Sitesini ServBay’e (Caddy) Taşıma

Web Sunucularında Rewrite Kuralı Temel Bilgileri

Farklı web sunucuları, rewrite kuralı için farklı sözdizimi ve dosya yapısı kullanır. Deepen geçişleri için bu farklılıkları anlamak gerekir. Bu bölümde Apache, NGINX ve Caddy’de rewrite yapılandırmasına kısa bir genel bakış sunulmuştur.

Apache’de .htaccess Dosyası

Apache HTTP Sunucu, rewrite kurallarını .htaccess dosyasıyla yapılandırır. .htaccess, genellikle sitenin kök dizininde veya belirli bir alt dizinde yer alan dağıtık (dağınık) bir yapılandırma dosyasıdır. Bu dosya sayesinde, klasör düzeyinde ana sunucu ayarlarının üzeri yazılabilir ve dosyanın bulunduğu dizin ile alt dizinlerine uygulanır (eğer alt dizinlerde ayrı bir .htaccess yoksa). Apache, rewrite’ın işlenmesini mod_rewrite modülüyle sağlar.

Temel Kullanım Örneği

Apache’de sık kullanılan bir .htaccess örneği; mevcut olmayan dosya veya dizinlere yapılan tüm istekleri index.php’ye yönlendirmek içindir ve bu, PHP çatılarında/CMS’lerde neredeyse standarttır:

# Rewrite motorunu etkinleştir
RewriteEngine On

# İstenen dosya veya dizin yoksa, rewrite kuralını çalıştır
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# Tüm istekleri index.php’ye ve varsa query string ile yönlendir
RewriteRule ^(.*)$ index.php [L,QSA]

Açıklama:

• RewriteEngine On: O dizindeki rewrite fonksiyonunu etkinleştirir.
• RewriteCond %{REQUEST_FILENAME} !-f: Dosya yolu (%{REQUEST_FILENAME}) bir dosya değilse (!-f).
• RewriteCond %{REQUEST_FILENAME} !-d: Dosya yolu bir dizin değilse (!-d).
• RewriteRule ^(.*)$ index.php [L,QSA]: Rewrite kuralı.
  • ^(.*)$: Tüm URL yollarına eşleşir.
  • index.php: Yol rewrite edilerek index.php olarak ayarlanır.
  • [L]: “Last”—bu kuraldan sonra sonraki kurallar işlenmez.
  • [QSA]: "Query String Append"—orijinal URL’deki query string korunur ve yönlendirilen URL’ye eklenir.

NGINX Rewrite Kuralları

NGINX’in rewrite kuralları, ana yapılandırma dosyası (nginx.conf) veya genellikle conf.d ya da sites-available/sites-enabled klasörlerindeki siteye özel dosyalarda yapılandırılır. NGINX kuralları genellikle server (sanallaştırılmış host tanımı) veya location (belirli URL yolları için) bloklarında tanımlanır. NGINX’in rewrite işlevi (ngx_http_rewrite_module) oldukça esnektir, fakat sözdizimi Apache’den oldukça farklıdır.

Temel Kullanım Örneği

Tüm isteklerin sonunda index.php’ye rewrite yapılmasına yönelik tipik bir NGINX yapılandırma örneği aşağıdaki gibidir:

server {
    listen 80;
    server_name servbay.demo; # ServBay marka alan adı örneği

    root /Applications/ServBay/www/demo; # Site kök dizin örneği

    # Önceliklendirerek dosya, dizin arar; bulunamazsa index.php’ye rewrite yapar
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # .php isteklerini PHP-FPM/FastCGI’ye ilet
    location ~ \.php$ {
        # Dosyanın varlığını kontrol et, rastgele dosya çalıştırmayı engeller
        try_files $uri =404;
        include fastcgi_params;
        # ServBay’de varsayılan PHP FastCGI socket yolu
        fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Açıklama:

• location /: Site kök yolu için istekleri eşler.
• try_files $uri $uri/ /index.php?$query_string;: Sırasıyla şunları dener:
  1. İstenen URI’ya karşılık gelen dosya ($uri).
  2. İstenen URI’ya karşılık gelen dizin ($uri/).
  3. Eğer hiçbiri yoksa, istek /index.php’ye yönlendirilir ve query string korunur (?$query_string).
• location ~ \.php$: Sonu .php ile biten istekler için eşleşir.
• fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;: Eşleşen PHP isteklerini ServBay’in varsayılan PHP FastCGI işlemcisine iletir.

Caddy’de Rewrite Kuralları

Caddy, kendine özgü Caddyfile yapılandırma dosyasını kullanır. Caddyfile sade, okunabilir ve güçlü olacak şekilde tasarlanmıştır. Caddy’nin rewrite fonksiyonelliği rewrite direktifi ve esnek eşleştiriciler (matcher’lar) ile gerçekleştirilir.

Temel Kullanım Örneği

Caddy’de tüm istekleri index.php’ye rewrite eden temel kural aşağıdaki gibidir:

servbay.demo { # ServBay marka domaine örnek
    root * /Applications/ServBay/www/demo # Site kök dizini örneği

    # PHP isteklerini ServBay’in varsayılan PHP FastCGI işlemcisine yönlendir
    php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock

    # Statik dosya servis hizmeti sağla
    file_server

    # @notStatic matcher’ı tanımla: istenen dosya ya da dizin yoksa tetiklenir
    @notStatic {
        not {
            file {
                # {path} ya da {path}/’yi arar, yoksa matcher tetiklenir
                try_files {path} {path}/
            }
        }
    }

    # @notStatic gerçekleşirse isteği /index.php’ye rewrite et
    rewrite @notStatic /index.php
}

Açıklama:

• servbay.demo { ... }: Bu site bloğu servbay.demo domaini için geçerlidir.
• root * /Applications/ServBay/www/demo: Sitenin kök dizinini belirtir. * tüm yollar için.
• php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock: .php dosya isteklerini ServBay’de ayarlanmış PHP FastCGI’ye iletir.
• file_server: Statik dosya servisi açar. İstek edilen dosya veya dizin aranır.
• @notStatic { ... }: notStatic adında bir matcher tanımlar.
• not { file { try_files {path} {path}/ } }: Eğer {path} veya {path}/ bulunmuyorsa matcher tetiklenir.
• rewrite @notStatic /index.php: notStatic matcher’ı gerçekleşirse istek /index.php’ye yönlendirilir.

ServBay varsayılan yapılandırmasında, php_fastcgi direktifi benzer bir try_files mantığı barındırır ve yeni oluşturulan siteler için temel Caddyfile hazır olarak gelir. Yukarıdaki örnek, iş mantığının Caddy sözdizimiyle nasıl kurulduğunu göstermek içindir.

Apache veya NGINX’ten, ServBay’deki Caddy’ye Geçerken Dikkat Edilmesi Gerekenler

Web sitenizi Apache veya NGINX’ten, ServBay’de Caddy kullanacak şekilde taşıdığınızda rewrite kuralı dönüşümü kilit adımdır. ServBay çoğu yaygın kuralı otomatik olarak sunarken, özelleşmiş kural yoğunluğu fazla olan projelerde dönüşümü sizin yapmanız gerebilir.

Mutlaka detaylı geçiş dökümanlarını inceleyiniz:

• Apache Web Sitesini ServBay’e (Caddy) Taşıma
• NGINX Web Sitesini ServBay’e (Caddy) Taşıma

Geçişte dikkat edilmesi gereken temel farklar şunlardır:

1. Rewrite kuralı sözdizimi ve yapılandırma konumu:

   • Apache: .htaccess (dağıtık, klasör bazlı) veya ana sunucu dosyası (httpd.conf/site config). Kurallar genellikle RewriteRule ve RewriteCond ile tanımlanır, sözdizimi regex tabanlıdır.
   • NGINX: Ana dosya (nginx.conf) veya site yapılandırması (merkezi), location/rewrite/if/try_files ile çalışılır, sözdizimi Apache’den farklıdır.
   • Caddy: Caddyfile dosyası (merkezi), kurallar rewrite ve matcher’larla yapılır (ör. file, path, header vb.), sözdizimi daha okunaklıdır.
   • Dönüşüm: Apache’nin .htaccess’teki veya NGINX’in location/rewrite/try_files ayarlarını elle Caddyfile’a dönüştürmek gerekir. Tam otomatik bir araçla bire bir dönüştürme mümkün değildir; Caddy dökümantasyonundan rewrite ve matcher bölümlerini dikkatle inceleyin.

2. Yapılandırma dosyası yapısı:

   • Apache: Farklı dizinlerde farklı .htaccess dosyaları veya ana config dosyasında (virtualhost) merkezi tanımlar.
   • NGINX: Yapı merkezi olarak nginx.conf dosyasında ve site yapılandırmasında, server ve location bloklarıyla kurulur.
   • Caddy: Yapı merkezi şekilde Caddyfileda; site adresine göre blok açılır, kurallar blok içinde belirlenir. Genellikle NGINX’e göre daha sade ve yatay bir yapıya sahiptir.

3. Modül ve direktif karşılıkları:

   • Apache ve NGINX çok fazla modül ve direktif sunarken, Caddy de benzer işlevleri çok daha okunaklı şekilde sağlar. Örneğin, Apache’deki mod_rewrite işlevi Caddy’de rewrite ve matcher’larla, NGINX’deki try_files ise Caddy’de file matcher’ı veya direkt php_fastcgi ile karşılanır.
   • Geçişte, ihtiyaç duyduğunuz işlevler için Caddy dökümantasyonundan uygun direktifi ve kullanımı kontrol edin.

4. Varsayılan davranış ve öncelik sırası:

   • Her sunucu istekleri işlerken ve kuralları uygularken kendine özgü davranışlar ve öncelik kurallarına sahiptir. Örneğin, Apache’de .htaccess işleyişi, NGINX’de location bloklarının önceliği, Caddy’de ise direktiflerin sırayla çalışması gibi.
   • Geçiş sonrası, tüm URL yollarınızı ustaca test edin. Özellikle ServBay’in Caddy varsayılan yapılandırması zaten temel kuralı içeriyor olabilir; yinelenen ya da çakışan tanımlar kullanmamaya dikkat edin.

Özet

ServBay, yerel geliştirmede Caddy, NGINX ve Apache’den birini web sunucusu olarak seçmenizi sağlar. Caddy ve NGINX için çoğu senaryo ve uygulama için gerekli rewrite kuralları önceden yüklenmiştir; popüler uygulamalar çoğunlukla “kutudan çıkar çıkmaz” çalışır. Ancak, Apache veya NGINX’te gelişmiş yapılandırmaya alışık geliştiriciler ServBay’de Caddy’ye geçerken aralarındaki rewrite kuralı farklılıklarını bilmedir.

Apache, .htaccess ve RewriteRule/RewriteCond tabanlı dağıtık yapılandırma kullanırken; NGINX, merkezi yapılandırma ve location/rewrite/try_files ile; Caddy ise okunabilir, sade bir Caddyfile ve güçlü matcher’larla yönetilen yapı sunar.

Geçişin ana noktası, mevcut Apache ya da NGINX rewrite mantığını Caddyfile’a elle doğru şekilde dönüştürmektir. Öğrenme ve/veya çeviri gerektirse de, Caddy’nin sade yaklaşımı ve ServBay’in sunduğu hazır yapılandırmalar ile detaylı rehberler, bu süreci kolaylaştıracaktır. Umarız bu makale, bu farklılıkları kavramanıza ve ServBay ile verimli web geliştirme süreçleri yürütmenize yardımcı olur.