Apache Temel Özellikleri

AcceptFilter Yönergesi

Bu yönerge protokol türüne göre bir dinleme soketinin işletim sistemine özgü en iyilemelerini etkin kılar. İşletim sistemi çekirdeği için temel önerme veri alınıncaya kadar veya HTTP isteğinin tamamı tamponlanana kadar sunucu sürecine bir soket tahsis etmemektir. Şimdilik sadece FreeBSD’nin Kabul Süzgeçleri ve Linux’un soket seçeneklerinden TCP_DEFER_ACCEPT desteklenmektedir.

FreeBSD için öntanımlı değerler:

httpready kabul süzgeci HTTP isteklerinin tamamını işletim sistemi çekirdeği seviyesinde tamponlar. Çekirdek isteğin tamamını alır almaz sunucuya gönderir. Ayrıntılar için accf_http(9) kılavuz sayfasına bakınız. HTTPS istekleri şifrelenmiş olduğundan sadece accf_data(9) süzgeci kullanılır.

Linux’taki ön tanımlı değerler:

Linux’un TCP_DEFER_ACCEPT soket seçeneği HTTP isteklerinin tamponlanmasını desteklemez. none dahil her değer dinleyici üzerinde TCP_DEFER_ACCEPT seçeneğini etkin kılar. Daha ayrıntılı bilgi edinmek için Linux tcp(7) kılavuz sayfasına bakınız.

Argüman olarak none kullanımı o protokol için kabul süzgeçlerini iptal edecektir. Bu, nntp gibi, sunucunun baştan bir veri göndermesinin gerekli olduğu protokoller için kullanışlıdır:

AcceptPathInfo Yönergesi

Bu yönerge, istekte dosya isminden sonra (dizinde belirtilen dosya bulunmayabilir) belirtilen yol verisinin kabul edilip edilmeyeceğini denetler. Dosya isminden sonra belirtilen yol verisi PATH_INFO ortam değişkeninde betiklerin kullanımına sunulabilir.

Örneğin, içinde sadece here.html dosyası bulunan bir /test/ dizinimiz olsun. /test/here.html/more ve /test/nothere.html/more isteklerinin her ikisi de PATH_INFO değişkenine /more verisinin atanmasını sağlar.

AcceptPathInfo yönergesine atanabilecek argüman sayısı üçtür:

Off

Sadece dosya isminden sonra yol verisi bulunmayan istekler kabul edilir. Yukarıdaki örnekteki gibi /test/here.html/more şeklindeki istekler bir 404 (Nesne bulunamadı) hatasıyla sonuçlanır.

On

Mevcut bir dosyaya ait bir dosya isminden sonra bir yol verisinin de belirtildiği istekler kabul edilir. Yukarıdaki örnekteki gibi /test/here.html/more şeklindeki istekler, /test/here.html geçerli bir dosya olduğu takdirde kabul edilir.

Default

Dosya isminden sonra yol verisi belirtilen isteklerin nasıl ele alınacağı istekten sorumlu eylemci tarafından saptanır. Normal dosyalar için çekirdek eylemci öntanımlı olarak PATH_INFO isteklerini reddeder. cgi-script ve isapi-handler gibi betiklere hizmet eden eylemciler ise genellikle PATH_INFO isteklerini öntanımlı olarak kabul ederler.

AcceptPathInfo yönergesinin birincil amacı eylemcinin PATH_INFO istekleri hakkında verdiği kabul veya red kararını geçersiz kılabilmenizi sağlamaktır. Örneğin, PATH_INFO’ya dayalı olarak içerik üretmek için INCLUDES gibi bir süzgeç kullandığınız takdirde bu geçersizleştirme zorunlu olur. Normal dosyalar için çekirdek eylemci normal olarak isteği reddederdi, böyle bir durumda bir betiği etkin kılmak için aşağıdaki gibi bir yapılandırma kullanabilirsiniz:

AccessFileName Yönergesi

Belge yolu üzerindeki dizinlerde dağıtık yapılandırma dosyalarının bulunmasına izin verilmişse sunucu bir isteği işlerken önce bu dizinlerde bu yönergede belirtilmiş yapılandırma dosyasını arar. Örnek:

Sunucu, /usr/local/web/index.html belgesini döndürmeden önce,

şeklinde bir yapılandırma ile iptal edilmiş olmadıkça yönergeler için /.acl, /usr/.acl, /usr/local/.acl ve /usr/local/web/.acl dosyalarını okur.

Ayrıca bakınız:

• AllowOverride
• Yapılandırma Dosyaları
• .htaccess Dosyaları

AddDefaultCharset Yönergesi

Bu yönerge, yanıtın içerik türü text/plain veya text/html olmak şartıyla yanıta eklenecek karakter kümesini (karakter kodlamasınının ismini) belirler. Bu, asıl davranış çoğunlukla kullanıcının istemci yapılandırmasına bağlı olmakla birlikte, yanıtın gövdesinde META elemanı vasıtasıyla belirtilmiş karakter kümesini geçersiz kılar. AddDefaultCharset Off şeklinde bir atama bu işlevselliği iptal eder. AddDefaultCharset On ile bu işlevsellik etkin kılınmaktan başka iso-8859-1 karakter kümesini öntanımlı olarak yanıta eklenir. Yönergede karküm olarak belirtilecek değerler, MIME ortam türlerinde kullanmak üzere IANA’da kayıtlı karakter kümesi değerlerinden biri olmalıdır. Örnek:

AddDefaultCharset yönergesi sadece, metin kaynaklarının hepsinin aynı karakter kümesine sahip olduğu bilindiği takdirde ve her birinde ayrı ayrı karakter kümesi belirtmek çok külfetli olacaksa kullanılmalıdır. Buna bir örnek, CGI betikleri tarafından üretilmiş içeriğe sahip kaynaklara karakter kümesinin eklenmesidir; böyle kaynaklar çıktıda kullanıcı tarafından sağlanmış veri içermeleri nedeniyle karşı siteden kaynaklanan betikli saldırılardan zarar görebilir. Bununla birlikte, bir öntanımlı karakter kümesi belirtmek, tarayıcılarında “karakter kodlamasını kendiliğinden sapta” özelliğini etkin kılmış kullanıcıları korumayacağından daha iyi bir çözüm bu betikleri bu tür saldırılara karşı düzeltmek veya en iyisi silmektir.

