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:
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:
apache
# 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]
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
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 edilerekindex.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:
nginx
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;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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:- İstenen URI’ya karşılık gelen dosya (
$uri
). - İstenen URI’ya karşılık gelen dizin (
$uri/
). - Eğer hiçbiri yoksa, istek
/index.php
’ye yönlendirilir ve query string korunur (?$query_string
).
- İstenen URI’ya karşılık gelen dosya (
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:
bash
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
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Açıklama:
servbay.demo { ... }
: Bu site bloğuservbay.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:
Geçişte dikkat edilmesi gereken temel farklar şunlardır:
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 genellikleRewriteRule
veRewriteCond
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), kurallarrewrite
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’inlocation
/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.
- Apache:
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
velocation
bloklarıyla kurulur. - Caddy: Yapı merkezi şekilde
Caddyfile
da; 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.
- Apache: Farklı dizinlerde farklı
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’derewrite
ve matcher’larla, NGINX’dekitry_files
ise Caddy’defile
matcher’ı veya direktphp_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.
- 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
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’delocation
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.
- Her sunucu istekleri işlerken ve kuralları uygularken kendine özgü davranışlar ve öncelik kurallarına sahiptir. Örneğin, Apache’de
Ö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.