Yapılandırma Bölümleri

Mevcut Diller: en | + fr | + ja | + ko | + tr

+ +

Yapılandırma dosyalarındaki + yönergeler sunucunun tamamına uygulanacağı gibi sadece belli dizinler, + dosyalar, konaklar veya URL’lere uygulanmakla sınırlanabilir. Bu + belgede, yapılandırma bölümü taşıyıcılarınının veya + .htaccess dosyalarının, yapılandırma dosyalarındaki diğer + yönergelerin etki alanlarını değiştirtirmek için nasıl kullanılacağı + açıklanmıştır.

Yapılandırma Bölümü Taşıyıcılarının Türleri
Dosya Sistemi, Site Alanı ve Mantıksal İfadeler
Sanal Konaklar
Vekil
Hangi Yönergelere İzin Veriliyor?
Bölümler Nasıl Katıştırılır?

Ayrıca bakınız:

Yorumlar

Yapılandırma Bölümü Taşıyıcılarının Türleri

+ +

İlgili Modüller	İlgili Yönergeler
`core` `mod_version` `mod_proxy`	`<Directory>` `<DirectoryMatch>` `<Files>` `<FilesMatch>` `<If>` `<IfDefine>` `<IfModule>` `<IfVersion>` `<Location>` `<LocationMatch>` `<MDomainSet>` `<Proxy>` `<ProxyMatch>` `<VirtualHost>`

+ +

İki temel taşıyıcı türü vardır. Taşıyıcıların çoğu her istek için + değerlendirmeye alınır. Taşıyıcılardaki yönergeler ise sadece bu + taşıyıcılarla eşleşen istekler için uygulanır. Diğer yandan, + <IfDefine>, + <IfModule> ve + <IfVersion> + taşıyıcıları sadece sunucu başlatılırken veya yeniden başlatılırken + değerlendirmeye alınır. Başlatma sırasında gerektirdikleri koşullar + sağlanıyorsa içerdikleri yönergeler tüm isteklere uygulanır. Aksi + takdirde, içerdikleri yönergeler yok sayılır.

+ +

<IfDefine> yönergesi + sadece httpd komut satırında uygun parametreler + tanımlanmışsa uygulanabilecek yönergeleri içerir. Örneğin, aşağıdaki + yapılandırma ile tüm isteklerin diğer siteye yönlendirilebilmesi sadece + sunucu httpd -DClosedForNow komut satırı ile başlatıldığı + takdirde mümkün olur:

+ +

<IfDefine ClosedForNow>
+  Redirect "/" "http://otherserver.example.com/"
+</IfDefine>

+ + +

<IfModule> yönergesi + sadece belli bir modülün sunucuda kullanılabilir durumda olması halinde + uygulanabilecek yönergeleri içerir. Modülün ya sunucuyla birlikte durağan + olarak derlenmiş olması ya da devingen olarak derlenmiş ve yapılandırma + dosyasında yönergeden önce o modüle ilişkin bir LoadModule satırının bulunması gerekir. Bu + yönergeyi sadece belli bir modülün varlığının veya yokluğunun + yapılandırma dosyanızın çalışmasını etkilememesini istediğiniz durumlarda + kullanmalısınız. Eksik modüllerle ilgili hata iletilerini + engellediğinden, taşıyıcı içine, her zaman çalışması istenen yönergeler + konulmamalıdır.

+ +

Aşağıdaki örnekte, MimeMagicFile yönergesi sadece + mod_mime_magic modülü mevcutsa uygulanacaktır.

+ +

<IfModule mod_mime_magic.c>
+  MimeMagicFile "conf/magic"
+</IfModule>

+ + +

<IfVersion> + yönergesi sunucunun belli bir sürümünün çalıştırılması halinde + uygulanabilecek yönergeleri içerebilmesi dışında <IfDefine> ve <IfModule> yönergeleri gibidir. + mod_version modülü farklı httpd sürümleri ve farklı + yapılandırmalarla büyük ağlarda çalışmayı mümkün kılmak veya sürüm + denemeleri yapabilmek amacıyla tasarlanmıştır.

+ +

<IfVersion >= 2.4>
+  # burası sadece 2.4.0 veya daha üstü sürümlerde
+  # iş görür.
+</IfVersion>

+ + +