Ayrıca bakınız:

• AddCharset

AddOutputFilterByType Yönergesi

Bu yönerge yanıtın MIME türüne bağlı olarak bir istek için belli bir çıktı süzgecini etkin kılar. Aşağıda açıklanan belli başlı sorunlardan dolayı bu yönergenin kullanımı önerilmemektedir. Aynı işlevsellik mod_filter kullanarak sağlanabilmektedir.

Aşağıdaki örnekte mod_deflate modülünce sağlanan DEFLATE süzgeci kullanılmıştır. Bu süzgeç, text/html veya text/plain olarak yaftalanmış tüm çıktıyı (ister durağan ister devingen olsun) istemciye göndermeden önce sıkıştırır.

İçeriğin birden fazla süzgeç tarafından işlenmesini isterseniz süzgeç isimlerini noktalı virgüllerle ayırarak belirtebilirsiniz. Ayrıca, bu süzgeçlerin her biri için ayrı bir AddOutputFilterByType yönergesi belirtmek de mümkündür.

Aşağıdaki yapılandırma text/html olarak yaftalanmış tüm betik çıktılarının önce INCLUDES sonra da DEFLATE süzgecinden geçirilmesine sebep olur.

Ayrıca bakınız:

• AddOutputFilter
• SetOutputFilter
• Süzgeçler

AllowEncodedSlashes Yönergesi

AllowEncodedSlashes yönergesi kodlanmış dosya yolu ayracı içeren URL’lere izin verir (/ yerine %2F ve ek olarak \ için ilgili sistemlerde %5C kullanılmış URL’ler). Normalde böyle URL’ler bir 404 (Nesne bulunamadı) hatasıyla reddedilirler.

AllowEncodedSlashes On, çoğunlukla PATH_INFO ile bir arada kullanıldığı zaman kullanışlıdır.

Ayrıca bakınız:

• AcceptPathInfo

AllowOverride Yönergesi

Sunucu AccessFileName yönergesi ile belirtildiği şekilde bir .htaccess dosyasına rastlarsa önceki yapılandırma yönergelerinin hangilerinin geçersiz kılınmak üzere bildirildiğini bilmek ister.

Yönergeye değer olarak None belirtilirse .htaccess dosyaları tamamen yok sayılır. Bu durumda, sunucu dosya sisteminde rastladığı .htaccess dosyalarını okumaya dahi çalışmayacaktır.

Bu yönergeye All değeri atanırsa, .htaccess bağlamında kullanılabilecek her yönergeye .htaccess dosyalarında izin verilir.

yönerge-türü olarak aşağıdaki yönerge grup isimlerinden biri belirtilebilir:

AuthConfig

AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require ve benzeri yetkilendirme yönergelerinin kullanımını izin verilir.

FileInfo

Belge türünü denetleyen mod_mime Add* ve Remove* yönergeleri, DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter yönergeleri ve benzerleri ile Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName belge meta veri yönergelerinin, mod_rewrite modülündeki RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule yönergelerinin ve mod_actions modülündeki Action yönergesinin kullanımına izin verilir.

Indexes

Dizin içeriğinin listelenmesini denetleyen AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName yönergelerinin ve benzerlerinin kullanımına izin verilir.

Limit

Konak erişimini denetleyen Allow, Deny ve Order yönergelerinin kullanımına izin verilir.

Options[=seçenek,...]

Dizinlere özgü özellikleri denetleyen Options ve XBitHack yönergelerinin kullanımına izin verilir. Options komutunda belirtilecek seçenekler bir eşit işaretinden sonra aralarına sadece virgül konarak (boşluksuz) belirtilebilir.

Örnek:

Bu örnekte AuthConfig ve Indexes grubundaki yönergeler bir dahili sunucu hatasına yol açmayacaktır.

Ayrıca bakınız:

• AccessFileName
• Yapılandırma Dosyaları
• .htaccess Dosyaları

AuthName Yönergesi

Bu yönerge bir dizin için yetki alanı ismi belirler. Bu alan istemciye bildirilerek kullanıcının hangi kullanıcı ismini ve parolasını kullanacağını bilmesi sağlanır. AuthName tek bir argüman alır. Bu bakımdan eğer alan ismi boşluk karakterleri içeriyorsa ismin tırnak içine alınması gerekir. Çalışması için AuthUserFile ve AuthGroupFile gibi yönergelerden başka AuthType ve Require yönergelerinin kendine eşlik etmesini gerektirir.

Örnek:

AuthName için belirtilen dizge çoğu tarayıcı tarafından parola diyaloğunda gösterilir.

Ayrıca bakınız:

• Kimlik Doğrulama, Yetkilendirme ve Erişim Denetimi

AuthType Yönergesi

Bu yönerge bir dizin için kullanıcı kimlik doğrulaması türünü belirler. Olası kimlik doğrulama türleri Basic (mod_auth_basic modülüyle sağlanır) ve Digest’tir (mod_auth_digest modülüyle sağlanır).

Kimlik doğrulamasının gerçekleşmesi için AuthName ve Require yönergelerini de kullanmalısınız. Bunlara ek olarak sunucunun mod_authn_file gibi bir kimlik doğrulayıcı modülüne ve mod_authz_user gibi bir yetkilendirme modülüne ihtiyacı vardır.

Ayrıca bakınız:

• Kimlik Doğrulama, Yetkilendirme ve Erişim Denetimi

CGIMapExtension Yönergesi

Bu yönerge Apache’inin CGI bekitlerini çalıştırmak için kullanacağı yorumlayıcıyı nasıl bulacağını denetlemek için kullanılır. Örneğin, CGIMapExtension sys:\foo.nlm .foo satırı .foo uzantılı CGI betik dosyalarının FOO yorumlayıcıya aktarılmasını sağlar.

ContentDigest Yönergesi

Bu yönerge RFC2616 ve RFC1864’te tanımlandığı gibi Content-MD5 üretimini etkin kılar.

MD5, verideki herhangi bir değişikliğin ileti özetinin değişmesi olarak yansıması nedeniyle yüksek derecede itimat sağlayan keyfi uzunlukta bir "ileti özeti" (bazen "parmakizi" dendiği de olur) hesaplama algoritmasıdır.

