Apache Temel Özellikleri

AcceptFilter Yönergesi

Bu yönerge Protocol yönergesinde belirtilen 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 ve Windows'un en iyilenmiş AcceptEx() işlevi desteklenmektedir.

Değiştirge olarak none kullanımı, protokolün kabul süzgeçlerini iptal edecektir. ftp: veya nntp gibi sunucunun baştan bir veri göndermesinin gerekli olduğu protokoller için kullanışlıdır. Örnek:

AcceptFilter nntp none

Öntanımlı protokol isimleri port 443 için https ve tüm diğer portlar için http'dir. Dinlenmesi için başka bir port ile ilgili bir protokol belirtmek isterseniz Listen yönergesine protokol argümanını ekleyin.

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

AcceptFilter http httpready
AcceptFilter https dataready

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 öntanımlı değerler:

AcceptFilter http data
AcceptFilter https data

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.

Windows’taki öntanımlı değerler::

AcceptFilter http connect
AcceptFilter https connect

Windows'un mpm_winnt modülü AcceptEx() arayüzünü açıp kapamak için AcceptFilter'i yorumlar ve http protokol tamponlamasını desteklemez. connect, AcceptEx() arayüzünü kullanacak, ayrıca uç ağ adresleri de alınacak, fakat none gibi connect seçeneği de ilk veri aktarımını beklemeyecektir.

Windows'ta none AcceptEx()'ten ziyade accept() kullanır ve ağ soketlerini bağlantılar arasında yer değiştirmez. Sürücü desteği bozuk ağ bağdaştırıcılarından başka vpn sürücüleri gibi bazı sanal ağ sağlayıcılar veya spam, virus veya casus yazılım süzgeçleri için kullanışlıdır.

Ayrıca bakınız:

• Protocol

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:

<Files "mypaths.shtml">
  Options +Includes
  SetOutputFilter INCLUDES
  AcceptPathInfo On
</Files>

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:

AccessFileName .acl

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

<Directory "/">
    AllowOverride None
</Directory>

ş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, Genel Ağ ortam türlerinde (MIME türlerinde) kullanmak üzere IANA’da kayıtlı karakter kümesi değerlerinden biri olmalıdır. Örnek:

AddDefaultCharset utf-8

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

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

Off öntanımlı değeriyle, böyle URL’ler bir 404 (Nesne bulunamadı) hatasıyla reddedilirler.

On değeriyle, böyle URL’ler kabul edilir ve kodlanmış dosya yolu ayraçları kodlanmış diğer karakterler gibi çözümlenir.

NoDecode değeriyle, böyle URL’ler kabul edilir fakat kodlanmış dosya yolu ayraçları çözümlenmeden kodlanmış halde bırakılır.

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.

Bu yönergeye ve AllowOverrideList yönergesine 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. (Hangi yönerge-türü türü için hangi yönergelerin etkin olduğunu görmek için .htaccess için Geçersizleştirme Sınıfları sayfasına bakınız)

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, 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, mod_alias modülündeki Redirect, RedirectTemp, RedirectPermanent, RedirectMatch) 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.

Nonfatal=[Override|Unknown|All]

.htaccess dosyalarındaki sözdizimi hatalarının ölümcül olarak ele alınmaması için AllowOverride yönergesinin kullanımına izin verir; bunun yerine bir dahili sunucu hatasına sebep olur, izin verilmeyen veya tanınmayan yönergeler yoksayılır ve günlüğe bir uyarı çıktılanır:

• Nonfatal=Override ile AllowOverride tarafından yasaklanmış yönergeler ölümcül olarak ele alınmaz.
• Nonfatal=Unknown ile bilinmeyen yönergeler ölümcül olarak ele alınmaz. Yazım hatalarını ve mevcut olmayan bir modül tarafından gerçeklenmiş yönergeleri kapsar.
• Nonfatal=All ile yukarıdakilerin ikisi de ölümcül olarak ele alınmaz.

Geçerli bir yönergedeki yazım hatalarının hala dahili bir sunucu hatasına sebep olacağına dikkat ediniz.

Güvenlik

Ölümcül olmayan hatalar .htaccess kullanıcıları için güvenlikle ilgili sorunlara yol açabilir. Örneğin AllowOverride AuthConfig'e izin vermezse kullanıcıların siteye erişimini kısıtlayan yapılandırma iptal edilmiş olur.

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, fakat virgülden sonra boşluk bırakmadan belirtilebilir.

Options'ın örtük iptali

.htaccess dosyalarında kullanılabilen seçenek listesi bu yönergeyle sınırlanabilirse de herhangi bir Options yönergesine izin verildiği sürece miras alınmış diğer seçenekler göreli olmayan sözdizimi kullanılarak iptal edilebilir. Başka bir deyişle, bu mekanizma diğerlerinin değerlerini korumasına izin verirken belli bir seçeneği değerini korumaya zorlayamaz.

AllowOverride Options=Indexes,MultiViews

Örnek:

AllowOverride AuthConfig Indexes

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

Ayrıca bakınız:

• AccessFileName
• AllowOverrideList
• Yapılandırma Dosyaları
• .htaccess Dosyaları
• .htaccess için Geçersizleştirme Sınıfları

AllowOverrideList Yönergesi

Sunucu bir .htaccess dosyası (AccessFileName tarafından belirtildiği gibi) bulduğunda önceki yapılandırma yönergelerini geçersiz kılabilen bu dosyada hangi yönergelerin bildirildiğini bilmek ister.

Bu yönergeye ve AllowOverride yönergesine None atanmışsa .htaccess dosyaları tamamen yoksayılır. Bu durumda sunucu dosya sistemindeki .htaccess dosyalarını okumaya bile çalışmayacaktır.

Örnek:

AllowOverride None
AllowOverrideList Redirect RedirectMatch

Yukarıdaki örnekte sadece Redirect ve RedirectMatch yönergelerine izin verilmektedir. Tüm diğerleri dahili bir sunucu hatasına sebep olacaktır.

Örnek:

AllowOverride AuthConfig
AllowOverrideList CookieTracking CookieName

Yukarıdaki örnekte AllowOverride yönergesi AuthConfig yönerge grubuna izin verirken AllowOverrideList yönergesi FileInfo yönerge grubundan yalnız iki yönergeye izin vermektedir. Tüm diğerleri dahili bir sunucu hatasına sebep olacaktır.

Ayrıca bakınız:

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

CGIMapExtension Yönergesi

Bu yönerge Apache httpd’nin 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.

CGIPassAuth Yönergesi

CGIPassAuth yönergesi, HTTP Temel kimlik doğrulamasını gerçekleştiren betikler için gereken Authorization gibi HTTP yetkilendirme başlıklarına betiklerin erişebilmesini sağlar. Normalde bu HTTP başlıkları betiklerden gizli olup sunucuda HTTP Temel kimlik kanıtlaması etkin kılındığında sunucuya erişmekte kullanılan kullanıcı kimliklerinin ve parolalarının betikler tarafından görülmemesini mümkün kılar. Bu yönerge, HTTP Temel kimlik kanıtlamasını betiklerin gerçekleştirmesini sağlamak için kullanılmalıdır.

Apache HTTP Sunucusunun önceki sürümlerinde derleme sırasında kullanılabilen SECURITY_HOLE_PASS_AUTHORIZATION sabitinin yerine bu yönerge kullanılabilir.

Bu ayarlama mod_cgi, mod_cgid, mod_proxy_fcgi, mod_proxy_scgi ve benzerleri gibi ap_add_common_vars() kullanan modüller tarafından kabul görür. Özellikle, isteği alışılmış tarzda işleme sokmayıp bu arayüzü kullanan modülleri etkiler. Ayrıca, ap_add_common_vars() kullanmayan üçüncü parti modüller de bu ayarlamayı kullanmayı tercih edebilir.

CGIVar Yönergesi

Bu yönerge bazı CGI değişkenlerinin nasıl atanacağını belirler.

REQUEST_URI kuralları:

original-uri (default)

Değer özgün istek satırından alınır ve dahili yöneldirmeler veya istenen özkaynakları değiştiren alt istekler dikkate alınmaz.

current-uri

Değer özgün istek satırından farklı olabilecek dahili yönlendirmeleri veya istenen özkaynakları değiştiren alt istekleri de yansıtır.

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.

DefaultRuntimeDir Yönergesi

DefaultRuntimeDir yönergesi sunucunun çalışma anında oluşturacağı dosyaların (paylaşımlı bellek, kilitler, vb.) saklanacağı dizini belirtmekte kullanılır. Göreli bir yol belirtilirse tam yol ServerRoot yönergesinde belirtilene göreli olacaktır.

Örnek

DefaultRuntimeDir scratch/

DefaultRuntimeDir için öntanımlı yer derleme sırasında DEFAULT_REL_RUNTIMEDIR #define satırı ile değiştirilebilir.

Bilgi: ServerRoot bu yönergeden önce belirtilmiş olmalıdır, aksi takdirde temel dizin için öntanımlı ServerRoot kullanılır.

Ayrıca bakınız:

• ServerRoot üzerindeki izinlerin düzgün olarak nasıl ayarlanacağını öğrenmek için: güvenlik ipuçları

DefaultType Yönergesi

Bu yönerge iptal edilmiştir. Yapılandırma dosyalarının geriye uyumluluğunu sağlamak için, öntanımlı bir ortam türünün olmadığını belirten none değeriyle belirtilebilir. Örnek:

DefaultType None

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

Ortam türlerini dosya uzantıları üzerinden yapılandırmak için AddType yönergesini ve mime.types yapılandırma dosyasını veya belli özkaynak türleri için ortam türlerini yapılandırmak için ForceType yönergesini kullanın.

Define Yönergesi

Tek değiştirgeli biçemi httpd’yi -D seçeneğiyle çalıştırmaya eşdeğerdir. Bu yönerge, başlatma betiğinde -D seçeneğinin argümanlarını değiştirme gereği duymaksızın <IfDefine> bölümlerini kullanıma sokmak için kullanılabilir.

