Apache HTTP Sunucusu Sürüm 2.2
Açıklama: | Apache HTTP Sunucusunda daima mevcut olan çekirdek özellikler |
---|---|
Durum: | Çekirdek |
Açıklama: | Bir protokolün dinleyici soketleri için en iyilemeleri ayarlar |
---|---|
Sözdizimi: | AcceptFilter protocol kabul_süzgeci |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache 2.1.5 ve sonrasında mevcuttur. |
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:
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 ön tanı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.
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:
AcceptFilter nntp none
Protocol
Açıklama: | Dosya isminden sonra belirtilen yol verisini kabul veya reddeder. |
---|---|
Sözdizimi: | AcceptPathInfo On|Off|Default |
Öntanımlı: | AcceptPathInfo Default |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache 2.0.30 ve sonrasında mevcuttur. |
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
/test/here.html/more
şeklindeki istekler bir 404 (Nesne
bulunamadı) hatasıyla sonuçlanır.On
/test/here.html/more
şeklindeki
istekler, /test/here.html
geçerli bir dosya olduğu
takdirde kabul edilir.Default
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>
Açıklama: | Dağıtık yapılandırma dosyasının ismi belirtilir. |
---|---|
Sözdizimi: | AccessFileName filename [filename] ... |
Öntanımlı: | AccessFileName .htaccess |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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.
Açıklama: | Bir yanıtın içerik türü text/plain veya
text/html olduğunda eklenecek öntanımlı karakter kümesi
parametresini belirler. |
---|---|
Sözdizimi: | AddDefaultCharset On|Off|karküm |
Öntanımlı: | AddDefaultCharset Off |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
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 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.
Açıklama: | Belli bir MIME türüne bir çıktı süzgeci atar. |
---|---|
Sözdizimi: | AddOutputFilterByType süzgeç[;süzgeç...]
MIME-türü [MIME-türü] ... |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | 2.0.33 ve sonrasında mevcuttur; Apache 2.1 ve sonrasında kullanımı önerilmemektedir. |
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.
AddOutputFilterByType DEFLATE text/html text/plain
İç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.
<Location /cgi-bin/>
Options Includes
AddOutputFilterByType INCLUDES;DEFLATE text/html
</Location>
Süzgeçlerin AddOutputFilterByType
ile etkin
kılınması bazı durumlarda kısmen bazılarında da tamamen başarısızlığa
uğrayabilir. Örneğin, MIME türü
saptanamadığı takdirde hiçbir süzgeç uygulanmaz ve DefaultType
aynı olsa bile son çare olarak
DefaultType
ayarlarına geri
dönülür.
Bununla birlikte, süzgeçlerin uygulanacağına emin olmak isterseniz,
bir kaynağa içerik türünü örneğin, AddType
veya
ForceType
ile açıkça
atayabilirsiniz. Ayrıca, içerik türünü (bir nph-olmayan) CGI betiği
içinde ayarlamak da bu güvenceyi sağlar.
Açıklama: | Kodlanmış dosya yolu ayracı içeren URL’lere izin verilip verilmeyeceğini belirler. |
---|---|
Sözdizimi: | AllowEncodedSlashes On|Off|NoDecode |
Öntanımlı: | AllowEncodedSlashes Off |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache 2.0.46 ve sonrasında mevcuttur. NoDecode seçeneği 2.2.18 ve sonrasında kullanılabilir. |
AllowEncodedSlashes
yönergesi
PATH_INFO
içinde 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ğeri ile böyle URL'ler bir 404 (bulunamadı)
hatasıyla reddedilir.
On
değeri ile böyle URL'ler kabul edilir ve kodlanmış bölü
çizgileri diğer kodlanmış karakterler gibi çözümlenir.
NoDecode
değeri ile böyle URL'ler kabul edilir fakat
kodlanmış bölü çizgileri çözümlenmeden bırakılır.
AllowEncodedSlashes
On
, çoğunlukla
PATH_INFO
ile bir arada kullanıldığı zaman
kullanışlıdır.
PATH_INFO
içinde kodlanmış bölü çizgilerini kullanmaktan
başka çare yoksa bir güvenlik ölçütü olarak NoDecode
kullanmanız şiddetle tavsiye edilir. Bölü çizgilerinin çözümlenmeye
çalışılması yanlış yol çözümlemesi gibi güvenilmez bir olasılığa yol
açabilir.
Açıklama: | .htaccess dosyalarında bulunmasına izin verilen
yönerge türleri belirtilir. |
---|---|
Sözdizimi: | AllowOverride All|None|yönerge-türü
[yönerge-türü] ... |
Öntanımlı: | AllowOverride All |
Bağlam: | dizin |
Durum: | Çekirdek |
Modül: | core |
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.
AllowOverride
yönergesi, <Location>
, <DirectoryMatch>
veya <Files>
bölümlerinde değil,
sadece düzenli ifade içermeyen <Directory>
bölümlerinde geçerlidir.
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:
AuthDBMGroupFile
,
AuthDBMUserFile
,
AuthGroupFile
,
AuthName
,
AuthType
,
AuthUserFile
,
Require
ve benzeri yetkilendirme yönergelerinin kullanımını izin
verilir.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.
AddDescription
,
AddIcon
,
AddIconByEncoding
,
AddIconByType
,
DefaultIcon
,
DirectoryIndex
,
FancyIndexing
,
HeaderName
,
IndexIgnore
,
IndexOptions
,
ReadmeName
yönergelerinin ve benzerlerinin kullanımına izin
verilir.Allow
,
Deny
ve
Order
yönergelerinin kullanımına izin verilir.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.
.htaccess dosyalarında kullanılabilecek seçenekler bu yönergeyle
sınırlanabileceği gibi miras alınmış bir seçenek olarak, bağıntısız
sözdizimi kullanılarak iptal edilebilen herhangi bir seçenek de
Options
yönergesi ile dolaylı
olarak iptal edilmiş olacaktır. Başka bir deyişle, bu mekanizma
evvelce etkisiz kılınmış bir seçeneğin etkin kılınmasını
sağlamayacaktır.
Örnek:
AllowOverride AuthConfig Indexes
Bu örnekte AuthConfig
ve Indexes
grubundaki
yönergeler bir dahili sunucu hatasına yol açmayacaktır.
Güvenlik ve başarımı arttırmak için <Directory />
bloğu içinde AllowOverride
yönergesine None
dışında bir değer atamayın. Böyle yapmak yerine bir .htaccess
dosyası yerleştirmeyi düşündüğünüz dizine ait bir
<Directory>
bloğu olması daha iyidir.
Açıklama: | HTTP kimlik doğrulamasında kullanmak için yetki alanı ismi |
---|---|
Sözdizimi: | AuthName yetki-alanı |
Bağlam: | dizin, .htaccess |
Geçersizleştirme: | AuthConfig |
Durum: | Çekirdek |
Modül: | core |
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 "Top Secret"
AuthName
için belirtilen dizge çoğu tarayıcı tarafından
parola diyaloğunda gösterilir.
Açıklama: | Kullanıcı kimlik doğrulaması türü |
---|---|
Sözdizimi: | AuthType Basic|Digest |
Bağlam: | dizin, .htaccess |
Geçersizleştirme: | AuthConfig |
Durum: | Çekirdek |
Modül: | core |
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.
Açıklama: | CGI betik yorumlayıcısını saptama tekniğini belirler. |
---|---|
Sözdizimi: | CGIMapExtension cgi-yolu .uzantı |
Bağlam: | dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Sadece NetWare’de geçerlidir. |
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.
Açıklama: | Content-MD5 HTTP yanıt başlıklarının üretimini
etkin kılar. |
---|---|
Sözdizimi: | ContentDigest On|Off |
Öntanımlı: | ContentDigest Off |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | Options |
Durum: | Çekirdek |
Modül: | core |
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:
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
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.
Açıklama: | Sunucunun MIME türünü saptayamadığı durumda göndereceği MIME içerik türünü belirler. |
---|---|
Sözdizimi: | DefaultType MIME-türü|none |
Öntanımlı: | DefaultType text/plain |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | none değeri Apache 2.2.7 ve sonrasında mevcuttur.
|
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,
DefaultType image/gif
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
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.
Açıklama: | Sadece ismi belirtilen dosya sistemi dizinine ve bunun altdizinleri ile içeriklerine uygulanacak bir yönerge grubunu sarmalar. |
---|---|
Sözdizimi: | <Directory dizin-yolu>
... </Directory> |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
<Directory>
ve
</Directory>
sadece ismi belirtilen dosya sistemi
dizini ve bunun altdizinleri ile bu dizinlerin içeriklerine 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-yolu argümanlarını belirtirken dikkatli
olmalısınız: Apache’nin dosyalara erişmekte kullandığı dosya sistemi
yolu ile bire bir eşleşmelidir. Belli bir
<Directory>
dizinine uygulanan yönergeler, aynı
dizine farklı bir yoldan, örneğin başka bir sembolik bağ üzerinden
erişilen dosyalara uygulanmayacaktır.
~
karakterine ek olarak düzenli
ifadeler de kullanılabilir. Örnek:
<Directory ~ "^/www/[0-9]{3}">
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)./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 ~ "public_html/.*">
# ... 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ı Apache
erişiminin Allow from All
oluşuna dikkat ediniz. Bunu şöyle
bir blokla değiştirmeniz,
<Directory />
Order Deny,Allow
Deny from All
</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 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.
Açıklama: | Bir düzenli ifade ile eşleşen dosya sistemi dizininde ve bunun altdizinlerinde uygulanacak bir yönerge grubunu sarmalar. |
---|---|
Sözdizimi: | <DirectoryMatch düzifd>
... </DirectoryMatch> |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
<DirectoryMatch>
and
</DirectoryMatch>
yönergeleri <Directory>
gibi sadece ismi
belirtilen dosya sistemi dizinine ve bunun altdizinleri ile
bunların içerdiği dosyalara 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}">
yönergesi /www/
içindeki üç rakamdan oluşan dizinlerle
eşleşecektir.
Satırsonu karakteri ($) bu yönerge ile eşleşemez.
<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.Açıklama: | İstemciye görünür olan ana belge ağacının kök dizinini belirler. |
---|---|
Sözdizimi: | DocumentRoot dizin-yolu |
Öntanımlı: | DocumentRoot /usr/local/apache/htdocs |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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://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.
Açıklama: | Teslimat sırasında okunacak dosyalar için bellek eşlemeyi etkin kılar. |
---|---|
Sözdizimi: | EnableMMAP On|Off |
Öntanımlı: | EnableMMAP On |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
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:
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-dosya-yolu">
EnableMMAP Off
</Directory>
Açıklama: | Dosyaların istemciye tesliminde çekirdeğin dosya gönderme desteğinin kullanımını etkin kılar. |
---|---|
Sözdizimi: | EnableSendfile On|Off |
Öntanımlı: | EnableSendfile On |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | 2.0.44 ve sonrasında mevcuttur. |
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:
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:
EnableSendfile Off
Bu özellik, sadece bir NFS veya SMB dosya sistemi üzerinde sunulan dosyaları kapsamak üzere şu şekilde kolayca kapatılabilir:
<Directory "/path-to-nfs-files">
EnableSendfile Off
</Directory>
EnableSendfile
yönergesinin .htaccess ve diziniçi
yapılandırmalarının mod_disk_cache
tarafından
desteklenmediğini lütfen aklınızdan çıkarmayın.
EnableSendfile
yönergesinin sadece küresel
tanımları hesaba katılır.
Açıklama: | Bir hata durumunda sunucunun istemciye ne döndüreceğini belirler. |
---|---|
Sözdizimi: | ErrorDocument hata-kodu belge |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Metin iletilerini tırnak içine alma sözdizimi Apache 2.0’da farklıdır. |
Bir sorun çıktığında veya hata oluştuğunda Apache şu dört işlemden birini yapacak şekilde yapılandırılabilir:
İ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:
ErrorDocument 500 http://hata.meselae.dom/cgi-bin/dnmci
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Kusura bakmayın, bugün hizmet veremiyoruz."
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 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’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.
mod_proxy
kullanıyorsanız, gerekirse vekili olunan
sunucu yararına özel hata iletileri üretmenizi sağlayabilen ProxyErrorOverride
yönergesini etkin
kılabilirsiniz. Bu yönergeyi etkinleştirmezseniz Apache vekaleten
sunulan içerik için özel hata sayfaları üretmeyecektir.
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.
Açıklama: | Sunucunun hata günlüğünü tutacağı yeri belirler. |
---|---|
Sözdizimi: | ErrorLog dosya-yolu|syslog[:oluşum] |
Öntanımlı: | ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows ve
OS/2) |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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 edinmek için borulu günlükler ile ilgili ek bilgilere 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.
ErrorLog syslog:user
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.
Unix-dışı platformlarda dosya yolunu girerken, platform ters bölü çizgilerini desteklese bile normal bölü çizgileri kullanmaya özen göstermelisiniz. Genel olarak, dosya yollarını belirtirken yapılandırma dosyası boyunca normal bölü çizgisi kullanmak her zaman daha iyidir.
Açıklama: | ETag Duruk dosyalar için HTTP yanıt başlığını
oluşturmakta kullanılacak dosya özniteliklerini belirler. |
---|---|
Sözdizimi: | FileETag bileşen ... |
Öntanımlı: | FileETag INode MTime Size |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
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.) 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:
FileETag INode MTime Size
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.
mod_dav_fs
kullanılıyorsa öntanımlı ayarları
değiştirmeyiniz. mod_dav_fs
, koşullu isteklerde
ETag
karşılaştırmaları yapabilmek için
INode MTime Size
yapılandırmasını kullanır. Eğer
ETag
ayarı FileETag
yönergesi
kullanılarak değiştirilirse koşullu istekler gerektiği gibi yerine
getirilemez.
mod_include
tarafından çözümlenen yanıtlar için bie ETag
üretilmez. Bunun sebebi, gömülü SSI yönergeleri ile duruk dosyanın
boyutunda, değişiklik zamanında ve dosya düğümünde bir değişiklik
olmaksızın yanıt öğesinin değişebilmesidir.
Açıklama: | Dosya isimleriyle eşleşme halinde uygulanacak yönergeleri içerir. |
---|---|
Sözdizimi: | <Files dosya-adı> ... </Files> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
<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 "cat.html"> # cat.html dosyasına uygulanacaklar buraya. </Files> <Files "?at.*"> # cat.html, bat.html, hat.php ve benzerlerine uygulanacaklar buraya. </Files>
~
imine ek olarak düzenli ifadeler de kullanılabilir. Örneğin
<Files ~ "\.(gif|jpe?g|png)$">
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.
Açıklama: | Düzenli ifadelerin dosya isimleriyle eşleşmesi halinde uygulanacak yönergeleri içerir. |
---|---|
Sözdizimi: | <FilesMatch düzifd> ... </FilesMatch> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
<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)$">
satırı en bilinen resim dosyası biçimleriyle eşleşecektir.
Açıklama: | Bütün dosyaların belirtilen MIME içerik türüyle sunulmasına sebep olur. |
---|---|
Sözdizimi: | ForceType MIME-türü|None |
Bağlam: | dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache 2.0’da core modülüne taşındı. |
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:
ForceType image/gif
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:
# 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>
Açıklama: | gmon.out profilleme verisinin yazılacağı dizin. |
---|---|
Sözdizimi: | GprofDir /tmp/gprof/|/tmp/gprof/% |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Sunucu gprof profilleme desteği ile derlendiği takdirde
GprofDir
yönergesi, süreç çıkarken
gmon.out
dosyalarının belirtilen dizine yazılmasını sağlar.
Eğer değistirge yüzde simgesi (%) ile bitirilirse her süreç kimliği (PID)
için ayrı bir aldizin oluşturulur.
Bu yönerge sadece prefork
MPM ile çalışır.
Açıklama: | İstemci IP adresleri üzerinde DNS sorgularını etkin kılar. |
---|---|
Sözdizimi: | HostnameLookups On|Off|Double |
Öntanımlı: | HostnameLookups Off |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
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.
Açıklama: | Başlatma sırasında bir doğruluk sınamasından sonra işleme sokulacak yönergeleri sarmalar. |
---|---|
Sözdizimi: | <IfDefine [!]parametre-adı> ...
</IfDefine> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
<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ı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:
httpd -DReverseProxy -DUseCache -DMemCache ...
# httpd.conf
<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 disk_cache_module modules/mod_disk_cache.so
</IfDefine>
</IfDefine>
</IfDefine>
Açıklama: | Belli bir modülün varlığına veya yokluğuna göre işleme sokulacak yönergeleri sarmalar. |
---|---|
Sözdizimi: | <IfModule [!]modül-dosyası|modül-betimleyici> ...
</IfModule> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Modül betimleyiciler 2.1 sürümünde ve sonrası için geçerlidir. |
<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:
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.
<IfModule>
bölümlerine yerleştirilmeleri
gerekmez.Açıklama: | Sunucu yapılandırma dosyalarının başka dosyaları içermesini sağlar. |
---|---|
Sözdizimi: | Include dosya-yolu|dizin-yolu |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Dosya kalıbıyla eşleşme 2.0.41 ve sonrasında mevcuttur. |
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:
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
Açıklama: | HTTP kalıcı bağlantılarını etkin kılar |
---|---|
Sözdizimi: | KeepAlive On|Off |
Öntanımlı: | KeepAlive On |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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.
Açıklama: | Bir kalıcı bağlantıda sunucunun bir sonraki isteği bekleme süresi |
---|---|
Sözdizimi: | KeepAliveTimeout saniye |
Öntanımlı: | KeepAliveTimeout 5 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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.
Açıklama: | Erişimi sınırlanacak HTTP yöntemleri için erişim sınırlayıcıları sarmalar. |
---|---|
Sözdizimi: | <Limit yöntem [yöntem] ... > ...
</Limit> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
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.
<Limit>
bölümü yerine daima bir <LimitExcept>
bölümünü tercih
etmelisiniz, çünkü <LimitExcept>
bölümü belirtilen yöntemler dışında kalanlara
erişim koruması sağlar.Açıklama: | İsimleri belirtilenler dışında kalan HTTP yöntemleri için kullanılacak erişim sınırlayıcıları sarmalar. |
---|---|
Sözdizimi: | <LimitExcept yöntem [yöntem] ... > ...
</LimitExcept> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
<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>
Açıklama: | Dahili yönlendirmelerin ve istek içi isteklerin azami sayısını belirler. |
---|---|
Sözdizimi: | LimitInternalRecursion sayı [sayı] |
Öntanımlı: | LimitInternalRecursion 10 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache 2.0.47 ve sonrasında mevcuttur. |
Ö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.
LimitInternalRecursion 5
Açıklama: | İstemci tarafından gönderilen HTTP istek gövdesinin toplam uzunluğunu sınırlar. |
---|---|
Sözdizimi: | LimitRequestBody bayt-sayısı |
Öntanımlı: | LimitRequestBody 0 |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
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:
LimitRequestBody 102400
Açıklama: | İstemciden kabul edilecek HTTP isteği başlık alanlarının sayısını sınırlar. |
---|---|
Sözdizimi: | LimitRequestFields sayı |
Öntanımlı: | LimitRequestFields 100 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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:
LimitRequestFields 50
İsme dayalı sanal konaklar kullanılıyorsa bu yönergenin değeri,
bağlantının eşleştirildiği ilk NameVirtualHost
yönergesinden (listedeki ilk - öntanımlı - konak) alınır.
Açıklama: | İstemciden kabul edilecek HTTP isteği başlık uzunluğunu sınırlar. |
---|---|
Sözdizimi: | LimitRequestFieldSize bayt-sayısı |
Öntanımlı: | LimitRequestFieldSize 8190 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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
belirtme 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:
LimitRequestFieldSize 4094
İsme dayalı sanal konaklar kullanılıyorsa bu yönergenin değeri,
bağlantının eşleştirildiği ilk NameVirtualHost
yönergesinden (listedeki ilk - öntanımlı - konak) alınır.
Açıklama: | İstemciden kabul edilecek HTTP istek satırının uzunluğunu sınırlar. |
---|---|
Sözdizimi: | LimitRequestLine bayt-sayısı |
Öntanımlı: | LimitRequestLine 8190 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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 belirleme
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:
LimitRequestLine 4094
İsme dayalı sanal konaklar kullanılıyorsa bu yönergenin değeri,
bağlantının eşleştirildiği ilk NameVirtualHost
yönergesinden (listedeki ilk - öntanımlı - konak) alınır.
Açıklama: | Bir XML temelli istek gövdesinin uzunluğunu sınırlar. |
---|---|
Sözdizimi: | LimitXMLRequestBody bayt-sayısı |
Öntanımlı: | LimitXMLRequestBody 1000000 |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
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:
LimitXMLRequestBody 0
Açıklama: | İçerdiği yönergeler sadece eşleşen URL’lere uygulanır. |
---|---|
Sözdizimi: | <Location URL-yolu|URL> ...
</Location> |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
<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.
URL-yolu bileşeni aşağıdaki koşullardan herhangi birine uyduğu takdirde kapsanan yönergeler isteğe uygulanacaktır:
Aşağıdaki örnekte, sonda bir bölü çizgisi kullanılmamış olmasına rağmen /herhangi1, /herhangi1/ ve /herhangi1/dosya.txt dizgilerini içeren isteklere kapsanan yönergeler uygulanacak, ancak /herhangi1baskasi dizgisini içeren bir isteğe uygulanmayacaktır.
<Location /herhangi1>
...
Aşağıdaki örnekte, sonda bir bölü çizgisi kullanılmış olup, /herhangi2, /herhangi2/ ve /herhangi2/dosya.txt dizgilerini içeren isteklere kapsanan yönergeler uygulanacak, ancak /herhangi2baskasi dizgisini içeren bir isteğe uygulanmayacaktır.
<Location /private2/>
...
<Location>
ne zaman
kullanılmalı<Location>
yönergesini dosya sistemi
dışındaki içeriğe çeşitli yönergeler uygulamak için kullanın. Dosya
sisteminde bulunan içerik için <Directory>
ve <Files>
bölümlerini kullanın. Bunun istisnası,
sunucunun tamamına bir yapılandırma uygulamak için kolay bir yol olan
<Location />
kullanımıdı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,
<Location ~ "/(ek|hususi)/veri">
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:
<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .mesela.dom
</Location>
Bölü çizgisinin URL içinde bulunduğu yere bağlı olarak özel anlamları
vardır. Dosya sistemindeki çok sayıda yanyana kullanımının tek bir bölü
çizgisi olarak ele alındığı duruma alışkın olanlar olabilir (yani,
/home///foo
ile /home/foo
aynıdır). URL
uzayında bunun böyle olması gerekli değildir. Eğer çok sayıda bölü
çizgisini yanyana belirtmeniz gerekiyorsa <LocationMatch>
yönergesinde ve <Location>
yönergesinin düzenli ifadeli
kullanımında bunu açıkça belirtmeniz gerekir.
Örneğin, <LocationMatch ^/abc>
yönergesi
/abc
ile eşleşecek ama //abc
ile
eşleşmeyecektir. <Location>
yönergesinin düzenli ifade içermeyen kullanımındaki davranış vekil
isteklerinde kullanılana benzer ve doğrudan kaynağa yapılan (vekil
olmayan) isteklerde çok sayıda bölü çizgisi dolaylı olarak tek bir bölü
çizgisiyle eşleşecektir. Örneğin, <Location
/abc/def>
belirtirseniz ve istek /abc//def
şeklinde olursa bu ikisi eşleşir.
Açıklama: | İçerdiği yönergeler sadece düzenli ifadelerle eşleşen URL’lere uygulanır. |
---|---|
Sözdizimi: | <LocationMatch
düzifade> ... </LocationMatch> |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
<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,
<LocationMatch "/(ek|hususi)/veri">
yönergesi /ek/veri
ve /hususi/veri
alt
dizgeleriyle eşleşecektir.
Açıklama: | Hata günlüklerinin ayrıntı seviyesini belirler. |
---|---|
Sözdizimi: | LogLevel seviye |
Öntanımlı: | LogLevel warn |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
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:
Seviye | Açıklama | Örnek |
---|---|---|
emerg |
Acil durumlar - sistem kullanışsız. | "Child cannot open lock file. Exiting" (Alt süreç kilit dosyasını açamıyor. Çıkılıyor) |
alert |
Ne yapılacaksa beklemeden yapılmalı. | "getpwuid: couldn't determine user name from uid" (getpwuid: Kullanıcı ismi numarasından saptanamadı) |
crit |
Kriz durumları. | "socket: Failed to get a socket, exiting child" (socket: bir soket alınamadı, alt süreç çıkıyor) |
error |
Hata durumları. | "Premature end of script headers" (Betik başlıkları beklenmedik şekilde bitti) |
warn |
Uyarı durumları. | "child process 1234 did not exit, sending another
SIGHUP" (1234 alt süreci çıkmadı, başka bir SIGHUP gönderiliyor) |
notice |
Normal fakat önemli durum. | "httpd: caught SIGBUS, attempting to dump core in
..." (httpd: SIGBUS alındı, core dökümlenmeye çalışılıyor: ...) |
info |
Bilgilendirme. | "Server seems busy, (you may need to increase
StartServers, or Min/MaxSpareServers)..." (Sunucu meşgul görünüyor, (StartServers veya Min/MaxSpareServers değerlerini arttırmanız gerekebilir)...) |
debug |
Hata ayıklama seviyesi iletileri | "Opening config file ..." (... yapılandırma dosyası açılıyor) |
Belli bir seviye belirtildiğinde daha yüksek seviyeden iletiler de
raporlanır. Örneğin, LogLevel info
belirtildiğinde
notice
ve warn
günlük seviyelerinin iletileri
ayrıca raporlanacaktır.
En az crit
seviyesinin kullanılması önerilir.
Örnek:
LogLevel notice
Günlük iletileri normal bir dosyaya yazılırken notice
seviyesinden iletiler engellenemez ve dolayısıyla daima raporlanırlar.
Ancak, günlük kaydı syslog
kullanılarak yapılıyorsa bu
uygulanmaz.
Açıklama: | Bir kalıcı bağlantıda izin verilen istek sayısı |
---|---|
Sözdizimi: | MaxKeepAliveRequests sayı |
Öntanımlı: | MaxKeepAliveRequests 100 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
MaxKeepAliveRequests
yönergesi KeepAlive
etkinken bağlantı başına izin
verilecek istek sayısını sınırlar. Değer olarak 0
belirtilirse istek sayısı sınırsız olur. Sunucu başarımını yüksek tutmak
için yüksekçe bir değer belirtmenizi öneririz.
Örnek:
MaxKeepAliveRequests 500
Açıklama: | Özkaynağın tamamı döndürülmeden önce gönderilebilecek HTTP range başlıklarının azami miktarı |
---|---|
Sözdizimi: | MaxRanges default | unlimited | none | miktar |
Öntanımlı: | MaxRanges 200 |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache HTTP Sunucusunun 2.2.21 ve sonraki sürümlerinde kullanılabilir. |
MaxRanges
yönergesi, sunucunu istemciye
gönderebileceği HTTP range
başlıklarının sayısını
sınırlamak için kullanılır. Eğer izin verilenden daha fazla
range
başlığı istenirse fazlalık yerine özkaynağın
tamamı gönderilir.
Range
başlıkları yoksayılır.range
başlık
sayısını gösteren bir pozitif tamsayı.Açıklama: | İsme dayalı sanal konaklar için IP adresi belirtir |
---|---|
Sözdizimi: | NameVirtualHost adres[:port] |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
NameVirtualHost
yönergesi isme dayalı sanal konakları yapılandırmak isterseniz gerekli olur.
adres olarak bir konak ismi de belirtebilirsiniz ama daima bir IP adresi ve bir port kullanmanızı öneririz. Örnek:
NameVirtualHost 111.22.33.44:80
NameVirtualHost
yönergesi ile sunucunun isme
dayalı sanal konaklar için istekleri hangi IP adresinden alacağı
belirtilir. Bu adres genellikle isme dayalı sanal konak isimleri
çözümlendiğinde elde edilen IP adresidir. İstekleri bir güvenlik
duvarının veya bir vekilin alıp sunucuya yönlendirdiği durumlarda ise bu
adres sunucunun istekleri aldığı fiziksel arabirimin IP adresi olmalıdır.
Çok sayıda adres üzerinde çok sayıda isme dayalı sanal konak varsa her
adresin kendi yönergeleri olmalıdır.
“Ana sunucu” ve _default_
sunucuların bir
NameVirtualHost
IP adresine yapılan bir isteği
asla sunmayacağına dikkat ediniz (bir sebeple
NameVirtualHost
belirtip bu adres için herhangi
bir VirtualHost
tanımlamadığınız durumlar
hariç).
Seçimlik olarak, isme dayalı sanal konakların kullanması gereken port numarasını örnekteki gibi belirtebilirsiniz:
NameVirtualHost 111.22.33.44:8080
IPv6 adresleri belirtilirken örnekteki gibi köşeli ayraçlar arasına alınmalıdır:
NameVirtualHost [2001:db8::a00:20ff:fea7:ccea]:8080
İsteklerin bütün arabirimlerden alınacağını belirtmek için değer olarak
*:80
veya eğer çok sayıda portu dinliyorsanız ve belli bir
sanal konak kümesi üzerinden sunucunun hepsine yanıt vermesini
istiyorsanız *
belirtebilirsiniz:
NameVirtualHost *:80
<VirtualHost>
yönergesinin
argümanı<VirtualHost>
yönergesinin
argümanının NameVirtualHost
yönergesininkiyle tam
olarak eşleşmesi gerektiğine dikkat ediniz.
NameVirtualHost 1.2.3.4:80
<VirtualHost 1.2.3.4:80>
# ...
</VirtualHost>
Açıklama: | Belli bir dizinde geçerli olacak özellikleri yapılandırır. |
---|---|
Sözdizimi: | Options
[+|-]seçenek [[+|-]seçenek] ... |
Öntanımlı: | Options All |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | Options |
Durum: | Çekirdek |
Modül: | core |
Options
yönergesi belli bir dizinde hangi sunucu
özelliklerinin etkin olacağını (veya olmayacağını) belirler.
seçenek olarak hiçbir ek özellik etkin olmayacaksa
None
, aksi takdirde aşağıdakilerden biri veya bir kaçı
belirtilir:
All
MultiViews
hariç tüm seçenekler. Bu öntanımlıdır.ExecCGI
mod_cgi
kullanan CGI betiklerinin çalışmasına izin
verilir.FollowSymLinks
Sembolik bağlar izlense bile <Directory>
bölümleriyle eşleşen dosya yolları
değiştirilmez.
The FollowSymLinks
ve
SymLinksIfOwnerMatch
Options
yönergeleri sadece <Directory>
bölümlerinde veya
.htaccess
dosyalarında çalışır.
Sembolik bağ sınamaları, atlatılabilir yarış koşullarına konu olduğundan bu seçeneğin yokluğu bir güvenlik sınırlaması olarak değerlendirilmemelidir.
Includes
mod_include
tarafından sağlanan sunucu taraflı
içeriklere izin verilir.IncludesNOEXEC
#exec cmd
ve #exec cgi
iptal edilir. Ancak, ScriptAlias
’lı dizinlerdeki CGI
betikleri için #include virtual
hala mümkün olacaktır.Indexes
DirectoryIndex
(index.html
gibi) belirtilmemişse mod_autoindex
bu dizinin
biçimlenmiş bir listesini döndürecektir.MultiViews
mod_negotiation
kullanılarak içerik uzlaştırmalı çok
görünümlü içeriğe izin verilir.SymLinksIfOwnerMatch
The FollowSymLinks
ve
SymLinksIfOwnerMatch
Options
yönergeleri sadece <Directory>
bölümlerinde veya
.htaccess
dosyalarında çalışır.
Sembolik bağ sınamaları, atlatılabilir yarış koşullarına konu olduğundan bu seçenek bir güvenlik sınırlaması olarak değerlendirilmemelidir.
Normalde, bir dizine çok sayıda Options
uygulanabilirse de, dizine en uygun olanı uygulanıp diğerleri yok
sayılır; seçenekler katıştırılmaz (bkz, Bölümler Nasıl Katıştırılır?). Bununla birlikte, önüne bir
+
veya -
simgesi konmuş seçenekler varsa, o
seçenekler katıştırılır. Önüne +
konmuş seçenekler
mevcutlara eklenirken -
konmuş seçenekler silinir.
+
veya -
imli seçenekler içeren
Options
ile imsiz seçenekler içerenlerin karışık
olarak kullanılması beklenmedik sonuçlara yol açması sebebiyle aslında
geçersiz bir sözdizimidir.
Örneğin, +
ve -
imleri olmaksızın,
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>
yapılandırmasıyla /web/docs/spec
dizininde sadece
Includes
seçeneği etkin olacaktır. Bununla birlikte, ikinci
Options
yönergesinde +
ve
-
imleri kullanılırsa,
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>
yapılandırmasıyla /web/docs/spec
dizininde
FollowSymLinks
ve Includes
seçenekleri etkin
olacaktır.
-IncludesNOEXEC
veya -Includes
kullanımı,
önceki ayarların ne olduğuna bakılmaksızın sunucu taraflı içeriğin
tamamen iptaline sebep olur.
Herhangi bir başka değer belirtilmedikçe All
öntanımlıdır.
Açıklama: | Dinlenen bir soket için protokol |
---|---|
Sözdizimi: | Protocol protokol |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Windows üzerinde Apache 2.3.3 ve sonrasında diğerlerinde ise Apache 2.1.5 ve sonrasında kullanılabilmektedir. |
Bu yönerge dinlenen belli bir soket için protokol belirtmek amacıyla
kullanılır. Protokol, bir isteği hangi modülün işleyeceğini belirlemekte ve
AcceptFilter
yönergesi ile ilgili protokole özgü
iyileştirmeleri uygulamakta kullanılır.
Bu yönergeyi sadece standartdışı portlar belirtecekseniz kullanın.
Normalde http
için 80, https
için 443 portu
kullanılır.
Örneğin, https
'i standartdışı bir port üzerinde
çalıştırıyorsanız bunu şöyle belirtebilirsiniz:
Protocol https
Kullandığınız protoklü ayrıca Listen
yönergesini kullanarak da
belirtebilirsiniz.
AcceptFilter
Listen
Açıklama: | Bir özkaynağa erişebilecek kimliği doğrulanmış kullanıcıları belirler |
---|---|
Sözdizimi: | Require öğe-adı [öğe-adı] ... |
Bağlam: | dizin, .htaccess |
Geçersizleştirme: | AuthConfig |
Durum: | Çekirdek |
Modül: | core |
Bu yönerge br özkaynağa erişebilecek kimliği doğrulanmış kullanıcıları
belirlemek için kullanılır. Belli bir kullanıcı veya kullanıcı grubuna
erişim vermek için bu yönergeden çok sayıda yazmak yerine bunlar mantıksal
VEYAlarla birleştirilebilir. Kısıtlamalar yetkilendirme modülleri
tarafından işleme sokulur. mod_authz_user
ve
mod_authz_groupfile
tarafından izin verilen bazı
sözdizimleri:
Require user kull-kiml [kull-kiml]
...
Require group grup-adı [grup-adı]
...
Require valid-user
Gerekli diğer seçenekleri sağlayan yetkilendirme modülleri olarak
mod_authnz_ldap
, mod_authz_dbm
ve
mod_authz_owner
sayılabilir.
Require
yönergesinin düzgün çalışması için
kendisine AuthName
ve AuthType
yönergelerinin yanı sıra kullanıcıları
ve grupları tanımlamak için AuthUserFile
ve AuthGroupFile
gibi yönergelerinin
de eşlik etmesi gerekir. Örnek:
AuthType Basic
AuthName "Restricted Resource"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin
Bu yolla uygulanan erişim denetimleri tüm yöntemler için
etkilidir. Normalde istenen zaten budur. Erişim
denetimlerini diğerlerini korumasız bırakmak pahasına sadece belli
yöntemlerle sınırlamak isterseniz Require
yönergesini bir <Limit>
bölümüne yerleştirin.
Eğer Require
yönergesini Allow
veya
Deny
yönergeleri ile
birlikte kullanırsanız bu sınırlamalarla olan etkileşim Satisfy
yönergesi tarafından denetlenir.
Aşağıdaki örnekte korunmuş bir dizinin bir alt dizinindeki erişim
denetimlerinin kaldırılması için Satisfy
yönergesinin nasıl kullanılacağı
gösterilmiştir. Bu teknik, mod_authz_host
tarafından
dayatılan erişim denetimlerini de ortadan kaldırdığından dikkatli
kullanılmalıdır.
<Directory /korunmuş/dizine/giden/yol/>
Require user david
</Directory>
<Directory /korunmuş/dizine/giden/yol/korunmamış-dizin/>
# Bu dizinde tüm erişim denetimleri ve kimlik doğrulaması
# iptal ediliyor
Satisfy Any
Allow from all
</Directory>
Açıklama: | Apache alt süreçleri tarafından çalıştırılan süreçlerin işlemci tüketimine sınırlama getirir. |
---|---|
Sözdizimi: | RLimitCPU saniye|max [saniye|max] |
Öntanımlı: | Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
|
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
1 veya 2 değer alır. İlk değer bütün süreçler için sanal özkaynak
sınırını, ikinci değer ise kesin özkaynak sınırını belirler. İki değer de
birer sayı olabileceği gibi bu sınırın işletim sistemi yapılandırmasında
izin verilen üst sınıra ayarlanacağını belirtmek üzere max
olabilir. Kesin özkaynak sınırını yükseltmek için sunucunun
root
olarak veya sistem açılışı sırasında çalıştırılması
gerekir.
Bu sınırlar Apache’nin kendi alt süreçlerine değil, isteklere yanıt verirken Apache alt süreçlerinin çatalladıkları süreçlere uygulanır. Bunlar CGI betikleri ve SSI çalıştırma komutları olabilir fakat borulu günlük kaydı gibi ana Apache süreci tarafından çatallanmış süreçler olmazlar.
İşlemci özkaynak sınırları saniye cinsinden ifade edilir.
Açıklama: | Apache alt süreçleri tarafından çalıştırılan süreçlerin bellek tüketimine sınırlama getirir. |
---|---|
Sözdizimi: | RLimitMEM bayt-sayısı|max [bayt-sayısı|max]
|
Öntanımlı: | Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
|
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
1 veya 2 değer alır. İlk değer bütün süreçler için sanal özkaynak
sınırını, ikinci değer ise kesin özkaynak sınırını belirler. İki değer de
birer sayı olabileceği gibi bu sınırın işletim sistemi yapılandırmasında
izin verilen üst sınıra ayarlanacağını belirtmek üzere max
olabilir. Kesin özkaynak sınırını yükseltmek için sunucunun
root
olarak veya sistem açılışı sırasında çalıştırılması
gerekir.
Bu sınırlar Apache’nin kendi alt süreçlerine değil, isteklere yanıt verirken Apache alt süreçlerinin çatalladıkları süreçlere uygulanır. Bunlar CGI betikleri ve SSI çalıştırma komutları olabilir fakat borulu günlük kaydı gibi ana Apache süreci tarafından çatallanmış süreçler olmazlar.
Bellek özkaynak sınırları süreç başına bayt sayısı olarak ifade edilir.
Açıklama: | Apache alt süreçleri tarafından çalıştırılabilecek süreç sayısına sınırlama getirir. |
---|---|
Sözdizimi: | RLimitNPROC sayı|max [sayı|max] |
Öntanımlı: | Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
|
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
1 veya 2 değer alır. İlk değer bütün süreçler için sanal özkaynak
sınırını, ikinci değer ise kesin özkaynak sınırını belirler. İki değer de
birer sayı olabileceği gibi bu sınırın işletim sistemi yapılandırmasında
izin verilen üst sınıra ayarlanacağını belirtmek üzere max
olabilir. Kesin özkaynak sınırını yükseltmek için sunucunun
root
olarak veya sistem açılışı sırasında çalıştırılması
gerekir.
Bu sınırlar Apache’nin kendi alt süreçlerine değil, isteklere yanıt verirken Apache alt süreçlerinin çatalladıkları süreçlere uygulanır. Bunlar CGI betikleri ve SSI çalıştırma komutları olabilir fakat borulu günlük kaydı gibi ana Apache süreci tarafından çatallanmış süreçler olmazlar.
Süreç sayısı sınırı kullanıcı başına süreç sayısına sınırlama getirir.
CGI süreçleri sunucu kullanıcı kimliğinden farklı bir kullanıcı
kimliği altında çalışmıyorsa bu yönerge sunucunun kendi oluşturduğu
süreç sayısını sınırlayacaktır. Bunun kanıtı error_log
’da
iletilerin çatallanamamasıdır.
Açıklama: | Konak seviyesinde erişim denetimi ile kullanıcı kimlik doğrulaması arasındaki etkileşim |
---|---|
Sözdizimi: | Satisfy Any|All |
Öntanımlı: | Satisfy All |
Bağlam: | dizin, .htaccess |
Geçersizleştirme: | AuthConfig |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | 2.0.51 sürümü ve sonrasında <Limit> ve <LimitExcept> tarafından etkin kılınır. |
Allow
ve Require
yönergelerinin ikisi birden
kullanıldığında uygulanacak erişim kuralını belirler. Değer olarak sadece
All
veya Any
belirtilebilir. Bu yönergenin yararlı
olabilmesi için belli bir alana hem istemci konak adresi hem de kullanıcı
ismi ve parolası belirtmek suretiyle erişilebiliyor olunması gerekir. Bu
durumda öntanımlı davranış (All
), istemcinin belli bir adrese
erişebilmek için belli kısıtlamaları aşması ve geçerli bir kullanıcı adı ve
parola girmesi gerekir. Any
seçeneğinin belirtildiği durumda
ise istemcinin ya konak kısıtlamalarıdan geçmesi ya da geçerli bir kullanıcı
adı ve parolası girmesi gerekir. Bu seçenek, belli bir alana erişimi
parolayla kısıtlayıp, belli adreslerden gelen kullanıcılara parolasız erişim
vermek için kullanılabilir.
Örneğin, sitenizin belli bir bölümü için iç ağınızdan gelen isteklere sınırsız erişim vermek ama dışardan gelen istekleri parolayla kısıtlamak isterseniz şöyle bir yapılandırma kullanabilirsiniz:
Require valid-user
Order allow,deny
Allow from 192.168.1
Satisfy Any
2.0.51 sürümünden itibaren Satisfy
yönergeleri
<Limit>
ve <LimitExcept>
bölümleri tarafından
belli yöntemlerle kısıtlanmış olabilir.
Açıklama: | CGI betikleri için yorumlayıcı belirleme tekniği |
---|---|
Sözdizimi: | ScriptInterpreterSource Registry|Registry-Strict|Script |
Öntanımlı: | ScriptInterpreterSource Script |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Sadece Win32 için; Registry-Strict seçeneği Apache
2.0 ve sonrası için geçerlidir. |
Bu yönerge Apache’nin CGI betiklerini çalıştıracak yorumlayıcıyı nasıl
tespit edeceğini belirler. Script
öntanımlı olup Apache’nin
yorumlayıcı olarak betiğin diyezli ünlem satırında (#!
ile
başlayan ilk satır) belirtilen yorumlayıcıyı kullanacağını belirtir.
Win32 sistemlerinde bu satır genellikle şöyledir:
#!C:/Perl/bin/perl.exe
perl
yorumlayıcının yeri PATH
değişkeninde
kayıtlı ise şöyle de olabilir:
#!perl
ScriptInterpreterSource Registry
değeri ise betik dosyası
uzantısının (.pl
gibi) Windows Sicili içindeki
HKEY_CLASSES_ROOT
ağacında arama yapmak için bir arama
anahtarı olarak kullanılmasını sağlar. Betik dosyasını çalıştırmak için
tanımlanmış komutu bulmak için Shell\ExecCGI\Command
yoluna,
orada yoksa Shell\Open\Command
yoluna bakılır. İkisi de
yoksa son çare olarak Script
seçeneğinin davranışına
dönülür.
Örneğin, .pl uzantılı bir betiğin perl ile işlenmesi için sicil ayarı şöyle olabilir:
HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command\(Default) =>
C:\Perl\bin\perl.exe -wT
ScriptAlias
’lı dizinlerde
Apache bulduğu her dosyayı çalıştırmayı deneyeceğinden
ScriptInterpreterSource Registry
yapılandırmasını
kullanırken dikkatli olun. Registry
seçeneği genellikle
çalıştırılmayacak dosyalar için istenmeyen program çağrılarına sebep
olabilir. Örneğin, çoğu Windows sisteminde .htm
dosyaları
için ön tanımlı "open" komutu Microsoft Internet Explorer’ın
çalıştırılmasına sebep olur; bu bakımdan, betik dizininde bulunan bir
.htm
dosyası için yapılan bir HTTP isteği tarayıcının sunucu
artalanında çalıştırılmasına sebep olacaktır. Bu, sistemi bir kaç dakika
içinde çökertmek için iyi bir yoldur.
Registry-Strict
seçeneği Apache 2.0’da yeni olup
Registry
seçeneğinin yaptığını
Shell\ExecCGI\Command
yolu için yapar. ExecCGI
sistem tarafından bilinen bir anahtar olmadığından Windows Siciline elle
kaydedilmesi gerekir ve dolayısıyla sisteminiz üzerinde istenmeyen
program çağrılarına sebep olmaz.
Açıklama: | Sunucunun hata iletilerinde istemciye göstereceği eposta adresi |
---|---|
Sözdizimi: | ServerAdmin eposta-adresi|URL |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
ServerAdmin
yönergesi, sunucunun bir hata
durumunda istemciye döndüreceği hata iletilerinde içereceği iletişim
adresini belirtmek için kullanılır. Eğer httpd
sağlanan
değerin bir URL olmadığını saptarsa değerin bir eposta adresi olduğuna
hükmeder ve önüne mailto:
getirerek onu bir hiper bağ hedefi
olarak kullanır. Çoğu CGI betiği bir eposta adresi belirtildiği kabulünü
yaptığından değer olarak bir URL değil bir eposta adresi belirtmeniz
önerilir. Eğer bir URL belirtecekseniz hedef sizin denetiminizde olan
başka bir sunucuda bulunmalıdır, yoksa kullanıcılar hata durumunda bu
adrese erişemeyebilirler.
Kullanıcıların sunucu hakkında konuşurken isminizden bahsetmemeleri için burada belirtilecek adresin sırf bu işe adanmış bir adres olması daha iyidir. Örnek:
ServerAdmin www-admin@falan.filan.dom
Açıklama: | İstekleri isme dayalı sanal konaklarla eşleştirilirken kullanılacak konak adları için başka isimler belirtebilmeyi sağlar. |
---|---|
Sözdizimi: | ServerAlias konakadı [konakadı] ... |
Bağlam: | sanal konak |
Durum: | Çekirdek |
Modül: | core |
ServerAlias
yönergesi, istekleri isme dayalı sanal konaklarla
eşleştirilirken kullanılacak konak adları için başka isimler
belirtebilmeyi sağlar. ServerAlias
dosya adı kalıp
karakterleri içerebilir.
<VirtualHost *:80>
ServerName sunucu.mesela.dom
ServerAlias sunucu sunucu2.mesela.dom sunucu2
ServerAlias *.mesela.dom
UseCanonicalName Off
# ...
</VirtualHost>
<virtualhost>
bölümleriyle en iyi eşleşen isme dayalı sanal konaklar yapılandırmada
göründükleri sıraya göre işleme sokulur. İlk eşleşen ServerName
veya ServerAlias
kullanılır ve joker kullanımı halinde herhangi
bir öncelik söz konusu olmaz.
VirtualHost
içindeki isimlerin tamamı bir
(jokersiz) ServerAlias
gibi ele alınır.
Açıklama: | Sunucunun özdeşleşeceği konak ismi ve port. |
---|---|
Sözdizimi: | ServerName [şema://]tam-nitelenmiş-alan-adı[:port]
|
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Bu yönerge 2.0 sürümünden itibaren 1.3 sürümündeki
Port yönergesinin işlevselliğini de
üstlenmiştir. |
ServerName
yönergesi, sunucunun kendini
betimlemekte kullanacağı şema, konak adı ve port değerlerini belirler.
Bu, yönlendirme URL’leri oluşturulurken kullanılır.
Buna ek olarak, ServerName
yönergesi
isme dayali sanal konaklar
kullanılması durumunda, bir sanal konağı tam olarak belirlemek için de
kullanlır (muhtemelen ServerAlias
ile
birlikte).
Örneğin, HTTP sunucusunun barındırıldığı makinenin ismi
falan.filan.dom
olduğu halde makinenin bir de
www.filan.dom
diye bir de DNS rumuzu varsa ve HTTP
sunucunuzun bu rumuzla kendini özdeşleştirmesini isterseniz bunu şöyle
belirtebilirsiniz:
ServerName www.filan.dom
Bir ServerName
ataması yapılmamışsa sunucu IP
adresine atanmış sunucu ismi için bir ters DNS sorgusu yapacaktır.
ServerName
yönergesinde bir port belirtilmediği
takdirde sunucu, isteğin geldiği portu kullanacaktır. Öngörülebilirlik ve
güvenilirlik açısından en iyisi ServerName
yönergesini kullanarak açıkça bir konak ismi ve port belirtmektir.
İsme dayalı sanal konaklar
kullanıyorsanız, <VirtualHost>
bölümü içindeki
ServerName
yönergesi, isteğin Host:
başlığında bu sanal konakla eşleşecek konak ismini belirler.
Bazen sunucu, bir ters vekil, yük dengeleyici veya SSL yük aktarım
uygulaması gibi bir aygıtın arkasında çalışır. Böyle durumlarda sunucunun
kendine yönelik URL’leri doğru üretebildiğinden emin olmak için
ServerName
yönergesinde istemcinin bağlanacağı
https://
şeması ve port numarası belirtilir.
Sunucunun kendine yönelik URL’lerin belirtilen portu içerip içermediğini
veya istemcinin yaptığı istekte belirtilen port numarasının verilip
verilmediğinin saptamasını sağlayan (örneğin, mod_dir
modülü tarafından) ayarlar için UseCanonicalName
ve
UseCanonicalPhysicalPort
yönergelerinin açıklamalarına bakınız.
Açıklama: | Uyumsuz bir tarayıcı tarafından erişilmesi için bir isme dayalı sanal konak için meşru URL yolu |
---|---|
Sözdizimi: | ServerPath URL-yolu |
Bağlam: | sanal konak |
Durum: | Çekirdek |
Modül: | core |
ServerPath
yönergesi isme
dayalı sanal konaklarda kullanmak için konağa meşru bir URL yolu
belirler.
Açıklama: | Sunucu yapılandırması için kök dizin |
---|---|
Sözdizimi: | ServerRoot dizin-yolu |
Öntanımlı: | ServerRoot /usr/local/apache |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
ServerRoot
yönergesi sunucu yapılandırmasını
içeren dizinin yerini belirtir. Genellikle conf/
ve
logs/
gibi alt dizinler içerir. Include
, LoadModule
gibi diğer yapılandırma
yönergelerindeki göreli yollar bu dizine göre ele alınır.
ServerRoot /home/httpd
httpd
için -d
seçeneğiServerRoot
dizininin erişim izinlerinin nasıl
ayarlanması gerektiğini öğrenmek için güvenlik ipuçlarıAçıklama: | Sunucu tarafından üretilen belgelerin dipnotunu ayarlar. |
---|---|
Sözdizimi: | ServerSignature On|Off|EMail |
Öntanımlı: | ServerSignature Off |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
ServerSignature
yönergesi, sunucu tarafından
üretilen belgelerin (hata iletileri, mod_proxy
ftp dizin
listeleri, mod_info
çıktısı, vs.) altındaki dipnot
satırını yapılandırabilmenizi sağlar. Böyle bir dipnot satırın
istenmesinin sebebi vekil zincirlerinde istemciye dönen hata iletisinin
aslında hangi sunucu tarafından üretildiğini kullanıcıya bildirmektir.
Off
değeri öntanımlı değer olup dipnot satırının
gösterilmemesini sağlar (Apache-1.2 ve öncesi ile uyumluluk).
On
değeri, sunucu sürüm numarası ve hizmeti sunan sanal
konağın isminden (ServerName
) oluşan
bir dipnot satırı oluşturulmasını sağlar; EMail
değeri bu
ikisine ek olarak satıra ServerAdmin
ile belirtilen adres için bir "mailto:" bağı ekler.
2.0.44 sürümünden beri sunucu sürüm numarasının ayrıntıları ServerTokens
yönergesi ile belirlenmektedir.
Açıklama: | Server HTTP yanıt başlığını yapılandırır.
|
---|---|
Sözdizimi: | ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full |
Öntanımlı: | ServerTokens Full |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
Bu yönerge Server
HTTP yanıt başlığı alanında istemcilere
sunucunun işletim sistemi, sunucuyla derlenmiş modüller, vs. hakkında
bilgi verilip verilmeyeceğini belirler.
ServerTokens Prod[uctOnly]
Server:
Apache
ServerTokens Major
Server:
Apache/2
ServerTokens Minor
Server:
Apache/2.0
ServerTokens Min[imal]
Server:
Apache/2.0.41
ServerTokens OS
Server: Apache/2.0.41
(Unix)
ServerTokens Full
(ya da belirtilmezse)Server: Apache/2.0.41
(Unix) PHP/4.2.2 MyMod/1.2
Bu ayarlama sunucunun tamamını etkiler ve her sanal konak için farklılaştırılamaz.
2.0.44 sürümünden itibaren bu yönerge ServerSignature
yönergesi tarafından sunulan
bilgiyi de etkilemektedir.
Açıklama: | Eşleşen tüm dosyaların belli bir eylemci tarafından işlenmesine sebep olur. |
---|---|
Sözdizimi: | SetHandler eylemci-ismi|None |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache 2.0’da core modülüne taşındı. |
Bir .htaccess
dosyasına veya bir <Directory>
ya da <Location>
bölümüne yerleştirildiğinde, eşleşen
tüm dosyaların, ismi eylemci-ismi ile belirtilen eylemci tarafından çözümlenmesine sebep olur.
Örneğin, bir dizin içindeki bütün dosyaların, uzantılarına bakılmaksızın
birer imagemap kural dosyası olarak çözümlenmesini istersiniz, bu dizin
içindeki bir .htaccess
dosyasına şöyle bir satır
koyabilirsiniz:
SetHandler imap-file
Başka bir örnek: http://localhost/status
gibi bir istek
yapıldığında sunucunun bir durum bilgisi göstermesi için
httpd.conf
dosyasına şöyle bir satır koyabilirsiniz:
<Location /status>
SetHandler server-status
</Location>
Evvelce tanımlanmış bir SetHandler
yönergesini
None
değeriyle geçersiz hale getirebilirsiniz.
Açıklama: | POST girdilerini ve istemci isteklerini işleyecek süzgeçleri belirler. |
---|---|
Sözdizimi: | SetInputFilter süzgeç[;süzgeç...] |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
SetInputFilter
yönergesi, istemci isteklerini
ve sunucu tarafından alındığı takdirde POST girdisini işleyecek süzgeç
veya süzgeçleri belirler. Bu, diğer AddInputFilter
yönergeleri dahil evvelce tanımlanmış
süzgeçlere eklenir.
Birden fazla süzgeç belirtilmek istenirse birbirlerinden noktalı virgüllerle ayrılmalı ve çıktıyı işleyecekleri sıraya uygun olarak sıralanmalıdırlar.
Açıklama: | Sunucunun yanıtlarını işleyecek süzgeçleri belirler. |
---|---|
Sözdizimi: | SetOutputFilter süzgeç[;süzgeç...] |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
SetOutputFilter
yönergesi, istemciye
gönderilmeden önce sunucunun yanıtlarını işleyecek süzgeçleri belirler.
Bu, diğer AddOutputFilter
yönergeleri dahil evvelce tanımlanmış süzgeçlere eklenir.
Örneğin, aşağıdaki yapılandırma ile /www/data/
dizinindeki
bütün dosyalar sunucu taraflı içerik kapsamında ele alınacaktır.
<Directory /www/data/>
SetOutputFilter INCLUDES
</Directory>
Birden fazla süzgeç belirtilmek istenirse birbirlerinden noktalı virgüllerle ayrılmalı ve çıktıyı işleyecekleri sıraya uygun olarak sıralanmalıdırlar.
Açıklama: | suEXEC özelliğini açar veya kapar |
---|---|
Sözdizimi: | Suexec On|Off |
Öntanımlı: | suexec çalıştırılabiliri doğru sahip ve kip ile mevcutsa etkin kılınır, yoksa etkin kılınmaz. |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache httpd 2.2.18 ve sonrasında kullanılabilir. |
Yönergeye On değeri verildiğinde, suexec çalıştırılabiliri mevcut değilse veya çalıştırılabilir dosyanın sahibi veya kip geçersizse sunucu başlatılamaz.
Off değeri verildiğinde ise, suexec çalıştırılabiliri doğru sahip ve kip ile mevcutsa bile suEXEC iptal edilir.
Açıklama: | Bir istek için başarısız olmadan önce belirli olayların gerçekleşmesi için sunucunun geçmesini bekleyeceği süre. |
---|---|
Sözdizimi: | TimeOut saniye |
Öntanımlı: | TimeOut 300 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
TimeOut
yönergesi çeşitli durumlarda
Apache’nin bekleyeceği süreyi belirler:
mod_cgi
modülünde bir CGI betiğinin çıktısı için
beklenecek süre.mod_ext_filter
modülünde bir süzme işleminin
çıktısı için beklenecek süre.mod_proxy
modülünde
ProxyTimeout
yapılandırılmamışsa öntanımlı zaman aşımı değeri.Açıklama: | TRACE isteklerinde davranış şeklini belirler
|
---|---|
Sözdizimi: | TraceEnable [on|off|extended] |
Öntanımlı: | TraceEnable on |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache 1.3.34, 2.0.55 ve sonrasında mevcuttur. |
Bu yönerge çekirdek ve vekil (mod_proxy
) sunucuların
her ikisi için öntanımlı TRACE
davranışını değiştirir.
Öntanımlı olan TraceEnable on
ile RFC 2616’dan kaynaklanan
ve isteğe herhangi bir istek gövdesinin eşlik etmesine izin vermeyen
TRACE
isteklerine izin verilir. TraceEnable off
ile çekirdek ve vekil (mod_proxy
) sunucuların her ikisi
de TRACE
isteklerine yanıt olarak bir 405
(Yönteme izin verilmiyor) hatası döndürür.
TraceEnable extended
ile sadece sınama ve tanı koyma
amaçlarına yönelik olarak istek gövdelerine izin verilir. Asıl sunucu
istek gövdesini 64k ile sınırlar (Transfer-Encoding: chunked
kullanılmışsa bölüm başlıkları için 8k daha). Asıl sunucu yanıt
gövdesinde tüm başlıkları ve bölüm başlıklarının tamamını yansıtacaktır.
Vekil sunucuda ise istek gövdesi için 64k’lık sınır yoktur.
Açıklama: | Sunucunun kendi adını ve portunu nasıl belirleyeceğini ayarlar |
---|---|
Sözdizimi: | UseCanonicalName On|Off|DNS |
Öntanımlı: | UseCanonicalName Off |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Apache‘nin çoğu durumda özüne yönelik URL‘ler (isteğin tekrar aynı
sunucuya yapıldığı bir URL türü) oluşturması gerekir.
UseCanonicalName On
ile Apache, sunucu için meşru ismi ve
portu oluşturmak için ServerName
yönergesinde belirtilen ismi ve portu kullanır. Bu isim CGI'lerde
SERVER_NAME
ve SERVER_PORT
değerlerinde ve tüm
özüne yönelik URL’lerde kullanılır.
UseCanonicalName Off
ile Apache, özüne yönelik URL’leri
varsa istemci tarafından sağlanan konak ismini ve portu kullanarak
oluşturur; bunlar istemci tarafından sağlanmamışsa yukarıda tanımlanan
işleme başvurulur. Bu değerler, isme
dayalı sanal konakları gerçekleştirirken kullanılan değerlerle aynı
olup aynı istemcilerle kullanılabilir. SERVER_NAME
ve
SERVER_PORT
CGI değişkenleri de istemci tarafından sağlanan
isim ve portla oluşturulur.
Bir örnek olarak, iç ağdaki istemcilerin sunucuya www
gibi
bir kısa isim kullanarak bağlandığı durumu ele alırsak daha yararlı olur.
Kullanıcılar bir kısa isim ve bir dizin isminden oluşan ve bir / ile
sonlandırılmamış http://www/splat
şeklinde bir istek
yaparlarsa, Apache onları http://www.mesela.dom/splat/
adresine yönlendirecektir. Eğer kimlik doğrulama da etkinse bu
kullanıcının iki defa kimlik doğrulamasına sokulmasına sebep olacaktır
(bir kere www
için bir kere de www.mesela.dom
için; daha ayrıntılı bilgi için SSS’y
e bakınız). Fakat UseCanonicalName Off
olsaydı
Apache isteği http://www/splat/
adresine yönlendirecekti.
UseCanonicalName DNS
diye üçüncü bir seçenek daha vardır ve
istek yaparken Host:
başlığını kullanmayan eski istemcileri
desteklemek amacıyla IP’ye dayalı sanal konaklarla kullanmak için
tasarlanmıştır. Bu seçenek etkin olduğunda Apache, istemciyi özüne
yönelik URL’lerle doğru yere bağlamak için sunucu IP adresi üzerinde bir
ters DNS sorgusu yapar.
Eğer CGI’ler SERVER_NAME
değerleri için önkabuller
yapıyorlarsa bu seçenek işlerinin bozulmasına yol açabilir. Aslında
istemciler konak ismi olarak istedikleri değeri vermekte özgürdürler.
Fakat eğer CGI, özüne yönelik URL’leri oluştururken sadece
SERVER_NAME
değerini kullanıyorsa bu istendiği gibi
çalışacaktır.
Açıklama: | Sunucunun kendi adını ve portunu nasıl belirleyeceğini ayarlar |
---|---|
Sözdizimi: | UseCanonicalPhysicalPort On|Off |
Öntanımlı: | UseCanonicalPhysicalPort Off |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Apache‘nin çoğu durumda özüne yönelik URL‘ler (isteğin tekrar aynı
sunucuya yapıldığı bir URL türü) oluşturması gerekir. Apache UseCanonicalName
yönergesine bağlı olarak
sunucu için meşru portu oluştururken UseCanonicalPhysicalPort
On
ile olası port olarak istek tarafından kullanılmakta olan
fiziksel portu kullanacaktır. UseCanonicalPhysicalPort Off
olduğunda ise geçerli bir port numarası oluşturmak için asıl fiziksel
port yerine yapılandırma bilgisi kullanılır.
Fiziksel port kullanımı etkin olduğunda işlemler şu sırayla
yürütülür:
UseCanonicalName On
Servername
yönergesinde belirtilen portUseCanonicalName Off | DNS
Host:
başlığından çözümlenen portServername
yönergesinde belirtilen portUseCanonicalPhysicalPort Off
olduğunda işlem sırasında
fiziksel port adımları atlanır.
Açıklama: | Sadece belli bir konak ismine ve porta uygulanacak yönergeleri barındırır. |
---|---|
Sözdizimi: | <VirtualHost
adres[:port] [adres[:port]]
...> ... </VirtualHost> |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
<VirtualHost>
ve
</VirtualHost>
birlikte sadece belli bir sanal konağa
uygulanacak yönergeleri sarmalamakta kullanılırlar. Bir sanal konak
kapsamında belirtilebilecek her yönerge kullanılabilir. Sunucu belli bir
sanal konak üzerindeki bir belge için bir istek aldığında <VirtualHost>
bölümünde bulunan yapılandırma
yönergelerini kullanır. adres şunlardan biri olabilir:
NameVirtualHost *
ile birlikte tüm IP adresleri ile
eşleşmek üzere *
karakteri._default_
dizgesi.
<VirtualHost 10.1.2.3:80>
ServerAdmin webmaster@konak.mesela.dom
DocumentRoot /www/docs/konak.mesela.dom
ServerName konak.mesela.dom
ErrorLog logs/konak.mesela.dom-error_log
TransferLog logs/konak.mesela.dom-access_log
</VirtualHost>
İsteğe bağlı port numarasını belirtmeyi mümkün kılmak için IPv6 adresleri köşeli ayraç içine alınır. IPv6 adresi kullanılan bir örnek:
<VirtualHost [2001:db8::a00:20ff:fea7:ccea]:80>
ServerAdmin webmaster@konak.mesela.dom
DocumentRoot /www/docs/konak.mesela.dom
ServerName konak.mesela.dom
ErrorLog logs/konak.mesela.dom-error_log
TransferLog logs/konak.mesela.dom-access_log
</VirtualHost>
Her sanal konağın ya farklı bir IP adresi ve port ile ya da farklı bir
konak ismiyle eşleşmesi gerekir. Birinci durumda sunucu makinesinin çok
sayıda adresten IP paketleri kabul edecek şekilde yapılandırılması
gerekir. (Eğer makinede çok sayıda ağ arabirimi yoksa bu, işletim sistemi
desteklediği takdirde ifconfig alias
komutuyla
sağlanabilir.)
<VirtualHost>
kullanımı Apache’nin
dinleyeceği adresler üzerinde belirleyici değildir. Apache’nin doğru
adresi dinlediğinden emin olmak için Listen
kullanmanız gerekebilir.
IP’ye dayalı sanal konakları kullanıyorsanız, diğer sanal konaklarda
açıkça belirtilmemiş IP adresleriyle eşleşecek sanal konağı
_default_
özel ismiyle belirtebilirsiniz. "Ana" sunucu
yapılandırmasında _default_
diye bir sanal konağın
bulunmaması halinde, hiçbir IP adresi eşleşmesi bulunamadığı takdirde
<VirtualHost>
bölümleri dışında kalan
tüm yapılandırmalar bu amaca yönelik olarak kullanılır. (Yalnız dikkat
edin, bir NameVirtualHost
yönergesi
ile eşleşen bir IP adresi için ne "ana" sunucu yapılandırması ne de
_default_
sanal konak yapılandırması kullanılır. Bu konuda
daha ayrıntılı bilgi için isme dayalı
sanal konaklar belgesine bakınız.)
Eşleşilecek portu değiştirmek için bir :port
belirtebilirsiniz. Port bu şekilde değiştirilmediği takdirde ana
sunucunun son Listen
yönergesinde belirtilen port kullanılır. Bir adresteki tüm portlarla
eşleşileceğini belirtmek için :*
kullanabilirsiniz. (Bu,
_default_
kullanıldığı takdirde önerilir.)
Her <VirtualHost>
bloku içinde bir
ServerName
yönergesi mutlaka
olmalıdır. Yokluğu halinde "ana" sunucu yapılandırmasındaki ServerName
miras alınacaktır (yani, sanal konak
belirtmek için boşuna uğraşmış olursunuz).
Günlük dosyalarının sunucuyu çalıştıran kullanıcıdan başka herkes tarafından yazılabilen bir yerde saklanmasından dolayı ortaya çıkabilecek güvenlik sorunları hakkında daha ayrıntılı bilgi için güvenlik ipuçları belgesine bakınız.