<IfDefine>, + <IfModule> ve + <IfVersion> + yönergelerinin önüne "!" konularak olumsuz koşullar için uygulanabilir. + Ayrıca, bu bölümler daha karmaşık sınırlamalar elde etmek amacıyla bir + diğerinin içinde kullanılabilirler.

Dosya Sistemi, Site Alanı ve Mantıksal İfadeler

+ + +

En sık kullanılan yapılandırma bölümü taşıyıcıları dosya sistemindeki + veya site alanındaki belli yerlerin yapılandırmalarını değiştirmekte + kullanılanlardır. Öncelikle, bu ikisi arasındaki farkları bilmek + önemlidir. Dosya sistemi disklerinizin işletim sistemi tarafından size + gösterilen halidir. Örneğin, öntanımlı kurulumda Apache httpd, Unix + sistemlerinde /usr/local/apache2 altındayken Windows + sistemlerinde "c:/Program Files/Apache Group/Apache2" + altındadır. (Bilgi: Windows için bile, Apache httpd yapılandırma + dosyalarında dosya yolu belirtilirken tersbölü değil normal bölü + karakterleri kullanılır.) Site alanı ise sunucu tarafından istemciye + sunulan dizin ağacıdır. Yani, site alanı içindeki /dir/ + dizini, Apache httpd’nin Unix üzerinde dosya sistemine öntanımlı olarak + kurulduğu yer göz önüne alınarak, dosya sistemindeki + /usr/local/apache2/htdocs/dir/ dizinine karşılıktır. Site + sayfaları veritabanlarından veya başka yerlerden devingen olarak + üretilebildiğinden site alanlarının doğrudan dosya sistemine eşlenmesi + gerekli değildir.

+ +

Dosya Sistemi Taşıyıcıları

+ +

<Directory> + ve <Files> + taşıyıcıları, düzenli ifade karşılıkları + ile beraber, yönergeleri dosya sisteminin parçalarına uygularlar. Bir + <Directory> bölümü + içindeki yönergeler belli bir dosya sistemi dizinine ve onun alt + dizinlerine uygulanır. Aynı etki .htaccess + dosyaları kullanılarak da sağlanabilir. Örneğin aşağıdaki + yapılandırmada, /var/web/dir1 dizini ve alt dizinlerinde + dizin içeriğinin listelenmesi etkin kılınmaktadır.

+ +

<Directory "/var/web/dir1">
+  Options +Indexes
+</Directory>

+ + +

Bir <Files> bölümü + içindeki yönergeler, hangi dizinde bulunduğuna bakılmaksızın ismi + belirtilen dosyalara uygulanır. Örneğin, aşağıdaki yapılandırma + yönergeleri yapılandırma dosyasının ana bölümüne yerleştirildiği takdirde + gizli.html isimli dosyalara nerede bulunursa bulunsun + erişime izin vermeyecektir.

+ +

<Files "gizli.html">
+  Require all denied
+</Files>

+ + +

Dosya sisteminin belli bir yerindeki belli dosyalarla ilgili yaptırımlar + için <Files> ve + <Directory> bölümleri + birlikte kullanılabilir. Örneğin, aşağıdaki yapılandırma + /var/web/dir1/gizli.html, + /var/web/dir1/subdir2/gizli.html, + /var/web/dir1/subdir3/gizli.html ve + /var/web/dir1/ altında bulunabilecek diğer tüm + gizli.html dosyalarına erişimi yasaklar.

+ +

<Directory "/var/web/dir1">

+  <Files "gizli.html">

+    Require all denied
+  </Files>

+</Directory>

+ + + +

Site Alanı Taşıyıcıları

+ +

<Location> yönergesi + ve yönergenin düzenli ifade karşılığı + site alanındaki içerik için yapılandırmayı değiştirir. Örneğin aşağıdaki + yapılandırma, /gizli ile başlayan URL yollarına erişimi + engeller. Özellikle, http://siteniz.mesela.dom/gizli, + http://siteniz.mesela.dom/gizli123 ve + http://siteniz.mesela.dom/gizli/dir/dosya.html + istekleri yanında /gizli ile başlayan diğer isteklere de + uygulanır.

+ +

<LocationMatch "^/gizli">
+    Require all denied
+</LocationMatch>

+ + +

