Apache HTTP Sunucusu Sürüm 2.2
Bu belgede, bir istekte belirtilen URL’nin sunulacak dosyanın dosya sistemindeki yerini bulmak için Apache tarafından nasıl kullanıldığı açıklanmaktadır.
İlgili Modüller | İlgili Yönergeler |
---|---|
DocumentRoot
Yapılan bir isteğe hangi dosyanın sunulacağına karar verirken
Apache’nin öntanımlı davranışı istek için URL yolunu (URL’den konak ismi
ve port ayrıldıktan sonra kalan kısım) alıp bunu yapılandırma dosyasında
DocumentRoot
yönergesi ile
belirtilen dizinin sonuna eklemektir. Bu nedenle, DocumentRoot
altındaki dizinler ve dosyalar
sitenin dışardan görünen temel belge ağacını oluştururlar.
Örneğin, DocumentRoot
yönergesine
/var/http/html
atanmış olsun.
http://mesela.dom/balıklar/zargana.html
şeklindeki bir
istek için istemciye /var/http/html/balıklar/zargana.html
dosyası sunulur.
Apache ayrıca, sunucunun birden fazla konak için istek kabul etmesini
sağlayan sanal barındırmaya da muktedirdir. Bu
durumda her sanal konak için ayrı bir DocumentRoot
belirtilebileceği gibi sunulacak içeriğin
istekte bulunulan IP adresi veya konak ismine dayanarak devingen olarak
saptanmasını sağlayabilen mod_vhost_alias
modülüyle
gelen yönergeler de kullanılabilir.
DocumentRoot
yönergesi
yapılandırma dosyanızda ana sunucu için bir tane ve muhtemelen
oluşturduğunuz her sanal konak için de birer
tanedir.
Bazen dosya sisteminde doğrudan DocumentRoot
altında bulunmayan dosyalara da erişim izni
vermek gerekir. Apache’de bunu sağlamanın çeşitli yolları vardır. Unix
sistemlerinde sembolik bağlar sayesinde dosya sisteminin farklı
yerlerindeki dosyaları ve dizinleri DocumentRoot
altındaymış gibi göstermek mümkündür.
Options
yönergesine değer olarak
FollowSymLinks
veya SymLinksIfOwnerMatch
atanmadıkça Apache olası güvenlik açıklarına karşı öntanımlı olarak
sembolik bağları izlemez.
Bundan başka, dosya sisteminin farklı parçalarını belge kök dizini
altında göstermek için Alias
yönergesi de kullanılabilir. Örneğin,
Alias /belgeler /var/http
yapılandırması ile
http://mesela.dom/belgeler/dizin/dosya.html
URL’si için
dosya sistemindeki /var/http/dizin/dosya.html
dosyası
sunulacaktır. Hedef dizindeki dosyaları birer CGI betiği olarak imlemesi dışında ScriptAlias
yönergesi de aynı şekilde
çalışır.
Biraz daha fazla esnekliğin gerektiği durumlarda düzenli ifadelere dayalı eşleşmeler sağlamak
üzere AliasMatch
ve ScriptAliasMatch
yönergelerinin gücünden
yararlanılabilir. Örneğin,
ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+)
/home/$1/cgi-bin/$2
satırı sayesinde http://mesela.dom/~user/cgi-bin/betik.cgi
URL’si /home/user/cgi-bin/betik.cgi
dosyası ile
eşleştirilir ve dosya bir CGI betiği olarak çalıştırılırdı.
Geleneksel olarak Unix sistemlerinde belli bir kullanıcının (örn,
birisi) ev dizinine ~birisi/
şeklinde atıfta
bulunulabilir. mod_userdir
modülü bu özelliği site
üzerinden kullanıcıların ev dizinlerindeki dosyaları kişisel sayfalar
olarak sunmalarını sağlamak üzere kullanır. Örnek:
http://mesela.dom/~birisi/dosya.html
Güvenlik sebebiyle kullanıcıların ev dizinlerine doğrudan HTTP erişimi
vermek uygun olmaz. Bu bakımdan, kullanıcının ev dizini altında HTTP
erişimi verilecek dosyaların bulunduğu dizini belirtmek için UserDir
yönergesi sağlanmıştır.
Öntanımlı olan Userdir public_html
yapılandırması ile
yukarıdaki gibi bir URL kullanıcının ev dizini (/etc/passwd
dosyasında belirtilir) /home/birisi/
altında yer alan
/home/birisi/public_html/dosya.html
dosyası ile
eşleşirdi.
Ev dizininin yerinin /etc/passwd
dosyasında belirtilmediği
sistemlerde kullanılmak üzere Userdir
yönergesinin başka
kullanım şekilleri de vardır.
Bazı kişiler (genellikle URL üzerinde %7e
olarak
kodlanması sebebiyle) "~" simgesini biçimsiz bulabilir ve kullanıcı
dizinlerini imlemek için başka bir karakter kullanmayı tercih
edebilirler. Bu işlevsellik mod_userdir
tarafından
desteklenmemektedir. Ancak, kullanıcı dizinleri düzgün şekilde
yapılandırılmışsa istenen etki AliasMatch
yönergesi ile sağlanabilir.
Örneğin, http://mesela.dom/sayfalar/birisi/dosya.html
URL’si ile /home/birisi/public_html/dosya.html
dosyasını
eşlemek için AliasMatch
yönergesi şöyle
kullanılabilirdi:
AliasMatch ^/sayfalar/([a-zA-Z0-9]+)/?(.*)
/home/$1/public_html/$2
Yukarıdaki bölümlerde açıklanan yapılandırma yönergeleri Apache’ye
içeriği dosya sisteminin belli bir yerinden alıp istemciye göndermesini
söyler. Bazen istemciye, istediği içeriğe farklı bir URL ile
erişebileceğini ve bu URL için ayrı bir istek yapması gerektiğini
bildirmek gerekir. Bu işleme yönlendirme adı verilir ve bu
işlevsellik Redirect
yönergesi
ile sağlanır. Örneğin, DocumentRoot
altındaki /foo/
dizininin içeriğinin /bar/
adında yeni bir dizine taşınması halinde istemciye yeni konumun
bildirilmesi şöyle sağlanabilirdi:
Redirect permanent /foo/
http://mesela.dom/bar/
Bu atama sayesinde /foo/
ile başlayan URL yolları
mesela.dom
sunucundaki /bar/
dizini altındaki
içeriğe yönlendirilmektedir. Yönlendirmeyi aynı sunucu üzerinde yapmak
zorunda değilsiniz, bu yönerge ile başka bir sunucuya da yönlendirme
yapabilirsiniz.
Apache ayrıca, yeniden yazma ile ilgili daha karmaşık sorunlara çözüm
olarak RedirectMatch
diye bir
yönerge daha sağlar. Örneğin bir sitenin baş sayfasını diğer isteklerden
ayrı olarak farklı bir siteye yönlendirmek için yönergeyi şöyle
kullanabilirsiniz:
RedirectMatch permanent ^/$
http://misal.dom/ilksayfa.html
Bundan başka, bir sitedeki tüm sayfalara yapılan istekleri başka bir siteye geçici olarak yönlendirmek için şöyle bir şey yapabilirsiniz:
RedirectMatch temp .*
http://mesela.misal.dom/ilksayfa.html
Apache ayrıca, uzak sunuculardaki belgelerin yerel sunucunun URL alanına getirilmesini de mümkün kılar. Bu tekniğe HTTP sunucunun belgeleri uzak bir sunucudan alıp istemciye sunmasını sağlayarak bir vekil sunucu gibi davranması nedeniyle ters vekalet adı verilir. Belgelerin istemciye özkaynağın bulunduğu sunucudan geliyormuş gibi değilde doğrudan isteği yaptığı sunucudan geliyormuş gibi sunulması nedeniyle bu işlem normal vekaletten farklıdır.
Aşağıdaki örnekte, istemci /foo/
dizini altından bir belge
istemekte, sunucu ise bu belgeyi dahili.mesela.dom
üzerindeki /bar/
dizininden alıp istemciye yerel sunucudan
geliyormuş gibi sunmaktadır:
ProxyPass /foo/ http://dahili.mesela.dom/bar/
ProxyPassReverse /foo/ http://dahili.mesela.dom/bar/
ProxyPassReverseCookieDomain dahili.mesela.dom harici.mesela.dom
ProxyPassReverseCookiePath /foo/ /bar/
ProxyPass
sunucuyu uygun
belgeleri alması için yapılandırırken ProxyPassReverse
yönergesi dahili.mesela.dom
sunucusundan kaynaklanan yönlendirmeleri yeniden yazar, böylece bunların
yerel sunucudaki yerleri belirlenmiş olur. Benzer şekilde, ProxyPassReverseCookieDomain
ve
ProxyPassReverseCookiePath
yönergeleri de arka sunucu tarafından atanan çerezleri yeniden yazar.
Yalnız, belgelerin içindeki hiperbağların yeniden yazılmayacağına
dikkat ediniz. Dolayısıyla, belge içinde
dahili.mesela.dom
’u ismiyle hedef alan mutlak hiperbağlar
varsa bunlar istemci tarafından vekil sunucudan değil doğrudan
dahili.mesela.dom
’dan istenecektir. Üçüncü parti modüller
arasında HTML ve XHTML’de hiperbağları yeniden yazabilen mod_proxy_html
adında bir modül vardır.
Daha güçlü ikameler gerektiğinde mod_rewrite
modülü
tarafından sağlanan yeniden yazma motoru işe yarayabilir. Bu modüldeki
yönergeler sunulacak içeriğin yerine karar vermek için kaynak IP adresi,
tarayıcı türü gibi isteğe özgü özellikleri kullanırlar.
mod_rewrite
modülü buna ek olarak isteğin nasıl ele
alınacağına karar vermek için harici yazılımları ve veritabanlarını
kullanabilir. Yeniden yazma motoru yukarıda değinilen üç eşleşme türünü
de uygulayabilecek yetenektedir: Dahili yönlendirmeler (rumuzlar),
harici yönlendirmeler ve vekalet. mod_rewrite
modülü
tarafından sağlanan yeteneklerin ayrıntılı açıklamaları ve bunların
kullanım örnekleri URL Yeniden Yazma
Rehberinde bulunmaktadır.
Kaçınılmaz olarak, dosya sisteminde mevcut olmayan dosyalar için de istek yapılacaktır. Bunun çeşitli sebepleri olabilir. Bazı durumlarda bu, belgelerin yerlerininin değiştirilmesinin bir sonucu olabilir. Bu durumda yapılacak en iyi şey, istemciyi belgeyi yeni yerinden istemesi için bilgilendirmek amacıyla URL yönlendirmesi kullanmaktır. Bu şekilde, içeriğin yeri değişse bile eski yer imlerinin ve hiperbağların çalışmaya devam edeceklerinden emin olabilirsiniz.
"Dosya orada yok" ("File Not Found") hatalarının diğer bir bildik
sebebi de URL’lerin hiperbağlarda veya doğrudan tarayıcıda kasıtlı ya da
kasıtsız, yanlış yazılmasıdır. Bu tür sorunlarda yardımcı olması için
Apache mod_speling
(sic) adında bir modülle gelir. Bu
modül etkin kılındığında Apache, "Dosya orada yok" ("File Not Found")
hatalarının önünü kesip başka bir yerde benzer isimde bir dosya var mı
diye bakar. Böyle bir dosya varsa, mod_speling
istemciye dosyanın doğru yerini bildiren bir HTTP yönlendirmesi yollar.
Benzer çok sayıda dosya varsa bunlar istemciye bir liste halinde
sunulur.
mod_speling
modülünün en yararlı özelliklerinden biri
de dosya isimlerini harf büyüklüğüne duyarsız olarak arayabilmesidir.
Dosya isimlerinde harf büyüklüğünün önemli olduğu Unix benzeri sistemler
hakkında bilgisi olmayan kullanıcılara sahip sistemlerin kullanıcılarına
bu büyük yarar sağlar. Fakat modülün URL düzeltmekten başka şeyler için
de kullanılması, istemcilerden gelen neredeyse her isteğin URL
yönlendirmesine konu olmasına sebep olarak sunucunun yükünü
arttırabilir.
Yerinde bulunmayan içeriğin bulunması çabalarının tümü Apache’nin 404
(Dosya orada yok) HTTP durum kodlu bir hata sayfası döndürmesine yol
açar. Bu sayfanın içeriği ErrorDocument
yönergesi ile denetlenebilir ve Hata Yanıtlarının Kişiselleştirilmesi
bölümünde anlatıldığı gibi oldukça esnek bir şekilde
kişiselleştirilebilir.