Content-MD5 başlığı öğe gövdesinin iki uç arasında ileti bütünlük sınamasının yapılabilmesini sağlar. Bir istemci veya vekil aktarılan öğe gövdesinde rastlantısal bir değişiklik olup olmadığını saptamak için bu başlığın doğruluğunu sınayabilir. Başlık örneği:

Her istekte ileti özeti hesaplanacağından (değerler saklanmaz), bu yönergenin sunucunuzda başarım sorunlarına yol açacağına dikkat ediniz.

Content-MD5, herhangi bir modül değil, sadece core modülü tarafından sunulan belgeler için gönderilir. Örneğin, SSI belgeleri CGI betikleri tarafından çıktılanırlar ve bayt seviyesinden çıktılar bu başlığa sahip olmazlar.

DefaultType Yönergesi

Sunucudan zaman zaman kendi MIME türü ile uyuşmayan bir belge sunması istenir.

Sunucu, belgenin içerik türünü istemciye bildirmek zorundadır. Eğer sunucu bunu normal yollardan saptayamazsa içerik türü olarak DefaultType ile belirtilen değeri gönderir. Örneğin, GIF dosyaları bulunan bir dizinde .gif uzantısına sahip olmayan dosyaların da bulunması durumunda, bu dizin için,

belirtilmesi uygun olurdu.

İçerik türünün ne sunucu ne de yönetici (örneğin, vekil) tarafından saptanabildiği durumlarda MIME türünün yanlış belirtilmesindense tür belirtmemek tercih edilebilir. Bu, şöyle yapılabilir:

DefaultType None sadece httpd-2.2.7 ve sonrasında mevcuttur.

Bu yönergenin sadece öntanımlı MIME-türünü sağlaması nedeniyle ForceType yönergesinden farklı olduğuna dikkat ediniz. Dosya ismi uzantıları dahil, tüm diğer MIME-türü tanımları ortam türünü tanımladığı noktada bu öntanımlı türü sunulan veri için geçersiz kılacaktır.

<Directory> Yönergesi

<Directory> ve </Directory> sadece ismi belirtilen dosya sistemi dizininde ve bunun altdizinlerinde uygulanacak bir yönerge grubunu sarmalamakta kullanılır. Bir dizin bağlamında kullanılabilecek her yönergeye izin verilir. dizin-yolu bir dizinin tam yolu olabileceği gibi Unix kabuk tarzı bir dosya ismi eşleştirme kalıbı da olabilir. Kalıp dizgesinde, ? herhangi bir tek karakterle, * herhangi bir karakter dizisiyle eşleşir. Ayrıca [] karakter aralıkları da kullanılabilir. ‘/’ karakteri ile hiçbir kalıp karakteri eşleşmez, bu bakımdan <Directory /*/public_html> ile /home/user/public_html değil, ama <Directory /home/*/public_html> eşleşecektir. Örnek:

~ karakterine ek olarak düzenli ifadeler de kullanılabilir. Örnek:

yönergesi /www/ içindeki üç rakamdan oluşan dizinlerle eşleşecektir.

Eğer çok sayıda (düzenli ifade olmayan) <Directory> bölümü, bir dosyayı içeren bir dizinle veya üst dizinlerinden biri ile eşleşiyorsa, uygulama en kısa eşleşmedeki yönergelerden başlayarak .htaccess dosyalarındaki yönergelere kadar genişletilir. Örneğin,

bölümleri ile /home/web/dir/doc.html belgesine erişirken şu aşamalardan geçilir:

• AllowOverride None yönergesi uygulanır (.htaccess dosyaları iptal edilir).
• AllowOverride FileInfo yönergesi uygulanır (/home dizini için).
• Sırayla /home/.htaccess, /home/web/.htaccess ve /home/web/dir/.htaccess dosyaları içindeki FileInfo yönergeleri uygulanır.

Normal bölümlerin tamamı uygulanıncaya kadar düzenli ifadeler değerlendirilmez. Düzenli ifadelerin tamamı yapılandırma dosyasında görüldükleri sıraya göre sınanırlar. Örneğin,

düzenli ifadeli bölümü, tüm normal <Directory> bölümleri ve .htaccess dosyaları uygulanıncaya kadar değerlendirilmeyecektir. Düzenli ifadeleri değerlendirmeye sıra gelince düzenli ifade /home/abc/public_html/abc ile eşleştirilecek ve buna ilişkin <Directory> uygulanacaktır.

<Directory /> için öntanımlı Apache erişiminin Allow from All oluşuna dikkat ediniz. Bunu şöyle bir blokla değiştirmeniz,

ve erişilebilir olmasını istediğiniz dizinleri ayrıca belirtmeniz önerilir. Daha ayrıntılı bilgi edinmek için Güvenlik İpuçları belgesine bakınız.

Dizin bölümleri httpd.conf dosyasında yer alır. <Directory> yönergeleri iç içe olamazlar ve bir <Limit> veya <LimitExcept> bölümü içinde bulunamazlar.

Ayrıca bakınız:

• Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının anlatıldığı <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine de bakınız.

<DirectoryMatch> Yönergesi

<DirectoryMatch> and </DirectoryMatch> yönergeleri <Directory> gibi sadece ismi belirtilen dosya sistemi dizininde ve bunun altdizinlerinde uygulanacak bir yönerge grubunu sarmalamakta kullanılır. Tek farkla argüman olarak bir düzenli ifade alır. Örnek:

yönergesi /www/ içindeki üç rakamdan oluşan dizinlerle eşleşecektir.

Ayrıca bakınız:

• Normal <Directory> bölümlerindeki yönergelerle düzenli ifadelerin nasıl karıştırıldığının bir açıklaması için <Directory> yönergesine bakınız.
• Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

DocumentRoot Yönergesi

Bu yönerge httpd tarafından dosyalarının sunulacağı dizini belirler. Alias benzeri bir yönerge ile eşleşmedikçe, sunucu istenen URL’deki yolu, belge yolu haline getirmek için belge kök dizinine ekler. Örnek:

yapılandırması ile http://www.my.host.com/index.html isteği /usr/web/index.html ile eşleştirilir. dizin-yolu ile göreli dosya yolu belirtildiği takdirde belge kök dizininin ServerRoot ile belirtilen sunucu kök dizinine göre belirtildiği varsayılır.