Dosya sistemi ile etkileşime girmeyen herşey için + <Location> + yönergesi gerekir. Aşağıdaki örnekte, belli bir URL’nin + mod_status modülü tarafından sağlanan bir dahili + Apache eylemcisine nasıl eşlenebileceği gösterilmiştir. Bu örnek + için dosya sisteminde server-status adında bir dosya + veya dizin bulunması gerekli değildir.

+ +

<Location "/server-status">
+    SetHandler server-status
+</Location>

+ + + +

Site Alanında Çakışma

Belli bölümler ve yönergeler değerlendirilirken çakışan iki URL bir URL + olarak dikkate alınır. <Location> yönergesi için bu şöyle olurdu:

+ +

<Location "/foo">
+</Location>
+<Location "/foo/bar">
+</Location>

+ + +

Diğer yandan <Takma + adlar> tam tersi eşlenir:

+ +

Alias "/foo/bar" "/srv/www/uncommon/bar"
+Alias "/foo"     "/srv/www/common/foo"

+ + +

Aynısı ProxyPass + yönergeleri için de geçerlidir:

+ +

ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
+ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On

+ + + +

Dosya Adı Şablonları ve Düzenli İfadeler

+ + +

<Directory>, + <Files> ve + <Location> + yönergelerinde, Standart C kütüphanesindeki fnmatch + işlevindeki gibi kabuk tarzı dosya ismi kalıpları kullanılabilir. "*" + karakteri herhangi bir karakter dizisi ile eşleşirken "?" karakteri tek + tek karakterlerle ve "[seq]" kalıbı ise seq içindeki + her karakterle eşleşir. "/" karakteri her hangi bir kalıp karakteri ile + eşleşmez; açıkça belirtilmesi gerekir.

+ +

Daha esnek bir eşleşmenin gerekli olduğu durumlar için her taşıyıcının + bir düzenli ifade karşılığı vardır. <DirectoryMatch>, <FilesMatch> ve <LocationMatch> yönergelerinde gerekli + eşleşmeleri seçmek için perl uyumlu düzenli + ifadelerin kullanımına izin verilir. Ayrıca, yönergelerin + uygulanışının düzenli ifade bölümleri kullanılarak nasıl + değiştirileceğini öğrenmek için, aşağıda, yapılandırmanın + katıştırılmasıyla ilgili bölüme de bakınız.

+ +

Tüm kullanıcı dizinlerine ilişkin yapılandırmayı değiştirmek için dosya + ismi kalıpları şöyle kullanılabilirdi:

+ +

<Directory "/home/*/public_html">
+    Options Indexes
+</Directory>

+ + +

Düzenli ifade bölümleri kullanarak çeşitli türlerdeki resim dosyalarına + erişimi bir defada yasaklayabiliriz:

+ +

<FilesMatch "\.(?i:gif|jpe?g|png)$">
+    Require all denied
+</FilesMatch>

+ + +

İsimli gruplar ve geriye başvurular içeren düzenli + ifadeler ortama eklenirken ilgili isimler büyük harfli yapılır. Böylece, + URL'lere ve dosya yolları elemanlarına ifadelerin + içinden ve mod_rewrite gibi modüllerden başvurmak + mümkün olur.

+ +

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

+ + + +

Mantıksal İfadeler

<If> yönergesi bir + mantıksal ifade olarak belirtilebilen bir kurala bağlı olarak + yapılandırmayı değiştirebilir. Örneğin, aşağıdaki yapılandırmada, + HTTP Referer başlığı "http://www.example.com/" ile + başlamıyorsa erişimi yasaklar.

+ +

<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
+    Require all denied
+</If>

+ + + +

Ne, Ne Zaman Kullanılır?

Dosya sistemi taşıyıcıları ile site alanı taşıyıcıları arasında seçim + yapmak aslında oldukça kolaydır. Dosya sisteminde bulunan nesnelere + uygulanacak yönergeler için daima <Directory> veya <Files> kullanılır. Dosya sisteminde bulunmayan nesnelere + (bir sayfanın bir veritabanı tarafından üretilmesi gibi) uygulanacak + yönergeler için ise <Location> kullanılır.

+ +

Dosya sistemindeki nesnelere erişimi kısıtlarken asla + <Location> + kullanmamak önemlidir. Bunun sebebi farklı site alanı konumlarının + (URL’ler) aynı dosya sistemi konumuna eşlenebilmesi dolayısıyla + kısıtlamalarınızın etrafından dolaşılabilmesine izin vermesidir. + Örneğin, aşağıdaki yapılandırmayı ele alalım:

