Bu belgede, bir istekte belirtilen URL’nin sunulacak dosyanın dosya sistemindeki yerini bulmak için Apache HTTP Sunucusu tarafından nasıl kullanıldığı açıklanmaktadır.
İlgili Modüller ve Yönergeler
DocumentRoot
Belge Kök Dizini Dışındaki Dosyalar
Kullanıcı Dizinleri
URL Yönlendirme
Karşı Vekil
Yeniden Yazma Motoru
Dosya orada yok
Diğer URL Eşleme Modülleri
Ayrıca bakınız:
Yorumlar
İlgili Modüller ve Yönergeler
İlgili Modüller
İlgili Yönergeler
mod_actions
mod_alias
mod_autoindex
mod_dir
mod_imagemap
mod_negotiation
mod_proxy
mod_rewrite
mod_speling
mod_userdir
mod_vhost_alias
Alias
AliasMatch
CheckSpelling
DirectoryIndex
DocumentRoot
ErrorDocument
Options
ProxyPass
ProxyPassReverse
ProxyPassReverseCookieDomain
ProxyPassReverseCookiePath
Redirect
RedirectMatch
RewriteCond
RewriteRule
ScriptAlias
ScriptAliasMatch
UserDir
DocumentRoot
Yapılan bir isteğe hangi dosyanın sunulacağına karar verirken httpd’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://example.com/balıklar/zargana.html şeklindeki bir istek için istemciye /var/http/html/balıklar/zargana.html dosyası sunulur.
Bir dizin istenirse (/ ile biten bir yol belirtilmesi durumu), sunulacak dosya DirectoryIndex yönergesinde belirtilen dosya olacaktır. Örneğin, DocumentRoot yukarıdaki gibi belirtimiş ve siz de şunu belirtmişseniz:
DirectoryIndex index.html index.php
http://www.example.com/fish/ isteği, httpd'nin /var/www/html/fish/index.html dosyasını sunmaya, bu dosya bulunmuyorsa /var/www/html/fish/index.php dosyasını sunmaya çalışmasına sebep olacaktır.
Bu dosyaların ikisi de bulunmuyorsa sonraki adım, mod_autoindex yüklü ve uygun şekilde yapılandırılmışsa bir dizin içeriği dosyası sağlamaya çalışmak olacaktır.
httpd 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.
Belge Kök Dizini Dışındaki Dosyalar
Bazen dosya sisteminde doğrudan DocumentRoot altında bulunmayan dosyalara da erişim izni vermek gerekir. httpd’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 httpd 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://example.com/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://example.com/~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ı.
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://example.com/~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://example.com/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/$3"
URL Yönlendirme
Yukarıdaki bölümlerde açıklanan yapılandırma yönergeleri httpd’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://example.com/bar/"
Bu atama sayesinde /foo/ ile başlayan URL yolları example.com 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.
httpd 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://example.com/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.example.com/ilksayfa.html"
Karşı Vekil
httpd 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.example.com üzerindeki /bar/ dizininden alıp istemciye yerel sunucudan geliyormuş gibi sunmaktadır:
ProxyPass "/foo/" "http://dahili.example.com/bar/"
ProxyPassReverse "/foo/" "http://dahili.example.com/bar/"
ProxyPassReverseCookieDomain dahili.example.com harici.example.com
ProxyPassReverseCookiePath "/foo/" "/bar/"
ProxyPass sunucuyu uygun belgeleri alması için yapılandırırken ProxyPassReverse yönergesi dahili.example.com 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.example.com’u ismiyle hedef alan mutlak hiperbağlar varsa bunlar istemci tarafından vekil sunucudan değil doğrudan dahili.example.com’dan istenecektir. Bir sayfanın içindeki bu bağları (ve diğer içeriği) mod_substitute modülü kullanılarak istemciye sunuluyormuşçasına değiştirebilirsiniz.
Substitute "s/dahili\.example\.com/harici.example.com/i"
HTML ve XHTML’de hiperbağları daha bilgece yeniden yazabilen mod_proxy_html modülü de kullanılabilir. Yeniden yazılması gereken URL eşlemlerini oluşturmanızı sağlar, böylece karmaşık vekil senaryoları oluşturulabilir.
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 ayrıntılı olarak mod_rewrite belgelerinde bulunmaktadır.
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 httpd mod_speling (sic) adında bir modülle gelir. Bu modül etkin kılındığında htpd, "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.
mod_dir modülü sanal URI'leri, onları sunan gerçek kaynağa eşlemekte kullanılan FallbackResource yönergesini içerir. Bir 'ön denetleyici' gerçeklerken mod_rewrite modülünün kullanılmasını sağlamak için çok kullanışlıdır.
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.
Diğer URL Eşleme Modülleri
URL eşlemede kullanılabilecek diğer modüller:
mod_actions - Bir isteği, özkaynağın MIME türüne veya istek yöntemine bakarak bir CGI betiğine eşler.
mod_dir - URL'yi sonlandıran bölü çizgisini index.html bir dosyaya eşler.
mod_imagemap - Bir isteği, bir HTML belge içindeki bir resme yapılan kullanıcı tıklamalarına dayanarak bir URL'ye eşler.
mod_negotiation - Dil veya içerik sıkıştırması gibi kullanıcı tercihlerine dayanarak uygun bir belgeyi seçer.
Mevcut Diller: en | fr | ja | ko | tr
Yorumlar
Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.