DocumentRoot ile belirtilen dizin bir bölü çizgisi ile bitirilmemelidir.

Ayrıca bakınız:

• URL’lerin Dosya Sistemi ile Eşlenmesi

EnableMMAP Yönergesi

Bu yönerge, sunucunun teslimat sırasında gerektiği takdirde bir dosya içeriğinin okunması için bellek eşleme kullanıp kullanmayacağını belirler. Öntanımlı olarak, bir isteğin yerine getirilmesi, mod_include kullanarak sunucu tarafından çözümlenen bir dosyanın teslimatı sırasında olduğu gibi, bir dosya içindeki veriye erişilmesini gerektirdiğinde Apache, işletim sistemi tarafından desteklendiği takdirde dosyayı belleğe eşler.

Böyle bellek eşleme kimi zaman başarım artışını beraberinde getirirse de bazen sorunlardan kaçınmak için bellek eşlemeyi kapatmak daha iyi sonuç verir:

• Bazı çok işlemcili sistemlerde bellek eşleme httpd’nin başarımını düşürebilmektedir.
• DocumentRoot NFS gibi bir ağ dosya sistemi üzerinde ise ağ kopması sonucunda, bir dosyanın silinmesi veya dosya okuma işleminin kesilmesi durumunda httpd parçalama arızası vererek çökebilir.

Bu tür sorunlardan dolayı zarar görülebilecek sunucu yapılandırmalarında dosya teslimatında bellek eşlemlerinin kullanımını şu şekilde iptal etmeniz gerekir:

Bu özellik, sadece NFS dosya sistemi üzerinde sunulan dosyaları kapsamak üzere şu şekilde kolayca kapatılabilir:

EnableSendfile Yönergesi

Bu yönerge, dosya içeriğinin istemciye teslimi için httpd’nin çekirdeğin dosya gönderme desteğini kullanıp kullanmayacağını belirler. Öntanımlı olarak, bir isteğin yerine getirilmesi, bir durağan dosyanın teslimatı sırasında olduğu gibi, bir dosya içindeki veriye erişilmesini gerektirmediği takdirde Apache, işletim sistemi tarafından destekleniyorsa dosyayı istemciye teslim etmek için çekirdeğin dosya gönderme özelliğini kullanır.

Çekirdeğin dosya gönderme mekanizması, okuma, gönderme ve tampon ayırma işlemlerini ayrı ayrı yapmaktan kaçınır. Fakat bazı platformlarda veya bazı dosya sistemlerinde aşağıda belirtilen işlemsel sorunlardan kaçınmak için bu özelliği iptal etmek daha iyidir:

• Bazı platformlar, derleme sistemince saptanamayan bozuk bir dosya gönderme desteğine sahiptir; özellikle eğer derleme işlemi dosya gönderme desteğinde sorun olmayan bir makinede yapılıp çalıştırılabilir dosyaların sorunlu makineye kurulduğu durumda bu saptama yapılamayacaktır.
• Linux’ta IPv6 kullanırken dosya gönderme desteği bazı ağ kartlarındaki TCP toplama sağlaması aktarım hatasını tetikler.
• Itanium üzerinde çalışan Linux’ta dosya gönderme desteği 2GB’tan büyük dosyalarla çalışamamaktadır.
• DocumentRoot ağ dosya sistemi (NFS veya SMB gibi) üzerinde olduğu durumda çekirdek ağ dosyalarını kendi arabelleği üzerinden sunamayabilir.

Bu sorunlardan muzdarip sunucu yapılandırmaları için bu özelliği şöyle iptal edebilirsiniz:

Bu özellik, sadece bir NFS veya SMB dosya sistemi üzerinde sunulan dosyaları kapsamak üzere şu şekilde kolayca kapatılabilir:

ErrorDocument Yönergesi

Bir sorun çıktığında veya hata oluştuğunda Apache şu dört işlemden birini yapacak şekilde yapılandırılabilir:

1. Yerleşik bir hata iletisi çıktılanır.
2. Özel bir ileti çıktılanır.
3. Sorunu/hatayı işleyecek yerel bir URL-yoluna yönlendirme yapılır.
4. Sorunu/hatayı işleyecek harici bir URL-yoluna yönlendirme yapılır.

İlk seçenek öntanımlıdır. Diğer üç seçenek ErrorDocument yönergesinin argümanları (hata kodundan sonra bir URL veya hata iletisi) ile belirtilir. Apache bazı durumlarda sorun/hata ile ilgili ek bilgi verecektir.

URL’ler yerel yollarda (DocumentRoot’a göre) bir bölü çizgisi (/) ile başlatılabileceği gibi istemci tarafından çözümlenecek tam bir URL şeklinde de belirtilebilir. Bunlar yerine, tarayıcıda gösterilmek üzere bir ileti de belirtilebilir. Örnekler:

Bunlardan başka, Apache’nin kendi hata iletilerinin kullanılacağı özel default değeri ile belirtilebilir. Normal şartlar altında gerekmese de, bir şey belirtilmediği takdirde mevcut bir ErrorDocument yönergesini miras alan yapılandırmalarda Apache’nin kendi hata iletilerinin kullanımı default değeri açıkça belirtilerek örnekteki gibi zorlanabilir:

ErrorDocument yönergesinde bir uzak URL (önünde http bulunan bir yol) belirtildiğinde, belge aynı sunucuda olsa bile, Apache’nin istemciye belgeyi bulacağı yer için bir yönlendirme göndereceğine dikkat ediniz. Bunun bazı istenmeyen etkileri vardır; en önemlilerinden biri istemcinin hata kodu yerine bir yönlendirme durum kodu alacak olmasıdır. Bu, bir URL’nin geçerliliğini durum koduna göre saptayan istemciler veya robotlar için yanıltıcı olacaktır. Buna ek olarak, ErrorDocument 401 için bir uzak URL belirttiğiniz durumda istemci 401 durum kodunu almayacağı için kullanıcıdan parola isteğinde bulunamayacaktır. Bu bakımdan, ihtiyaç duyduğunuz takdirde, ErrorDocument 401 yönergesine yerel bir belge belirtmelisiniz.