+ +

<Location "/dir/">
+    Require all denied
+</Location>

+ + +

http://siteniz.mesela.dom/dir/ için bir istek yapılmışsa + bu doğru çalışacaktır. Fakat dosya sistemi harf büyüklüğüne duyarsızsa + ne olacak? Kısıtlamanız, istek + http://siteniz.mesela.dom/DIR/ + şeklinde yapılarak kolayca geçersiz kılınabilir. Halbuki <Directory> yönergesi isteğin + nasıl yapıldığına bakılmaksızın bu konumdan sunulan her türlü içeriğe + uygulanacaktı. (Dosya sistemi bağlarıyla bu da aşılabilir. Sembolik + bağlar kullanılarak aynı dizin dosya sisteminin bir çok yerine + yerleştirilebilir. <Directory> yönergesi dosya yolunu sıfırlamaksızın sembolik + bağları izleyecektir. Bu bakımdan, en yüksek seviyede güvenlik için uygun + Options yönergesi ile sembolik + bağların izlenmesi devredışı bırakılabilir.)

+ +

Belki de siz sırf harf büyüklüğüne duyarlı bir dosya sistemi + kullanıyorsunuz diye böyle uygulamalara ihtiyacınız olmadığını düşünüyor + olabilirsiniz, fakat aynı site alanını çok sayıda dosya sistemi konumuna + eşleyecek daha bir sürü yol bulunduğunu unutmayınız. Bu bakımdan dosya + sisteminde yapacağınız kısıtlamalarda daima dosya sistemi taşıyıcılarını + kullanmalısınız. Bununla birlikte bu kuralın da bir istisnası vardır. + Yapılandırma kısıtlamalarının bir <Location "/"> bölümü + içine koyulması, bu bölüme konan yönergelerin etki alanının belli bir URL + ile sınırlı olmaması nedeniyle mükemmelen güvenlidir.

+ + +

Bölüm iç içeliği

Bazı bölüm türleri başka bölüm türlerinin içinde olabilir. Bir yandan, + <Files> bölümü + <Directory> bölümünün + içinde bulunabilirken diğer yandan bir <If> bölümü <Directory>, <Location> ve <Files> bölümlerinde bulunabilir fakat + başka bir <If> bölümünün + içinde bulunamaz. Bu bölümlerin düzenli ifadeli türevleri de benzer tarzda + davranır.

+ +

İç içe bölümler, aynı türdeki iç içe olmayan bölümlerin sonrasına + yerleştirilir.

+ + +

Sanal Konaklar

+ +

<VirtualHost> + taşıyıcısının içinde belli bir konağa uygulanan yönergeler bulunur. + Aynı makinede çok sayıda konağı farklı yapılandırmalarla sunuyorsanız + bu taşıyıcı çok işinize yarar. Daha fazla bilgi için + Sanal Konak Belgeleri bölümüne bakınız.

Vekil

<Proxy> + ve <ProxyMatch> + taşıyıcıları, sadece belli bir URL ile eşleşen mod_proxy + vekil sunucusu üzerinden erişilen sitelere uygulanan yapılandırma + yönergelerini bulundururlar. Örneğin aşağıdaki yapılandırma + example.com sitesine erişim için vekil sunucunun + sadece ağdaki bazı kullanıcılar tarafından kullanılabilmesini sağlayacaktır.

+ +

<Proxy "http://www.example.com/*">
+    Require host bizimki.example.com
+</Proxy>

+ +

Hangi Yönergelere İzin Veriliyor?

Hangi yönergelere hangi yapılandırma bölümlerinde izin verildiğini + öğrenmek için yönerge bağlamına bakınız. <Directory> bölümlerinde + izin verilen herşeye sözdizimsel olarak ayrıca + <DirectoryMatch>, + <Files>, + <FilesMatch>, + <Location>, + <LocationMatch>, + <Proxy> + ve <ProxyMatch> + bölümlerinde de izin verilir. Yine de bazı istisnai durumlar + mevcuttur:

+ +

AllowOverride yönergesi sadece + <Directory> + bölümlerinde çalışır.
Options yönergesinin + FollowSymLinks ve SymLinksIfOwnerMatch + seçenekleri sadece <Directory> bölümlerinde veya .htaccess + dosyalarında çalışır.
Options yönergesi + <Files> ve + <FilesMatch> + bölümlerinde kullanılamaz.