Buna ek olarak, ikinci değiştirge belirtilirse yapılandırma değişkenine bu değer atanır. Değişken yapılandırmada ${VAR} sözdizimi ile kullanılabilir. Değişken daima küresel olarak tanımlı olup yapılandırma bölümünü sarmalayan etki alanı ile sınırlanmaz.

<IfDefine TEST>
  Define servername test.example.com
</IfDefine>
<IfDefine !TEST>
  Define servername www.example.com
  Define SSL
</IfDefine>
DocumentRoot "/var/www/${servername}/htdocs"

RewriteMap sözdizimi ile karışmalardan kaçınmak için değişken isimleri ikinokta ":" karakterleri içeremez.

Ayrıca bakınız:

• UnDefine
• IfDefine

<Directory> Yönergesi

<Directory> ve </Directory> sadece ismi belirtilen dosya sistemi dizininde, bunun altdizinlerinde ve bu dizinlerin içindeki dosyalara 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:

<Directory "/usr/local/httpd/htdocs">
  Options Indexes FollowSymLinks
</Directory>

Dizin yollarında isterseniz önceleme kullanabilirsiniz, ancak eğer yol bazı boşluklar içeriyorsa mutlaka kullanmanız gerekir. Bir boşluk aksi belirtilmedikçe bir ifadenin sonunu belirlediğinden bu gereklidir.

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

<Directory ~ "^/www/[0-9]{3}">

</Directory>

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,

<Directory "/">
  AllowOverride None
</Directory>

<Directory "/home">
  AllowOverride FileInfo
</Directory>

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,

<Directory ~ "abc$">
  # ... yönergeler burada ...
</Directory>

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ı erişimin tüm erişime izin vermek oluşuna dikkat ediniz. Bunu şöyle bir blokla değiştirmeniz,

<Directory "/">
  Require all denied
</Directory>

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 apache2.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 açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

<DirectoryMatch> Yönergesi

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

<DirectoryMatch "^/www/(.+/)?[0-9]{3}/">
    # ...
</DirectoryMatch>

yönergesi /www/ içindeki (veya alt dizinlerindeki) üç rakamdan oluşan dizinlerle eşleşecektir.

2.4.8 itibariyle, isimli gruplar ve geriye başvurular elde edilmekte olup ilgili isim büyük harfe çevrildikren sonra "MATCH_" ile öncelendikten sonra ortama yazılmaktadır. Böylece yol elemanlarına mod_rewrite gibi modüllerden veya düzenli ifadelerden başvurmak mümkün kılınmıştır. Karışıklığı önlemek için, numaralı (isimsiz) geriye başvurular yoksayılmaktadır. Bunların yerine isimli geriye başvurular kullanılmalıdır.

<DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)">
    require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</DirectoryMatch>

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:

DocumentRoot "/usr/web"

yapılandırması ile http://my.example.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

<Else> Yönergesi

<Else> sadece ve sadece aynı etki alanındaki en son <If> veya <ElseIf> bölümü uygulanmamışsa kapsadığı yönergeleri uygular. Örneğin:

<If "-z req('Host')">
  # ...
</If>
<Else>
  # ...
</Else>

Burada, <If> yönergesi Host: başlıksız HTTP/1.0 istekleriyle eşleşirken <Else> Host: başlıklılarla eşleşir.

Ayrıca bakınız:

• <If>
• <ElseIf>
• 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. <If>, <ElseIf> ve <Else> son olarak uygulanır.

<ElseIf> Yönergesi

<ElseIf> kapsadığı yönergeleri sadece ve sadece belirtilen koşulun doğrulandığı ancak aynı etki alanında hemen önceki <If> veya <ElseIf> yönergesinin uygulanmadığı takdirde uygular. Örnek:

<If "-R '10.1.0.0/16'">
  #...
</If>
<ElseIf "-R '10.0.0.0/8'">
  #...
</ElseIf>
<Else>
  #...
</Else>

<ElseIf> bir isteğin uzak adresi 10.0.0.0/8 ağına aitse ama 10.1.0.0/16 ağına ait değilse içerdiği yönergelerin uygulanmasını sağlar.

Ayrıca bakınız:

• Tam bir kaynak ve daha fazla örnek için: Apache HTTP Sunucusundaki ifadeler
• <If>
• <Else>
• 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. <If>, <ElseIf> ve <Else> son olarak uygulanır.

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 httpd, 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.
• httpd bellek eşlemli çalışırken bir dosyanın silinmesi veya boyutunun küçültülmesi httpd'nin parçalama arızası vererek çökmesine yol açabilir.

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:

EnableMMAP Off

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

<Directory "/nfs-dosyaları-yolu">
  EnableMMAP Off