Sunucunun ürettiği hata iletileri "çok kısa" olduğu takdirde, Microsoft Internet Explorer (MSIE) öntanımlı olarak bu hata iletilerini yoksayar ve bunun yerine kendi "kullanıcı dostu" hata iletilerini kullanır. "Çok kısa" eşiği duruma göre değişmekle birlikte, genellikle, hata iletileriniz 512 bayttan büyük olduğu takdirde MSIE kendi hata iletileri yerine sunucunun ürettiği hata iletilerini gösterecektir. Bu konuda daha fazla bilgiyi Q294807 kodlu Microsoft Knowledge Base makalesinde bulabilirsiniz.

Çoğu yerleşik hata iletisi özel iletilerle değiştirilebilse de bazı durumlarda ErrorDocument ile ne belirtildiğine bakılmaksızın yerleşik hata iletileri kullanılır. Özellikle, bozuk bir istek saptandığında normal istek işleme hemen devre dışı bırakılır ve yerleşik hata iletisi döndürülür. Bu, hatalı istekler yaparak güvenlik sorunlarına yol açılmak istenmesi durumlarında gereklidir.

2.0 öncesi sürümlerde iletiler bir çift çift-tırnak içine alınmayıp, tek bir çift-tırnak ile başlatılması yeterli olurdu.

Ayrıca bakınız:

• Özel Hata Yanıtları

ErrorLog Yönergesi

ErrorLog yönergesi sunucunun saptadığı hataları kaydedeceği dosyanın ismini belirtmek için kullanılır. dosya-yolu ile göreli dosya yolu belirtildiği takdirde dizininin ServerRoot ile belirtilen sunucu kök dizinine göre belirtildiği varsayılır.

dosya-yolu bir boru imi (|) ile başlatıldığı takdirde hata iletilerinin hata günlüğünü işleme sokacak komuta borulanacağı varsayılır.

Dosya adı yerine syslog kullanılırsa, sistem desteklediği takdirde günlük kaydı syslogd(8) üzerinden yürütülür. Öntanımlı olarak local7 syslog oluşumu kullanılır. Bunu syslog:oluşum sözdizimini kullanarak değiştirebilirsiniz. Buradaki oluşum syslog.conf(5) kılavuz sayfasında belirtilen oluşum isimlerinden biri olabilir.

GÜVENLİK: Günlük dosyalarının saklandığı dizin, sunucuyu başlatan kullanıcı dışındakiler tarafından yazılabilir olduğu takdirde güvenliğinizin nasıl tehlikeye gireceği güvenlik ipuçları belgesinde ayrıntılı olarak açıklanmıştır.

Ayrıca bakınız:

• LogLevel
• Apache Günlük Dosyaları

FileETag Yönergesi

FileETag yönergesi, belge bir dosyaya dayandığı takdirde ETag (Entity Tag - öğe etiketi kısaltması) yanıt başlığı alanını oluşturmakta kullanılacak dosya özniteliklerini yapılandırır. (ETag değeri, ağ band genişliğinden kazanmak için arabellek yönetiminde kullanılır.) Apache 1.3.22 ve öncesinde ETag değeri daima dosyanın düğümü, boyutu ve son değişiklik zamanından (mtime) oluşurdu. FileETag yönergesi ne kullanılması gerektiğini belirleyebilmenizi sağlar. Değer olarak belirtilebilecek anahtar sözcükler şunlardır:

INode

Dosyanın düğüm numarası hesaba katılır.

MTime

Dosyanın son değişiklik tarih ve saati dahil edilir.

Size

Dosyanın bayt cinsinden uzunluğu dahil edilir.

All

Olası tüm alanlar kullanılır. Bu şuna eşdeğerdir:

FileETag INode MTime Size

None

Bir belge dosyasıyla sunulsa bile yanıta hiçbir ETag alanı dahil edilmez.

Öntanımlı ayarları miras alıp bunların kapsamını genişletmek/daraltmak için INode, MTime ve Size anahtar sözcüklerinin önüne + veya - imi konabilir. Bu imlerin bulunmadığı bir anahtar sözcüğün varlığı halinde hiçbir değer miras alınmaz.

Eğer bir dizinin yapılandırması FileETag INode MTime Size ve alt dizini FileETag -INode içeriyorsa bu alt dizinin (ve bir geçersizleştirme olmadığı takdirde onun alt dizinlerinin) ayarları FileETag MTime Size yapılandırmasına eşdeğer olacaktır.

<Files> Yönergesi

<Files> yönergesi, içerdiği yönergelerin etki alanını dosya isimlerine göre sınırlandırır. <Directory> ve <Location> bölümleri ile karşılaştırılabilir. Bir </Files> yönergesi ile sonlandırılması gerekir. Bu bölüm içinde belirtilen yönergeler, <Files> yönergesinde belirtilen dosya-adı’nın son bileşeniyle (dizinler atıldıktan sonda kalan dosya ismi) eşleşen nesnelere uygulanır. <Files> bölümleri yapılandırma dosyasında, <Directory> bölümleri ve .htaccess dosyaları okunduktan sonra fakat <Location> yönergelerinden önce göründükleri sıraya göre işleme sokulurlar. <Files> bölümlerinin <Directory> bölümlerinin içinde uygulama alanını sınırlamak amacıyla kullanılabileceğine dikkat ediniz.

dosya-adı argümanının bir dosya ismi veya bir dosya ismi kalıbı içermesi gerekir. Bir dosya ismi kalıbındaki her ? imi bir karakterle eşleştirilirken * imi karakter dizileri ile eşleştirilir. ~ imine ek olarak düzenli ifadeler de kullanılabilir. Örneğin

satırı en bilinen resim dosyası biçimleriyle eşleşecektir. Bunun yerine <FilesMatch> yönergesi de tercih edilebilirdi.

<Directory> ve <Location> bölümlerinin aksine, <Files> bölümleri .htaccess dosyaları içinde kullanılabilir. Bu sayede kullanıcıların kendi dosyalarına erişimi dosya seviyesinde denetlemelerine imkan sağlanmış olur.

Ayrıca bakınız:

• Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

<FilesMatch> Yönergesi

<FilesMatch> yönergesi, içerdiği yönergelerin etki alanını <Files> yönergesinin yaptığı gibi dosya isimlerine göre sınırlandırır. Ancak, argüman olarak bir düzenli ifade kabul eder. Örneğin