Bölümler Nasıl Katıştırılır?

+ +

Yapılandırma bölümleri belli bir sıra ile uygulanır. Yapılandırma + yönergelerinin yorumlanışı üzerinde önemli etkilere sahip olabilmesi + nedeniyle neyin ne zaman çalıştığını anlamak çok önemlidir.

+ +

Yapılandırma bölümlerinin katıştırılma sırası şöyledir:

+ +

<Directory> (düzenli ifadeler hariç) + ve .htaccess aynı anda işleme sokulur + (.htaccess ile eğer izin verilmişse <Directory> içindeki bazı + yönergeler geçersiz kılınabileceği için).
<DirectoryMatch> + (ve <Directory "~">).
<Files> ve + <FilesMatch> aynı anda + işleme sokulur.
<Location> + ve <LocationMatch> + aynı anda işleme sokulur.
<If> bölümleri, + önceki bağlamlardan herhangi birinin içine alınmış olsalar bile. + +

+ +

Bazı önemli durumlar:

<Directory> + bölümündekiler hariç, her grup, yapılandırma dosyasında bulundukları + sıraya göre işleme sokulurlar. Örneğin, 4. grupta /foo/bar için yapılan + bir istek <Location "/foo/bar"> ve <Location + "/foo"> bölümleriyle de eşleşir ve bunlar yapılandırma + dosyalarında bulundukları sıraya göre değerlendirilir.
Yukarıda 1. grup olan <Directory> bölümü en kısa dizin elemanından en uzun + dizin elemanına doğru işleme sokulur. Yani, örneğin, <Directory + "/var/web/dir"> bölümü <Directory + "/var/web/dir/subdir"> bölümünden önce işleme sokulacaktır.
Eğer aynı dizin için birden fazla <Directory> bölümü varsa bunlar yapılandırma + dosyasında bulundukları sıraya göre işleme sokulurlar.
Include yönergeleri ile + yapılandırmaya dahil edilen dosyaların içerikleri Include yönergesinin bulunduğu yere konulduktan + sonra işleme sokulurlar.
<VirtualHost> + bölümlerinin içindeki bölümler, sanal konak tanımı dışındaki + karşılıklarından sonra uygulanırlar. Bu yöntemle ana sunucu + yapılandırmasındaki tanımlar geçersiz kılınabilir
İstek mod_proxy tarafından sunulduğu takdirde, + <Proxy> taşıyıcısı + işlem sırasında <Directory> taşıyıcısının yerini alır.
katıştırma düzeni üzerindeki etkisi nedeniyle, ilgili yapılandırma + yönergelerini <If>'in + içinde ve dışında karıştırırken dikkatli olunmalıdır. Doğrudan + <Else> kullanımının + yardımı olabilir.
.htaccess içinde <If> kullanıldığında, üst dizindeki sarmalanmış + yönergeler, alt dizinde sarmalanmamış yönergelerden sonra + birleştirilir.

+ +

Bazı Teknik Bilgiler

+ Aslında, isim dönüşüm aşamasından (Aliases ve + DocumentRoots, URL’leri dosya isimlerine eşlemek için + kullanılırken) hemen önce uygulanan bir + <Location>/<LocationMatch> dizisi + vardır. Bu dizinin sonuçları isim dönüşüm aşaması tamamlandıktan sonra + tamamen elden çıkarılır. +

+ +

Modüllerle + yapılandırma bölümleri arasındaki ilişki

+ +

Yapılandırma bölümlerini okurken örneğin mod_rewrite + gibi belli modüllerin yönergelerinin bu bölümlere nasıl katılacağı ve + ne zaman nasıl işleneceği gibi sorular sıkça aklımızdan geçer. Bunun + belli bir yanıtı yoktur ve biraz temel bilgi gerektirir. Her httpd + modülü yapılandırmasını kendi yönetir ve httpd.conf içindeki + yönergelerinin her biri belli bir bağlamdaki bir yapılandırmayı + belirtir. httpd bir komutu okunduğu sırada çalıştırmaz.

+ +

