<-
Apache > HTTP Sunucusu > Belgeleme > Sürüm 2.2

URL’lerin Dosya Sistemi ile Eşleştirilmesi

Mevcut Diller:  en  |  ja  |  ko  |  tr 

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.

top

İlgili Modüller ve Yönergeler

top

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.

top

Belge Kök Dizini Dışındaki Dosyalar

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ı.

top

Kullanıcı Dizinleri

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

top

URL Yönlendirme

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

top

Karşı Vekil

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.

top

Yeniden Yazma Motoru

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.

top

Dosya orada yok

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.

Mevcut Diller:  en  |  ja  |  ko  |  tr