satırı en bilinen resim dosyası biçimleriyle eşleşecektir.

Ayrıca bakınız:

• Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

ForceType Yönergesi

Bu yönerge, bir .htaccess dosyası veya bir <Directory>, <Location> veya <Files> bölümüne yerleştirildiği zaman, eşleşen tüm dosyaların MIME-türü ile belirtilen içerik türüyle sunulmasına sebep olur. Örneğin, altında sadece GIF dosyaları bulunan bir dizininiz varsa ve bunlara tek tek .gif uzantısı belirtmek istemiyorsanız şu yapılandırmayı kullanabilirsiniz:

DefaultType yönergesinin tersine bu yönerge ortam türünü betimleyen tüm MIME-türü tanımlarını geçersiz kılar.

Mevcut ForceType ayarlarını None değeriyle geçersiz kılabilirsiniz:

HostnameLookups Yönergesi

Bu yönerge oturum açabilecek konak isimlerini tespit edebilmek için DNS sorgularını etkin kılar (ve sonuç REMOTE_HOST’ta belirtilerek CGI/SSI’lere aktarılır). Double değeri sorgunun çift yönlü yapılacağını belirtir. Yani, bir tersine sorgunun ardından bir normal sorgu yapılır. Normal sorguda elde edilen IP adreslerinden birinin istek yapan IP adresi ile eşleşmesi gerekir. ("tcpwrappers" terminolojisinde buna PARANOID adı verilir.)

Konak ismine göre erişimi denetlemek için mod_authz_host kullanıldığında, nasıl bir ayar yapıldığına bakılmaksızın, çift yönlü sorgulama yapılır. Bu güvenlik için gereklidir. Bunun dışında açıkça HostnameLookups Double belirtilmedikçe genellikle çift yönlü sorgulama yapılmaz. Örneğin, sadece HostnameLookups On belirtilmiş ve konak ismi kısıtlamalarıyla korunmuş bir nesne için bir istek yapılmışsa çift yönlü sorgunun başarısına bakılmaksızın CGI’lere REMOTE_HOST olarak tek yönlü sorgu sonucu aktarılır.

Gerçekte ters yönlü sorguya gerek duyulmayan sitelerde ağ trafiğini yormamak için Off, öntanımlı değerdir. Ayrıca, son kullanıcıların DNS sorguları nedeniyle gereksiz yere bir beklemeye maruz kalmaması için de bu daha iyidir. Yükü zaten ağır olan sitelerde, DNS sorgularının görece uzun zaman alması nedeniyle bu yönergenin değeri Off olarak bırakılmalıdır. Öntanımlı olarak kurulum dizininizin bin alt dizinine kurulan logresolve uygulaması kullanılarak oturum açan IP adresleri için isim sorguları çevrim dışıyken yapılabilir.

<IfDefine> Yönergesi

<IfDefine sınama>...</IfDefine> bölümü koşullu olarak işleme sokulacak yönergeleri içerir. Bir <IfDefine> bölümü içindeki yönergeler sadece sınama doğru sonuç verirse işleme sokulur. Aksi takdirde, bölüm içinde kalan her şey yok sayılır.

<IfDefine> bölüm yönergesinde sınama için belirtilebilecek iki biçim vardır:

• parametre-adı
• !parametre-adı

Birinci durumda bölüm içinde kalan yönergeler sadece parametre-adı ile belirtilen parametre tanımlı ise işleme sokulur. İkinci durumda ise tersi yapılır, yani sadece parametre-adı ile belirtilen parametre tanımlı değil ise yönergeler işleme sokulur.

parametre-adı argümanı sunucu başlatılırken httpd komut satırında -Dparametre ile belirtilerek tanımlı hale getirilebilir.

<IfDefine> bölümleri iç içe olabilir, dolayısıyla çok parametreli basit sınamalar gerçeklenebilir. Örnek:

<IfModule> Yönergesi

<IfModule sınama>...</IfModule> bölümü belli bir modülün varlığına veya yokluğuna göre işleme sokulacak yönergeleri içerir. Bir <IfModule> bölümü içindeki yönergeler sadece sınama doğru sonuç verirse işleme sokulur. Aksi takdirde, bölüm içinde kalan her şey yok sayılır.

<IfModule> bölüm yönergesinde sınama için belirtilebilecek iki biçim vardır:

• modül
• !modül

Birinci durumda bölüm içinde kalan yönergeler sadece modül ile belirtilen modül Apache içine dahil edilmişse veya LoadModule yönergesi ile devingen olarak yüklenmişse işleme sokulur. İkinci durumda ise tersi yapılır, yani sadece modül içerilmiş değil ise yönergeler işleme sokulur.

modül argümanında bir modül betimleyici veya modülün derleme sırasındaki dosya adı belirtilebilir. Örneğin, rewrite_module bir betimleyici, mod_rewrite.c ise bir dosya ismidir. Eğer modül çok sayıda kaynak dosyasından oluşuyorsa STANDARD20_MODULE_STUFF dizgesini içeren dosyanın ismi kullanılır.

<IfModule> bölümleri iç içe olabilir, dolayısıyla çok parametreli basit sınamalar gerçeklenebilir.

Include Yönergesi

Bu yönerge sunucu yapılandırma dosyalarının başka dosyaları içermesini mümkün kılar.

Çok sayıda dosyayı bir kerede alfabetik sırada içermek için kabuk tarzı (fnmatch()) dosya ismi kalıp karakterleri kullanılabilir. Ayrıca, eğer Include yönergesi bir dosya değil de bir dizin gösteriyorsa Apache bu dizindeki ve alt dizinlerindeki bütün dosyaları okuyacaktır. Fakat dizinin bir bütün olarak okutulması önerilmez, çünkü dizinde httpd programının çökmesine sebep olabilecek geçici dosyalar unutulabilir.

Dosya yolu mutlak bir dosya yolu olarak belirtilebileceği gibi ServerRoot dizinine göreli olarak da belirtilebilir.

Örnekler:

Veya dizinler ServerRoot dizinine göre belirtilebilir:

Ayrıca bakınız:

• apachectl

KeepAlive Yönergesi