</Directory>

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 httpd, 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 (sendfile) 2GB’tan büyük dosyalarla çalışamamaktadır.
• DocumentRoot ağ dosya sistemi (NFS, SMB, CIFS, FUSE 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 etkin kılabilirsiniz:

EnableSendfile On

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

<Directory "/nfs-dosyaları-yolu">
  EnableSendfile Off
</Directory>

EnableSendfile yönergesinin .htaccess ve diziniçi yapılandırmalarının mod_cache_disk tarafından desteklenmediğini lütfen aklınızdan çıkarmayın. EnableSendfile yönergesinin sadece küresel tanımları hesaba katılır.

Error Yönergesi

Yapılandırmada bir hatanın saptanması istenirse, bu yönerge yapılandırma çözümlemesinin durdurulması ve özel bir hata iletisi üretilmesi için kullanılabilir. Genelde kullanıldığı durum, gerekli modüllerin yapılandırmada bulunmadığının raporlanmasıdır.

# Örnek
# mod_include yüklü değilse bilelim
<IfModule !include_module>
  Error "Hata: mod_include mod_foo için gerekiyor. LoadModule ile yükleyin."
</IfModule>

# SSL veya NOSSL tanımlı mı bilelim
<IfDefine SSL>
<IfDefine NOSSL>
  Error "Ne SSL ne de NOSSL tanımlı. Sadece biri tanımlı olsa yeter."
</IfDefine>
</IfDefine>
<IfDefine !SSL>
<IfDefine !NOSSL>
  Error "Ya SSL ya da NOSSL tanımlı olmalı."
</IfDefine>
</IfDefine>

ErrorDocument Yönergesi

Bir sorun çıktığında veya hata oluştuğunda Apache httpd ş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 dahili bir 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 httpd bazı durumlarda sorun/hata ile ilgili ek bilgi verecektir.

2.4.13 itibariyle, özdevinimli dizgeler ve URLler üretmek için yönerge içinde ifade sözdizimi kullanılabilir.

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:

ErrorDocument 500 http://example.com/cgi-bin/server-error.cgi
ErrorDocument 404 /errors/bad_urls.php
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Kusura bakmayın, bugün hizmet veremiyoruz."
ErrorDocument 403 /errors/forbidden.pl?referrer=%{escape:%{HTTP_REFERER}}

Bunlardan başka, Apache httpd’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 httpd’nin kendi hata iletilerinin kullanımı default değeri açıkça belirtilerek örnekteki gibi zorlanabilir:

ErrorDocument 404 /cgi-bin/bad_urls.pl

<Directory "/web/docs">
  ErrorDocument 404 default
</Directory>

ErrorDocument yönergesinde bir uzak URL (önünde http bulunan bir yol) belirtildiğinde, belge aynı sunucuda olsa bile, Apache HTTP Sunucusunun 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.

mod_proxy kullanıyorsanız, ProxyErrorOverride yönergesini etkin kılmak isteyebilirsiniz, böylece asıl sunucular adına özel hata iletileri üretebilirsiniz. ProxyErrorOverride etkin kılınmak istenmezse, Apache httpd vekalet edilen içerik için özel hata belgeleri üretmeyecektir.

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.

ErrorLog "/var/log/httpd/error_log"

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

ErrorLog "|/usr/local/bin/httpd_errors"

Daha fazla bilgi için borulu günlüklere bakınız.

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. Oluşum aslında küreseldir ve sanal konaklardan bazılarında değiştirilmişse, belirtilen en son oluşum tüm sunucuyu etkileyecektir. etiket için de aynı kurallar uygulanır. Genellikle, öntanımlı etiket olarak Apache çalıştırılabilirinin ismi olan httpd kullanılır. Öntanımlı etiketi syslog::etiket sözdizimini kullanarak değiştirebilirsiniz

ErrorLog syslog:user
ErrorLog syslog:user:httpd.srv1
ErrorLog syslog::httpd.srv2

Buna ek olarak, modüller kendi günlük kaydı oluşturucusunu sağlayabilir. Sözdizimi yukarıdaki örnekte kullanılan syslog sözdiziminin benzeridir.

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 HTTP Sunucusunun Günlük Dosyaları

ErrorLogFormat Yönergesi

ErrorLogFormat yönergesi, hata günlüğünde asıl hata iletisine ek olarak günlüklenecek ek bilgiyi belirtmek için kullanılabilir.

#Basit örnek
ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"

İlk değiştirge olarak connection veya request belirtilmesi ek biçemlerin belirtilebilmesini sağlar. Böylece, belli bir bağlantı ya da istek için ilk ileti günlüklendiğinde ek bilgininde günlüklenmesi sağlanır. Bu ek bilgi sadece bağlantı/istek başına bir kere günlüklenir. herhangi bir günlük iletisine sebep olmadan işlenmişse ek bilgi de günlüklenmez.

Bu, bazı biçem dizgesi öğeleri çıktı üretmediğinde olur. Örneğin, Referer başlığı sadece günlük iletisi bir istekle ilişkilendirilmişse mevcuttur ve hata iletisi Referer başlığı istemcide okunduğu anda oluşur. Eğer bir çıktı üretilmezse, öntanımlı davranış önceki boşluk karakterinden sonraki boşluk karakterine kadar herşeyi silmektir. Yani, günlük satırı örtük olarak boşluklarla ayrılmış alanlara bölünür. Bir biçem dizgesi öğesi çıktı üretmezse alanın tamamı çıktılanmaz. Örneğin, [%t] [%l] [%a] %M  günlük biçeminde uzak adres %a kullanılamazsa sarmalayıcı köşeli ayraçlar da günlüklenmeyecektir. Boşluk karakterleri ters bölülerle öncelenerek bir alanı sınırlaması önlenebilir. '% ' (yüzde boşluk) çifti sıfır genişlikte bir alan ayracı olup herhangi bir çıktı üretmez.

Yukarıdaki davranış, biçem dizgesi öğesine değiştirciler eklenerek değiştirilebilir. - (tire) değiştircisi ilgili öğe bir çıktı üretmediğinde tire iminin günlüklenmesine sebep olur. Bağlantı/istek başına bir kere biçemlerinde + (artı) değiştircisini de kullanmak mümkündür.Artı değiştiricili bir öğe herhangi bir çıktı üretmezse satırın tamamı günlüklenmez.

Bir biçem öğesine günlük önem derecesi atamak için değiştirici olarak bir sayı kullanılabilir. Bu öğenin günlüklenebilmesi için günlük iletisinin önem derecesinin belirtilen günlük önem derecesinden daha yüksek olmaması gerekir. Sayı 1'den (alarm) 4'e (uyarı) ve 7'den (hata ayıklama) 15'e (trace8) kadar olabilir.

Örneğin, Referer istek başlığını günlükleyen %{Referer}i dizgeciğine değiştirciler eklendiğinde neler olduğunu burada görebilirsiniz:

Bazı biçem dizfesi öğeleri ayraç içine alınmış ek değiştirgeler kabul eder.

The log ID format %L günlük kimliği biçemi bağlantı veya istek için eşsiz bir kimlik üretir. Bu, bağlantı üzerinden gelen istek durumunda günlük satırlarının ait olduğu bağlantı veya isteği bağdaştırmak için kullanılabilir. %L biçem dizgesi ayrıca mod_log_config modülünde erişim günlüğü iletilerini hata günlüğü iletileriyle ilişklendirmek için de kullanılabilmektedir. mod_unique_id modülü yüklüyse onun eşsiz kimliği istekler için günlük kimliği olarak kullanılacaktır.

#Örnek (Evreli MPM'ler için öntanımlı biçim)
ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"

Bunun hata iletilerindeki sonuçları şöyle olabilir:

Dikkat edin, yukarıda açıklandığı gibi, bazı alanlar tanımlanmadıklarından tamamen yoksayılır.

#Örnek (2.2.x biçimine benzer)
ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"

#İstek/bağlantı günlük kimlikli gelişkin bir örnek
ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"
ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"
ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"
ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"
ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"

Ayrıca bakınız:

• ErrorLog
• LogLevel
• Apache HTTP Sunucusu Günlük Dosyaları

ExtendedStatus Yönergesi

Bu yönerge, o an işlenmekte olan istek hakkında evre başına ek veriyi ve kullanım özetini izler; mod_status modülünü yapılandırarak bu değişkenleri çalışma anında görebilirsiniz. Diğer modüllerin bu sonuçlara bel bağlayabileceğini unutmayın.

Bu ayarlar sunucunun tamamına uygulanır ve bir sanal konakta etkin başka bir sanal konakta etkisiz kılınamaz. Ek durum bilgisinin toplanması sunucuyu yavaşlatabilir. Ayrıca, bu ayarın nazikçe yeniden başlatma sırasında değiştirilemeyeceğine dikkat ediniz.

FileETag Yönergesi

FileETag yönergesi, belge bir duruk 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.) FileETagyö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.

<Files "zat.html">
    # zat.html dosyasına uygulanacakları buraya koy
</Files>

<Files "?at.*">
    # Buradakiler hat.html, kat.html, tat.html ve benzerlerine uygulanır.
</Files>

~ imine ek olarak düzenli ifadeler de kullanılabilir. Örneğin

<Files ~ "\.(gif|jpe?g|png)$">
    #...
</Files>

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

<FilesMatch "\.(gif|jpe?g|png)$">
    # ...
</FilesMatch>

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

2.4.8 itibariyle, isimli gruplar ve geriye başvurular elde edilmekte olup ilgili isim büyük harfe çevrildikren sonra "MATCH_" ile öncelendikten sonra ortama yazılmaktadır. Böylece yol elemanlarına mod_rewrite gibi modüllerden veya düzenli ifadelerden başvurmak mümkün kılınmıştır. Karışıklığı önlemek için, numaralı (isimsiz) geriye başvurular yoksayılmaktadır. Bunların yerine isimli geriye başvurular kullanılmalıdır.

<FilesMatch "^(?<sitename>[^/]+)">
    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</FilesMatch>

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 ortam-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:

ForceType image/gif

Bu yönerge, AddType yönergesi üzerinden ve mime.types dosyasında örtük olarak tanımlanmış ortam türü/dosya uzantısı ilişkilerini geçersiz kılar.

Ayrıca, daha genel ForceType ayarlarını da None değeriyle geçersiz kılabilirsiniz:

# tüm dosyaların image/gif olarak sunulması için:
<Location "/images">
  ForceType image/gif
</Location>

# normal MIME-türüne geri dönmek için:
<Location "/images/mixed">
  ForceType None
</Location>

Bu yönerge, öncelikle dosya sisteminden sunulan duruk dosyalar için üretilen içerik türlerini geçersiz kılar. Duruk dosyaların haricindeki özkaynaklar için yanıt üretecinin genelde bir Content-Type belirttiği durumda bu yönerge etkisizdir.

GprofDir Yönergesi

Sunucu gprof ayrıntılı inceleme desteği ile derlenmişse, GprofDir yönergesi gmon.out dosyalarının süreç çıktığında belirtilen dizine yazılmasını sağlar. Eğer değiştirge bir yüzde simgesi ('%') ile bitiyorsa her süreç kimliği için alt dizinler oluşturulur.

Bu yönerge şimdilik sadece prefork MPM'i ile çalışmaktadır.

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.

Son olarak, konak ismine dayalı Require yönergelerine sahipseniz konak ismi araması HostnameLookups ayarına bakılmaksızın gerçekleştirilecektir.

HttpProtocolOptions Yönergesi

Bu yönerge HTTP istek satırına (RFC 7230 §3.1.1) ve the HTTP istek başlığı alanlarına (RFC 7230 §3.2) uygulanmış kuralları öntanımlı olarak veya Strict seçeneği kullanılarak değiştirir. Eski modüller, uygulamalar veya kullanımı önerilmeyen özel istemciler için eski davranışlara dönmeyi sağlamak üzere Unsafe seçeneği eklenmiştir.

Bu kurallar istek işlenmeden önce uygulanır. Dolayısıyla yönerge, IP/port arabirimine göre ana bölümde veya öntanımlı (ilk) eşleşen sanal konak bölümünde yapılandırılmalıdır.

Bu yönergeye aşağıdaki parametrelerden seçilen üç tanesi uygulanabilir. Belirtilmeyenlerin yerine öntanımlılar uygulanır.

Strict|Unsafe

Bu yönerge devreye girmeden önce, Apache HTTP Sunucusunun istek iletisi ayrıştırıcıları protokolle uyumlu olmayan bir dizi girdi şekline toleranslıydı. RFC 7230 §9.4 İstek bölme ve §9.5 Yanıt kaçırma çağrıları uyumsuz istek iletilerinin kabulündeki olası risklerden yalnızca iki tanesidir. RFC 7230 §3.5 "İleti Ayrıştırma Sağlamlığı" belirsiz boşlukların kabul ve istek iletisi biçimleme risklerini tanımlar. Bu yönergenin devreye girmesini takiben belirtimin tüm imla kurallarına öntanımlı Strict işlem kipi ve 3.5 bölümünde tavsiye edilen hoşgörüsüz boşluk uygulanır ve esnekliğe müsamaha edilmez.

Unsafe için güvenlik riskleri

Kullanıcılar, özellikle dışa bakan, herkes tarafından erişilebilen sunucu konuşlandırmalarında Unsafe işlem kipine geçiş yapmaya karşı kesinlikle uyarılır. Eğer bir arayüz hataları izlemek veya bir intranette çalışan özel hizmet tüketicileri için gerekliyse, kullanıcılar, sadece, dahili özel ağlarına hizmet etmek üzere yapılandırılmış özel bir sanal konak üzerinde Unsafe işlem kipine geçiş yapmalıdır.

Strict kipte HTTP 400 ile sonuçlanan bir istek örneği

# Eksik CRLF
GET / HTTP/1.0\n\n

Komut satırı araçları ve CRLF

Bazı araçların CRLF kullanmaya zorlanması gerekir, aksi takdirde httpd yukarıdaki örnekte belirtildiği gibi bir HTTP 400 yanıtı ile döner. Örneğin, OpenSSL s_client düzgün çalışmak için -crlf değiştirgesine ihtiyaç duyar.

CRLF yokluğu gibi durumları saptamak için HTTP isteğini görünümlemek isterseniz DumpIOInput yönergesi yardımcı olabilir.

RegisteredMethods|LenientMethods

RFC 7231 §4.1 "İstek Yöntemleri" "Genel Bakış" bölümlerinde bir istek satırında desteklenmeyen bir yöntem saptadığında özgün sunucuların bir hatayla yanıt vermesini gerekli görmüştür. LenientMethods seçeneği kullanıldığında olan zaten budur. RegisteredMethods seçeneğine geçiş yapmak isteyen yöneticiler RegisterHttpMethod yönergesini kullanarak standart olmayan yöntemleri belirlemelidir. Özellikle Unsafe seçeneğine geçiş yapılacaksa bu yol izlenmelidir.

İleri Vekil Uyumluluğu

Özgün sunucunun kullandığı yöntemleri vekil sunucu bilemeyeceği için ileri vekil konaklarda RegisteredMethods seçeneğine geçiş yapılmamalıdır.

Example of a request leading to HTTP 501 with LenientMethods mode

# Unknown HTTP method
WOW / HTTP/1.0\r\n\r\n

# Lowercase HTTP method
get / HTTP/1.0\r\n\r\n


Allow0.9|Require1.0

RFC 2616 §19.6 "Önceki Sürümlerle Uyumluluk" bölümünde HTTP sunucularının eski HTTP/0.9 isteklerini desteklemesi tavsiye edilmektedir. RFC 7230 "HTTP/0.9 isteklerini destekleme beklentisi kaldırılmıştır." cümlesiyle bunu geçersiz kılmış ve RFC 7230 Ek A bölümünde bununla ilgili yorumlar yer almıştır. Require1.0 seçeneği kullanıcıya öntanımlı Allow0.9 seçeneğinin davranışına verilen desteği kaldırma imkanını vermektedir.

Require1.0 kipinde HTTP 400 ile sonuçlanan bir istek örneği

# Desteklenmeyen HTTP sürümü
GET /\r\n\r\n

LogLevel debug seviyesiyle yapılandırılmış ErrorLog ile kaydedilmiş günlüklerin gözden geçirilmesi, böyle hatalı isteklerin kaynaklandıkları yerle birlikte belirlenmesine yardımcı olabilir. Kullanıcılar, beklenmedik bir şekilde reddedilmiş geçersiz istekleri bulmak için erişim günlüklerindeki 400 yanıtlarına özellikle dikkat etmelidir.

<If> Yönergesi

<If> yönergesi bir ifadeyi çalışma anında değerlendirir ve ifadenin sonucu doğru olduğu takdirde içerdiği yönergeleri uygular. Örnek:

<If "-z req('Host')">

Bir Host: başlığı içermeyen HTTP/1.0 istekleriyle eşleşir. İfadeler, dizge karşılaştırması (==, !=, <, ...), tamsayı karşılaştırması (-eq, -ne, ...) ve diğerleri (-n, -z, -f, ...) için kabuktakilere benzer çeşitli işleçler içerebilir. Ayrıca, düzenli ifadeleri,

<If "%{QUERY_STRING} =~ /(delete|commit)=.*?elem/">

kabuk tarzı kalıp eşleştirme ve birçok başka işlemi kullanmak da mümkündür. Bu işlemler istek başlıklarında (req), ortam değişkenlerinde (env) ve çok sayıda başka niteliklerin üstünde yapılabilir. Apache HTTP Sunucusundaki İfadeler belgesinde daha ayrıntılı bilgi bulabilirsiniz.

Bu yapılandırma bölümünün içinde sadece dizin bağlamını destekleyen yönergeler kullanılabilir.

Ayrıca bakınız:

• Apache HTTP Sunucusundaki İfadeler belgesinde daha ayrıntılı bilgi ve örnek bulabilirsiniz.
• <ElseIf>
• <Else>
• 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. <If>, <ElseIf> ve <Else> son olarak uygulanır.

<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 veya Define yönergesi 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:

<IfDefine ReverseProxy>
  LoadModule proxy_module   modules/mod_proxy.so
  LoadModule proxy_http_module   modules/mod_proxy_http.so
  <IfDefine UseCache>
    LoadModule cache_module   modules/mod_cache.so
    <IfDefine MemCache>
      LoadModule mem_cache_module   modules/mod_mem_cache.so
    </IfDefine>
    <IfDefine !MemCache>
      LoadModule cache_disk_module   modules/mod_cache_disk.so
    </IfDefine>
  </IfDefine>
</IfDefine>

<IfDirective> Yönergesi

<IfDirective yönerge-adı> ...</IfDirective> bölümü içindeki yönergeler yönerge-adı ile belirtilen yönerge mevcutsa çalıştırılır yoksa yok sayılır.

<IfDirective> yönergenide sınama iki türlü yapılır:

• yönerge-adı
• !yönerge-adı

İlk durumda bölüm içinde kalan yönergeler, yönerge başlangıç satırına belirtilen yönerge işlem sırasında mevcutsa çalıştırılır, değilse çalıştırılmaz. İkinci durumda ise, bölüm içinde kalan yönergeler, yönerge başlangıç satırına belirtilen yönerge işlem sırasında mevcut değilse çalıştırılır, mevcutsa çalıştırılmaz.

Ayrıca bakınız:

• <IfSection>

<IfFile> Yönergesi

<IfFile dosyaadı>...</IfFile> bölümü bir dosyanın diskteki mevcudiyetine bağlı olarak çalıştırılacak yönergeleri belirtmekte kullanılır. <IfFile> bölümü içindeki yönergeler sadece diskte dosyaadı mevcutsa çalıştırılır. dosyaadı mevcut değilse bölüm içindeki yönergeler yok sayılır. dosyaadı sunucu kök dizinine göreli veya mutlak bir yol olarak belirtilebilir.

<IfFile> bölüm yönergesindeki dosyaadı, <IfDefine> yönergesindeki sınama değişkenindeki gibi ele alınır, yani dosyaadı bir ! ile öncelenirse bölüm içindeki yonergeler dosyanın yokluğu durumunda çalıştırılır.

Göreli bir dosyaadı belirtilmişse sınama ServerRoot yönergesinde belirtilen dizinde göre yapılır. <IfFile> yönergesinin ServerRoot yönergesinde önce yer alması durumunda dosya yolu derleme sırasında kullanılan sunucu köküne veya komut satırında -d seçeneği ile belirtilen dizine göre sınanır.

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

<IfSection> Yönergesi

<IfSection bölüm-adı> ...</IfSection> bölümü içindeki yönergeler bölüm-adı ile belirtilen bölüm mevcutsa çalıştırılır yoksa yok sayılır. Bir bölüm yönergesi "<" ile öncelenmiş bir yönerge adına sahip olmalı ve <VirtualHost> gibi başka yönergeleri sarmalayan bir yönerge olmalıdır.

<IfSection> bölümü içindeki yönergeler sadece sınama doğru ise çalıştırılır, sınama yanlışsa çalıştırılmaz.

bölüm-adı başında "<" veya sonunda ">" olmaksızın belirtilmelidir. <IfSection> yönergesindeki bölüm-adı iki türlü ele alınır:

• bölüm-adı
• !bölüm-adı

İlk durumda bölüm içinde kalan yönergeler, yönerge başlangıç satırına belirtilen bölüm işlem sırasında mevcutsa çalıştırılır, değilse çalıştırılmaz. İkinci durumda ise, bölüm içinde kalan yönergeler, yönerge başlangıç satırına belirtilen bölüm işlem sırasında mevcut değilse çalıştırılır, mevcutsa çalıştırılmaz.

Örnek:

<IfSection VirtualHost>
   ...
</IfSection>

Ayrıca bakınız:

• <IfDirective>

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 yolun dosya ismi ve dizin parçalarında 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 httpd bu dizindeki ve alt dizinlerindeki bütün dosyaları okuyacaktır. Bunula birlikte, dizinin bir bütün olarak okutulması önerilmez, çünkü dizinde httpd programının çökmesine sebep olabilecek geçici dosyalar unutulabilir. Bunun yerine, belli bir şablona uyan dosyaları seçebilmek için, örneğin *.conf gibi dosya kalıplarının kullanılmasını öneriyoruz.

Include yönergesi, bir dosya kalıbı ifadesi hiçbir dosyayla eşleşmezse bir hatayla başarısız olacaktır. Eşleşmeyen dosya kalıbı ifadelerinin yoksayılması gerekiyorsa IncludeOptional yönergesi kullanılabilir.

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

Örnekler:

Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf

Veya dizinler ServerRoot dizinine göre belirtilebilir:

Include conf/ssl.conf
Include conf/vhosts/*.conf

Dosya kalıbı karakterleri yolun dizin ve dosya parçalarına yerleştirilebilir. conf/vhosts altında en azından bir *.conf içeren hiçbir alt dizin yoksa bu örnek başarısız olacaktır:

Include conf/vhosts/*/*.conf

Bunun yerine, dizin ve dosyaların eksikliği durumunda aşağıdaki komut sadece yoksayılır:

IncludeOptional conf/vhosts/*/*.conf

Ayrıca bakınız:

• IncludeOptional
• apache2ctl

IncludeOptional Yönergesi

Bu yönerge, diğer yapılandırma dosyalarının sunucu yapılandırma dosyasında içerilmesini sağlar. Çalışması Include yönergesi ile bir istisna dışında aynıdır. Dosya kalıp karakterlerinin hiçbir dosya veya dizinle eşleşmemesi veya dosya yolunun dosya sisteminde mevcut olmaması durumunda bir hata oluşmayacak ve bu durum sadece yoksayılacaktır.

Ayrıca bakınız:

• Include
• apache2ctl

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, MaxConnectionsPerChild 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. Ayrıca, ms soneki kullanılarak süreyi milisaniye olarak belirtmek de mümkündür. İ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 için KeepAliveTimeout atanmamışsa, yerel IP adresi ve portu ile en iyi eşleşen ilk sanal konağın değeri kullanılır.

<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:

<Limit POST PUT DELETE>
  Require valid-user
</Limit>

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 (bkz, TraceEnable).

<Limit> ve <LimitExcept> yönergeleri iç içe olabilirler. Bu durumda, başarılı her <Limit> veya <LimitExcept> seviyesi, erişim denetimlerinin uygulanacağı yöntemlerle sınırlı kalmalıdır.

Örneğin, aşağıdaki yapılandırmayı ele alalım; tüm kullanıcılar POST istekleri için yetkilendirilecek ve tüm durumlarda Require group editors yönergesi yoksayılacaktır:

<LimitExcept GET>
  Require valid-user
</LimitExcept>
<Limit POST>
  Require group editors
</Limit>

<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:

<LimitExcept POST GET>
  Require valid-user
</LimitExcept>

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 httpd’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.

LimitInternalRecursion 5

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. Vekil isteklerinin snırlı uygulanabilirliği için aşağıdaki nota bakınız.

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:

LimitRequestBody 102400