Çalışma anında, httpd çekirdeği geçerli isteğe hangilerinin + uygulanacağını belirlemek için yukarıda açıklanan sırada tanımlı + yapılandırma bölümlerini tekrar tekrar okur. Eşleşen ilk bölümün bu + istek için geçerli yapılandırmayı içerdiği varsayılır. Eğer alt + bölümlerden biri de eşleşmişse bu bölümlerde yönergeleri bulunan her + modüle yapılandırmasını iki bölüm arasında katıştırma şansı verilir. + Sonuç üçüncü bir yapılandırma olup işlem bütün yapılandırma bölümleri + değerlendirilene kadar sürer.

+ +

Yukarıdaki adımların ardından HTTP isteğiyle ilgili "asıl" işlem + başlar: her modül ondan istenen görevleri gerçekleştirme şansına sahip + olur. Nasıl davranacaklarını belirlemek için kendilerinin katıştırılmış + son yapılandırmalarını http çekirdeğinden alabilirler.

+ +

Sürecin tamamı bir örnekle görselleştirilebilir. Aşağıdaki örnekte + belli bir HTTP başlığını ayarlamak için mod_headers + modülünün Header yönergesi + kullanılmıştır. /example/index.html isteği için httpd + CustomHeaderName başlığına hangi değeri atayacaktır? +

<Directory "/">
+    Header set CustomHeaderName bir
+    <FilesMatch ".*">
+        Header set CustomHeaderName yedi
+    </FilesMatch>
+</Directory>
+
+<Directory "/example">
+    Header set CustomHeaderName iki
+</Directory>

+ +

Directory "/" eşleşir ve ilk yapılandırma + olarak CustomHeaderName başlığı bir + değeriyle oluşturulur.
Directory "/example" eşleşir ve + mod_headers modülünün koduna göre bir katıştırma + durumundan yeni değer eskiyi geçersiz kılacağından yeni bir + yapılandırma ile CustomHeaderName başlığının değeri + iki yapılır.
FilesMatch ".*" eşleşir ve başka bir + katıştırma fırsatı doğar: CustomHeaderName başlığının + değeri yedi yapılır.
Neticede HHP isteğinin sonraki adımlarında + mod_headers çağrılıp yedi değeri + atanmış CustomHeaderName başlığını işleme sokması + istenecektir. mod_headers normalde işini yapmak + için bu yapılandırmayı kullanacaktır. Fakat bundan, bir yönergenin + gerekli olmaması veya kullanımdan kaldırılması ve benzeri nedenlerle + yapılandırmada iptal edilmesi gibi daha karmaşık bir eylemi bir + modülün gerçekleştiremeyeceği anlamı çıkarılmamalıdır.

+ +

Directory ile aynı katıştırma sırasından dolayı + bu durum .htaccess için de geçerlidir. Burada anlaşılması gereken husus, + Directory ve FilesMatch + gibi yapılandırma bölümlerinin Header veya RewriteRule gibi modüle özgü + yönergelerle karşılaştırılmamasıdır, çünkü bunlar farklı seviyelerde + işlem görür. +

+ + +

Bazı Örnekler

+ +

Aşağıdaki yapay örnekte katıştırma sırası gösterilmiştir. Hepsinin aynı + isteğe uygulandığı varsayımıyla, bu örnekteki yönergeler A > B > C + > D > E sırasıyla uygulanacaktır.

+ +

<Location "/">
+    E
+</Location>
+
+<Files "f.html">
+    D
+</Files>
+
+<VirtualHost *>
+    <Directory "/a/b">
+        B
+    </Directory>
+</VirtualHost>
+
+<DirectoryMatch "^.*b$">
+    C
+</DirectoryMatch>
+
+<Directory "/a/b">
+    A
+</Directory>

+ + +

Daha somut bir örnek olarak aşağıdakini ele alalım. + <Directory> + bölümlerindeki erişim sınırlamaları ne olursa olsun <Location> bölümü son olarak + değerlendirmeye alınacak ve sunucuya sınırsız erişim verecektir. + Başka bir deyişle, katıştırma sırası önemlidir, bu nedenle dikkatli + olmalısınız!

+ +

<Location "/">
+    Require all granted
+</Location>
+
+# Alooo!  Bu <Directory> bölümünün hiçbir hükmü yok.
+<Directory "/">
+    <RequireAll>
+        Require all granted
+        Require not host kkadam.example.com
+    </RequireAll>
+</Directory>

+ + + + +