Keep-Alive yönergesi HTTP/1.0 protokolüne bir eklenti olup HTTP/1.1 protokolünün kalıcı bağlantı özelliği aynı TCP bağlantısı üzerinden çok sayıda isteğin gönderilmesini mümkün kılan uzun süreli HTTP oturumları açılmasını sağlar. Bunun, çok sayıda resim içeren HTML belgelerin yanıt zamanlarında bazı durumlarda %50’lik bir hızlanmayla sonuçlandığı gösterilmiştir. Kalıcı bağlantıları etkin kılmak için yönerge KeepAlive On şeklinde kullanılır.

HTTP/1.0 istemcileri için kalıcı bağlantılar sadece bir istemci tarafından özellikle istendiği takdirde kullanılabilir. Ek olarak, HTTP/1.0 istemci kalıcı bağlantıları sadece içerik uzunluğu baştan bilindiği zaman kullanılabilir. Bu, CGI çıktısı, SSI sayfaları ve sunucunun ürettiği dizin listeleri gibi genellikle HTTP/1.0 istemcilere kalıcı bağlantılar kullanmayan devingen içeriklere uygulanır. HTTP/1.1 istemciler için kalıcı bağlantılar aksi belirtilmedikçe öntanımlıdır. İstemci istediği takdirde, uzunluğu bilinmeyen içerik kalıcı bağlantılar üzerinden gönderilirken parçalı kodlama kullanılacaktır.

Bir istemci kalıcı bağlantı kullandığı takdirde, bağlantı üzerinden kaç istek gönderilirse gönderilsin, MaxRequestsPerChild yönergesi bakımından tek bir istek olarak değerlendirilir.

Ayrıca bakınız:

• MaxKeepAliveRequests

KeepAliveTimeout Yönergesi

Sunucunun kalıcı bir bağlantıyı kapatmadan önce bir sonraki isteği kaç saniye bekleyeceğini belirler. İstek alındıktan sonra Timeout yönergesiyle belirtilen zaman aşımı değeri uygulanır.

KeepAliveTimeout için yüksek bir değer belirtmek ağır yüklü sunucularda başarım sorunlarına yol açar. Daha yüksek bir zaman aşımı, boştaki istemcilerin bulunduğu bağlantıları bekleyen daha fazla sunucu sürecini meşgul edecektir.

İsme dayalı sanal konak bağlamında, NameVirtualHost bölümleri içinde tanımlanmış ilk sanal konağın (öntanımlı konak) değeri kullanılır. Diğer değerler görmezden gelinir.

<Limit> Yönergesi

Erişim denetleyicileri normalde tüm erişim yöntemleri için etkindir ve olağan olanı da budur. Genel durum olarak, erişim denetim yönergeleri bir <Limit> bölümüne yerleştirilmemelidir.

<Limit> bölümünün amacı, erişim denetleyicilerinin etkilerini belli HTTP yöntemleri için sınırlamaktır. <Limit> bölümü içinde listelenen erişim sınırlamaları, kalan tüm diğer yöntemler için etkisiz olacaktır. Aşağıdaki örnekte, erişim sınırlaması POST, PUT ve DELETE yöntemleri için uygulanmakta, diğer tüm yöntemler korumasız bırakılmaktadır:

Birden fazla bölümde kullanılabilecek yöntem isimleri: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK ve UNLOCK. Yöntem isimleri harf büyüklüğüne duyarlıdır. GET yöntemi sınırlanırsa HEAD istekleri de sınırlanmış olur. TRACE yöntemi sınırlanamaz.

<LimitExcept> Yönergesi

<LimitExcept> ve </LimitExcept> argüman olarak belirtilenler dışında kalan HTTP yöntemleri için kullanılacak erişim sınırlayıcıları gruplamakta kullanılır. Yani, <Limit> bölümünün tersine, standart olsun olmasın bütün yöntemler için erişimi kısıtlamakta kullanılabilir. Daha ayrıntılı bilgi edinmek için <Limit> yönergesinin açıklamasına bakınız.

Örnek:

LimitInternalRecursion Yönergesi

Örneğin, özgün istekleri dahili olarak bir CGI betiğine yönlendiren Action yönergesi kullanıldığında bir dahili yönlendirme oluşur. İstek içi istekler ise bazı URI’ler için istek yapıldığında ne olacağını bulmak için Apache’nin kullandığı bir mekanizmadır. Örneğin, mod_dir, DirectoryIndex yönergesinde listelenen dosyalara bakmak için istek içi istekler kullanır.

LimitInternalRecursion yönergesi sunucunun dahili yönlendirmeler ve istek içi isteklerin oluşturduğu döngülerden dolayı çökmemesini sağlar. Böyle döngüler genellikle yanlış yapılandırma sonucu ortaya çıkarlar.

Yönerge her istek için değerlendirmeye alınacak iki farklı sınırlama için kullanılabilir. İlk sayı ardarda gelebilen dahili yönlendirmelerin azami sayısını, ikinci sayı ise istek içi isteklerin ne kadar iç içe olabileceğini belirler. Tek bir sayı belirtilirse iki sınırlama için de aynı değer kullanılır.

LimitRequestBody Yönergesi

Bu yönerge, bir istek gövdesinde izin verilen bayt sayısını 0 (sınırsız anlamında) ile 2147483647 (2GB) arasında sınırlamak için kullanılır.

LimitRequestBody yönergesi kullanıcıya yönergenin kullanıldığı bağlam (sunucu, belli bir dizin, belli bir dosya, belli bir yer) dahilinde bir HTTP istek iletisi gövdesinin izin verilen uzunluğu için bir sınır belirleme imkanı verir. Eğer istemcinin isteği bu sınırı aşarsa sunucu isteği sunmak yerine bir hata iletisi döndürecektir. Normal bir istek ileti gövdesinin uzunluğu büyük oranda özkaynağın doğasına ve bu özkaynak üzerinde izin verilen yöntemlere bağlıdır. CGI betikleri genellikle ileti gövdesini form bilgisini almak için kullanır. PUT yöntemi gerçeklenimleri, en azından, sunucunun o özkaynak için kabul etmek isteyeceği herhangi bir gösterim kadar büyük bir değer gerektirecektir.

Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim imkanı sağlar.

Eğer, örneğin, belli bir yere dosya yükleme izni verir ve buraya yüklenebilecek dosya boyutunu 100 kB ile sınırlamak isterseniz yönergeyi şöyle kullanabilirsiniz:

LimitRequestFields Yönergesi

sayı, en küçük 0 (sınırsız anlamında), en büyük 32767 olabilir. Öntanımlı değer bir derleme zamanı sabiti olan DEFAULT_LIMIT_REQUEST_FIELDS ile belirlenir (dağıtımla gelen değeri 100’dür).

LimitRequestFields yönergesi sunucu yöneticilerine bir HTTP isteğinde izin verilen istek başlık alanlarının sayısı üzerindeki sınırı değiştirebilme imkanı verir. Sunucu bu değerin, normal bir istemci isteğinin içerebileceği alan sayısından daha büyük olmasına ihtiyaç duyar. Bir istemci tarafından kullanılan istek başlık alanlarının sayısı nadiren 20’yi geçer, fakat bu farklı istemci gerçeklenimleri için değişiklik gösterir ve çoğunlukla kullanıcının tarayıcısını ayrıntılı içerik müzakeresini desteklemek için nasıl yapılandırdığıyla ilgilidir. İsteğe bağlı HTTP eklentileri çoğunlukla istek başlık alanları kullanılarak ifade edilir.

Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim imkanı sağlar. Eğer normal istemciler sunucudan istekte bulunurken çok fazla başlık alanı gönderildiğine dair bir hata iletisi alırlarsa bu değerin arttırılması gerekir.

Örnek:

LimitRequestFieldSize Yönergesi

Bu yönerge, HTTP istek başlığında izin verilecek bayt sayısını belirler.

LimitRequestFieldSize yönergesi, sunucu yöneticilerine HTTP istek başlık alanının azami uzunluğunu arttırıp azaltma imkanı verir. Sunucu bu değerin, normal bir istemci isteğinin içerebileceği herhangi bir başlık alanını tutabilecek kadar büyük olmasını gerektirir. Normal bir istek başlık alanı uzunluğu kullanıcının tarayıcısını ayrıntılı içerik müzakeresini desteklemek için nasıl yapılandırdığıyla ilgilidir. SPNEGO kimlik doğrulama başlıkları 12392 baytlık olabilir.

Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim imkanı sağlar.

Örnek:

LimitRequestLine Yönergesi

Bu yönerge, HTTP istek satırında izin verilecek bayt sayısını belirler.

LimitRequestLine yönergesi, sunucu yöneticilerine bir istemcinin HTTP istek satırının azami uzunluğunu arttırıp azaltma imkanı verir. İstek satırının içeriği HTTP yöntemi, URI ve protokol sürümünden oluştuğundan LimitRequestLine yönergesi, sunucudan bir istek için kullanılan istek adresinin uzunluğunu sınırlamış olur. Sunucu bu değerin, bir GET isteğinin sorgu kısmında aktarılabilen her bilgi dahil, özkaynak isimlerinden her birini tutabilecek kadar büyük olmasını gerektirir.

Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim imkanı sağlar.

Örnek:

LimitXMLRequestBody Yönergesi

Bir XML temelli istek gövdesinin azami bayt sayısını belirler. Değer olarak 0 belirtildiğinde herhangi bir boyut sınaması yapılmaz.

Örnek:

<Location> Yönergesi

<Location> bölüm yönergesi kapsadığı yönergelerin etki alanını belirtilen URL’lerle sınırlar. Bu yönerge, <Directory> yönergesine benzer ve </Location> yönergesi ile biten bir alt bölüm başlatır. <Location> bölümleri yapılandırma dosyasında göründükleri sıraya göre, <Directory> bölümleri ve .htaccess dosyaları okunup <Files> bölümleri de işlendikten sonra işleme sokulurlar.

<Location> bölümleri dosya sisteminin tamamen dışında işlem görürler. Bunun çeşitli sonuçları olur. En önemlisi, <Location> yönergelerinin dosya sistemi konumlarına erişimi denetim altına almak için kullanılmaması gerekliliğidir. Aynı dosya sistemi konumuna farklı URL’lerle erişmek mümkün olduğundan bu tür erişim denetimleri hile ile atlatılabilir olacaktır.

Kaynağa yapılan (vekil olmayan) tüm istekler için eşleşecek URL, /yol/ şeklinde bir URL yolu olmalı; ne şema, ne konak ismi ne port ne de sorgu dizgesi içermelidir. Vekil istekleri için eşleşecek URL ise şema://sunucuadı/dosya-yolu şeklinde olmalı ve önek içermelidir.

URL içinde dosya kalıp karakterleri kullanılabilir. Dosya kalıp karakterleri bulunan bir dizgede bulunan ? karakteri herhangi bir tek karakterle eşleşirken * karakteri herhangi bir karakter dizisi ile eşleşecektir. URL yolu içindeki / karakterleri ile hiçbir dosya kalıp karakteri eşleşmez.

Ayrıca, ~ karakteri eşliğinde düzenli ifadeler de kullanılabilir. Örneğin,

yönergesi /ek/veri ve /hususi/veri alt dizgeleriyle eşleşecektir. <LocationMatch> yönergesi <Location> yönergesinin düzenli ifade sürümüne eşdeğer davranır.

<Location> işlevselliği özellikle SetHandler yönergesi ile birlikte kullanışlı olur. Örneğin, durum isteklerini etkin kılmak ama sadece mesela.dom’dan gelen isteklere izin vermek için şöyle bir uygulama yapabilirsiniz:

Ayrıca bakınız:

• Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

<LocationMatch> Yönergesi

<LocationMatch> yönergesi içerdiği yönergelerin etki alanını <Location> yönergesinin yaptığı gibi belirtilen URL’lerle sınırlar. Ancak argüman olarak basit bir dizge değil bir düzenli ifade alır. Örneğin,

yönergesi /ek/veri ve /hususi/veri alt dizgeleriyle eşleşecektir.

Ayrıca bakınız:

• Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

LogLevel Yönergesi

LogLevel yönergesi hata günlüklerine kaydedilen hata iletilerinde hangi ayrıntılara yer verileceğini belirler (ErrorLog yönergesine bakınız). En yüksek önem derecesinden başlayarak olası seviye değerleri aşağıda sıralanmıştır: