Apache HTTP Sunucusu Sürüm 2.4
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: | Windows'ta Apache httpd 2.3.3 ve sonrasında diğerlerinde Apache httpd 2.1.5 ve sonrasında mevcuttur. |
Bu yönerge Protocol
yönergesinde belirtilen
protokol türüne göre bir dinleme soketinin işletim
sistemine özgü en iyilemelerini etkin kılar. İşletim sistemi çekirdeği
için temel önerme veri alınıncaya kadar veya HTTP isteğinin tamamı
tamponlanana kadar sunucu sürecine bir soket tahsis etmemektir.
Şimdilik sadece FreeBSD’nin Kabul Süzgeçleri ve Linux’un soket seçeneklerinden
TCP_DEFER_ACCEPT
ve Windows'un en iyilenmiş
AcceptEx()
işlevi desteklenmektedir.
Değiştirge olarak none
kullanımı, protokolün kabul
süzgeçlerini iptal edecektir. ftp:
veya nntp
gibi sunucunun baştan bir veri göndermesinin gerekli olduğu
protokoller için kullanışlıdır. Örnek:
AcceptFilter nntp none
Öntanımlı protokol isimleri port 443 için https
ve tüm
diğer portlar için http
'dir. Dinlenmesi için başka bir port
ile ilgili bir protokol belirtmek isterseniz Listen
yönergesine protokol
argümanını ekleyin.
FreeBSD için öntanımlı değerler:
AcceptFilter http httpready
AcceptFilter https dataready
httpready
kabul süzgeci HTTP isteklerinin tamamını
işletim sistemi çekirdeği seviyesinde tamponlar. Çekirdek isteğin
tamamını alır almaz sunucuya gönderir. Ayrıntılar için accf_http(9) kılavuz sayfasına bakınız. HTTPS istekleri
şifrelenmiş olduğundan sadece accf_data(9) süzgeci kullanılır.
Linux’taki öntanımlı değerler:
AcceptFilter http data
AcceptFilter https data
Linux’un TCP_DEFER_ACCEPT
soket seçeneği HTTP isteklerinin
tamponlanmasını desteklemez. none
dahil her değer
dinleyici üzerinde TCP_DEFER_ACCEPT
seçeneğini etkin kılar.
Daha ayrıntılı bilgi edinmek için Linux
tcp(7) kılavuz sayfasına bakınız.
Windows’taki öntanımlı değerler::
AcceptFilter http data
AcceptFilter https data
Windows'un mpm_winnt
modülü AcceptEx()
arayüzünü açıp kapamak için AcceptFilter
'i yorumlar ve
http protokol tamponlamasını desteklemez. Windows
AcceptEx()
arayüzünü tetikleyen iki değer vardır ve ağ
soketlerini bağlantılar arasında yer değiştirirler. data
,
veri aktarılana kadar yukarıda anlatıldığı gibi bekler ve ilk veri
tamponu ve uç ağ adresleri tek bir AcceptEx()
çağrısından
alınır. connect
, AcceptEx()
arayüzünü
kullanacak, ayrıca uç ağ adresleri de alınacak, fakat
none
gibi connect
seçeneği de ilk veri
aktarımını beklemeyecektir.
Windows'ta none
AcceptEx()
'ten ziyade
accept()
kullanır ve ağ soketlerini bağlantılar arasında
yer değiştirmez. Sürücü desteği bozuk ağ bağdaştırıcılarından başka
vpn sürücüleri gibi bazı sanal ağ sağlayıcılar veya spam, virus veya
casus yazılım süzgeçleri için kullanışlıdır.
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 httpd 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,
Genel Ağ ortam türlerinde (MIME türlerinde) kullanmak üzere IANA’da kayıtlı
karakter kümesi değerlerinden biri olmalıdır. Örnek:
AddDefaultCharset utf-8
AddDefaultCharset
yönergesi sadece, metin
kaynaklarının hepsinin aynı karakter kümesine sahip olduğu bilindiği
takdirde ve her birinde ayrı ayrı karakter kümesi belirtmek çok
külfetli olacaksa kullanılmalıdır. Buna bir örnek, CGI betikleri
tarafından üretilmiş içeriğe sahip kaynaklara karakter kümesinin
eklenmesidir; böyle kaynaklar çıktıda kullanıcı tarafından sağlanmış
veri içermeleri nedeniyle karşı siteden kaynaklanan betikli
saldırılardan zarar görebilir. Bununla birlikte, bir öntanımlı karakter
kümesi belirtmek, tarayıcılarında “karakter kodlamasını kendiliğinden
sapta” özelliğini etkin kılmış kullanıcıları korumayacağından daha iyi
bir çözüm bu betikleri bu tür saldırılara karşı düzeltmek veya en iyisi
silmektir.
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 httpd 2.0.46 ve sonrasında mevcuttur. NoDecode seçeneği Apache httpd 2.3.12 ve sonrasında mevcuttur. |
AllowEncodedSlashes
yönergesi kodlanmış dosya
yolu ayracı içeren URL’lere izin verir (/
yerine
%2F
ve ek olarak \
için ilgili sistemlerde
%5C
kullanılmış URL’ler).
Off
öntanımlı değeriyle, böyle URL’ler bir 404
(Nesne bulunamadı) hatasıyla reddedilirler.
On
değeriyle, böyle URL’ler kabul edilir ve kodlanmış
dosya yolu ayraçları kodlanmış diğer karakterler gibi çözümlenir.
NoDecode
değeriyle, böyle URL’ler kabul edilir fakat
kodlanmış dosya yolu ayraçları çözümlenmeden kodlanmış halde
bırakılır.
AllowEncodedSlashes
On
, çoğunlukla
PATH_INFO
ile bir arada kullanıldığı zaman
kullanışlıdır.
Kodlanmış bölü çizgileri yol bilgisi için gerekliyse bir güvenlik
ölçütü olarak NoDecode
kullanımı şiddetle önerilir.
Kodlanmış bölü çizgilerinin çözümlenmesine izin vermek güvensiz olması
olası yollara izin vermek olurdu.
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 None (2.3.9 ve sonrası), AllowOverride All (2.3.8 ve öncesi) |
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.
Bu yönergeye ve AllowOverrideList
yönergesine değer olarak None
belirtilirse
.htaccess dosyaları tamamen yok sayılır.
Bu durumda, sunucu dosya sisteminde rastladığı .htaccess
dosyalarını okumaya dahi çalışmayacaktır.
Bu yönergeye All
değeri atanırsa, .htaccess bağlamında kullanılabilecek her
yönergeye .htaccess
dosyalarında izin verilir.
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,
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.AllowOverride
yönergesinin kullanımına izin verir; bunun
yerine bir dahili sunucu hatasına sebep olur, izin verilmeyen veya
tanınmayan yönergeler yoksayılır ve günlüğe bir uyarı çıktılanır:
AllowOverride
tarafından yasaklanmış yönergeler
ölümcül olarak ele alınmaz.Geçerli bir yönergedeki yazım hatalarının hala dahili bir sunucu hatasına sebep olacağına dikkat ediniz.
AllowOverride AuthConfig
'e izin vermezse kullanıcıların
siteye erişimini kısıtlayan yapılandırma iptal edilmiş olur.
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ılabilen
seçenek listesi bu yönergeyle sınırlanabilirse de herhangi bir
Options
yönergesine izin
verildiği sürece miras alınmış diğer seçenekler göreli olmayan
sözdizimi kullanılarak iptal edilebilir. Başka bir deyişle, bu
mekanizma diğerlerinin değerlerini korumasına izin verirken belli bir
seçeneği değerini korumaya zorlayamaz.
Ö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: | .htaccess dosyalarında izin verilecek yönergeler tek tek belirtilir |
---|---|
Sözdizimi: | AllowOverrideList None|yönerge
[yönerge-türü] ... |
Öntanımlı: | AllowOverrideList None |
Bağlam: | dizin |
Durum: | Çekirdek |
Modül: | core |
Sunucu bir .htaccess
dosyası (AccessFileName
tarafından belirtildiği gibi)
bulduğunda önceki yapılandırma yönergelerini geçersiz kılabilen bu
dosyada hangi yönergelerin bildirildiğini bilmek ister.
AllowOverrideList
sadece <Directory>
bölümlerinde düzenli
ifadeler olmaksızın belirtilmişse kullanılabilir; <Location>
, <DirectoryMatch>
veya <Files>
bölümlerinde değil.
Bu yönergeye ve AllowOverride
yönergesine None
atanmışsa
.htaccess dosyaları tamamen yoksayılır. Bu
durumda sunucu dosya sistemindeki .htaccess
dosyalarını
okumaya bile çalışmayacaktır.
Örnek:
AllowOverride None
AllowOverrideList Redirect RedirectMatch
Yukarıdaki örnekte sadece Redirect
ve
RedirectMatch
yönergelerine izin verilmektedir. Tüm
diğerleri dahili bir sunucu hatasına sebep olacaktır.
Örnek:
AllowOverride AuthConfig
AllowOverrideList CookieTracking CookieName
Yukarıdaki örnekte AllowOverride
yönergesi AuthConfig
yönerge grubuna izin
verirken AllowOverrideList
yönergesi
FileInfo
yönerge grubundan yalnız iki yönergeye izin
vermektedir. Tüm diğerleri dahili bir sunucu hatasına sebep
olacaktır.
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 httpd’nin CGI bekitlerini çalıştırmak için
kullanacağı yorumlayıcıyı nasıl bulacağını denetlemek için kullanılır.
Örneğin, CGIMapExtension sys:\foo.nlm .foo
satırı
.foo
uzantılı CGI betik dosyalarının FOO yorumlayıcıya
aktarılmasını sağlar.
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 çalışma anı dosyaları için temel dizin |
---|---|
Sözdizimi: | DefaultRuntimeDir dizin-yolu |
Öntanımlı: | DefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/) |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
DefaultRuntimeDir
yönergesi sunucunun çalışma
anında oluşturacağı dosyaların (paylaşımlı bellek, kilitler, vb.)
saklanacağı dizini belirtmekte kullanılır. Göreli bir yol belirtilirse
tam yol ServerRoot
yönergesinde belirtilene
göreli olacaktır.
DefaultRuntimeDir scratch/
DefaultRuntimeDir
için öntanımlı yer derleme
sırasında DEFAULT_REL_RUNTIMEDIR
#define satırı ile
değiştirilebilir.
Bilgi: ServerRoot
bu yönergeden önce belirtilmiş
olmalıdır, aksi takdirde temel dizin için öntanımlı
ServerRoot
kullanılır.
ServerRoot
üzerindeki izinlerin düzgün olarak
nasıl ayarlanacağını öğrenmek için:
güvenlik ipuçlarıAçıklama: | Değeri none olduğu takdirde, bu yönergenin bir
uyarı vermekten başka bir etkisi yoktur. Önceki sürümlerde, bu yönerge,
sunucunun ortam türünü saptayamadığı durumda göndereceği öntanımlı ortam
türünü belirlerdi. |
---|---|
Sözdizimi: | DefaultType ortam-türü|none |
Öntanımlı: | DefaultType none |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | none değeri Apache httpd 2.2.7 ve sonrasında
mevcuttur. Diğer tüm seçenekler Apache httpd'nin 2.3.x ve sonraki sürümleri
için iptal edilmiştir. |
Bu yönerge iptal edilmiştir. Yapılandırma dosyalarının geriye
uyumluluğunu sağlamak için, öntanımlı bir ortam türünün olmadığını
belirten none
değeriyle belirtilebilir. Örnek:
DefaultType none
DefaultType None
sadece httpd-2.2.7 ve sonrasında
mevcuttur.
Ortam türlerini dosya uzantıları üzerinden yapılandırmak için
AddType
yönergesini ve
mime.types
yapılandırma dosyasını veya belli özkaynak
türleri için ortam türlerini yapılandırmak için ForceType
yönergesini kullanın.
Açıklama: | Bir değişken tanımlar |
---|---|
Sözdizimi: | Define değişken-ismi [değişken-değeri] |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Tek değiştirgeli biçemi httpd
’yi -D
seçeneğiyle çalıştırmaya eşdeğerdir. Bu yönerge, başlatma betiğinde
-D
seçeneğinin argümanlarını değiştirme gereği duymaksızın
<IfDefine>
bölümlerini
kullanıma sokmak için kullanılabilir.
Buna ek olarak, ikinci değiştirge belirtilirse yapılandırma değişkenine
bu değer atanır. Değişken yapılandırmada ${VAR}
sözdizimi
ile kullanılabilir. Değişken daima küresel olarak tanımlı olup
yapılandırma bölümünü sarmalayan etki alanı ile sınırlanmaz.
<IfDefine TEST>
Define servername test.example.com
</IfDefine>
<IfDefine !TEST>
Define servername www.example.com
Define SSL
</IfDefine>
RewriteMap
sözdizimi ile
karışmalardan kaçınmak için değişken isimleri ikinokta ":" karakterleri
içeremez.
Açıklama: | Sadece ismi belirtilen dosya sistemi dizininde ve bunun altdizinlerinde ve bunların içeriğinde 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
dizininde, bunun altdizinlerinde ve bu dizinlerin içindeki dosyalara
uygulanacak bir yönerge grubunu
sarmalamakta kullanılır. Bir dizin bağlamında kullanılabilecek her
yönergeye izin verilir. dizin-yolu bir dizinin tam yolu
olabileceği gibi Unix kabuk tarzı bir dosya ismi eşleştirme kalıbı da
olabilir. Kalıp dizgesinde, ?
herhangi bir tek karakterle,
*
herhangi bir karakter dizisiyle eşleşir. Ayrıca
[]
karakter aralıkları da kullanılabilir. ‘/’ karakteri
ile hiçbir kalıp karakteri eşleşmez, bu bakımdan <Directory
/*/public_html>
ile /home/user/public_html
değil, ama <Directory /home/*/public_html>
eşleşecektir. Örnek:
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
dizin-yolu argümanlarını belirtirken dikkatli
olmalısınız: Apache httpd’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 ~ abc$>
# ... yönergeler burada ...
</Directory>
düzenli ifadeli bölümü, tüm normal <Directory>
bölümleri ve
.htaccess
dosyaları uygulanıncaya kadar
değerlendirilmeyecektir. Düzenli ifadeleri değerlendirmeye sıra gelince
düzenli ifade /home/abc/public_html/abc
ile eşleştirilecek
ve buna ilişkin <Directory>
uygulanacaktır.
<Directory />
için öntanımlı erişimin tüm
erişime izin vermek oluşuna dikkat ediniz. Bunu şöyle bir blokla
değiştirmeniz,
<Directory />
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 dizinlerinin içeriklerine 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 dizininde ve içindeki dosyalarda uygulanacak
bir yönerge grubunu sarmalamakta kullanılır. Tek farkla argüman olarak
bir düzenli ifade alır. Örnek:
<DirectoryMatch "^/www/(.+/)?[0-9]{3}">
yönergesi /www/
içindeki üç rakamdan oluşan dizinlerle
eşleşecektir.
<Directory>
gibi) alt dizinlere de uygulanırdı
ve satır sonu simgesi ($) ile eşleşemezdi. 2.3.9 ve sonrasında, sadece
ifade ile eşleşen dizinler sarmalanan yönerge grubundan etkilenmektedir.
<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://my.example.com/index.html
isteği /usr/web/index.html
ile eşleştirilir.
dizin-yolu ile göreli dosya yolu belirtildiği takdirde belge
kök dizininin ServerRoot
ile
belirtilen sunucu kök dizinine göre belirtildiği varsayılır.
DocumentRoot
ile belirtilen dizin bir bölü
çizgisi ile bitirilmemelidir.
Açıklama: | Önceki bir <If> veya <ElseIf> bölümünün koşulu, çalışma anında bir istek tarafından yerine getirilmediği takdirde uygulanacak yönergeleri içerir |
---|---|
Sözdizimi: | <Else> ... </Else> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
<Else>
sadece ve sadece aynı etki
alanındaki en son <If>
veya
<ElseIf>
bölümü uygulanmamışsa
kapsadığı yönergeleri uygular. Örneğin:
<If "-z req('Host')">
...
</If>
<Else>
...
</Else>
Burada, <If>
yönergesi
Host: başlıksız HTTP/1.0 istekleriyle eşleşirken <Else>
Host: başlıklılarla
eşleşir.
<If>
<ElseIf>
<If>
,
<ElseIf>
ve
<Else>
son olarak uygulanır.Açıklama: | İçerdiği koşulun bir istek tarafınan sağlandığı ancak daha önceki bir <If> veya
<ElseIf> bölümlerininkilerin sağlanmadığı durumda kapsadığı yönergelerin uygulanmasını sağlar |
---|---|
Sözdizimi: | <ElseIf ifade> ... </ElseIf> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
<ElseIf>
kapsadığı yönergeleri
sadece ve sadece belirtilen koşulun doğrulandığı ancak aynı etki
alanında hemen önceki <If>
veya
<ElseIf>
yönergesinin uygulanmadığı
takdirde uygular. Örnek:
<If "-R '10.1.0.0/16'">
...
</If>
<ElseIf "-R '10.0.0.0/8'">
...
</ElseIf>
<Else>
...
</Else>
<ElseIf>
bir isteğin uzak adresi
10.0.0.0/8 ağına aitse ama 10.1.0.0/16 ağına ait değilse içerdiği
yönergelerin uygulanmasını sağlar.
<If>
<Else>
<If>
,
<ElseIf>
ve
<Else>
son olarak uygulanır.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 |
Uyumluluk: | none değeri Apache 2.2.7 ve sonrasında mevcuttur.
|
Bu yönerge, sunucunun teslimat sırasında gerektiği takdirde bir dosya
içeriğinin okunması için bellek eşleme kullanıp kullanmayacağını
belirler. Öntanımlı olarak, bir isteğin yerine getirilmesi,
mod_include
kullanarak sunucu tarafından çözümlenen
bir dosyanın teslimatı sırasında olduğu gibi, bir dosya içindeki veriye
erişilmesini gerektirdiğinde Apache httpd, işletim sistemi tarafından
desteklendiği takdirde dosyayı belleğe eşler.
Böyle bellek eşleme kimi zaman başarım artışını beraberinde getirirse de bazen sorunlardan kaçınmak için bellek eşlemeyi kapatmak daha iyi sonuç verir:
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 Off |
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. Öntanımlı değer 2.3.9 sürümünde Off olarak değişti. |
Bu yönerge, dosya içeriğinin istemciye teslimi için
httpd
’nin çekirdeğin dosya gönderme desteğini
kullanıp kullanmayacağını belirler. Öntanımlı olarak, bir isteğin
yerine getirilmesi, bir durağan dosyanın teslimatı sırasında olduğu
gibi, bir dosya içindeki veriye erişilmesini gerektirmediği takdirde
Apache httpd, işletim sistemi tarafından destekleniyorsa dosyayı
istemciye teslim etmek için çekirdeğin dosya gönderme özelliğini
kullanır.
Çekirdeğin dosya gönderme mekanizması, okuma, gönderme ve tampon ayırma işlemlerini ayrı ayrı yapmaktan kaçınır. Fakat bazı platformlarda veya bazı dosya sistemlerinde aşağıda belirtilen işlemsel sorunlardan kaçınmak için bu özelliği iptal etmek daha iyidir:
sendfile
) 2GB’tan büyük dosyalarla çalışamamaktadır.DocumentRoot
ağ dosya sistemi
(NFS, SMB, CIFS, FUSE gibi) üzerinde olduğu durumda çekirdek ağ
dosyalarını kendi arabelleği üzerinden sunamayabilir.Bu sorunlardan muzdarip sunucu yapılandırmaları için bu özelliği şöyle etkin kılabilirsiniz:
EnableSendfile On
Bu özellik, sadece bir ağ dosya sistemi üzerinde sunulan dosyaları kapsamak üzere şu şekilde kolayca kapatılabilir:
<Directory "/path-to-nfs-files">
EnableSendfile Off
</Directory>
EnableSendfile
yönergesinin .htaccess ve
diziniçi yapılandırmalarının mod_cache_disk
tarafından
desteklenmediğini lütfen aklınızdan çıkarmayın.
EnableSendfile
yönergesinin sadece küresel
tanımları hesaba katılır.
Açıklama: | Özel bir hata iletisiyle yapılandırma çözümlemesini durdurur |
---|---|
Sözdizimi: | Error ileti |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | 2.3.9 ve sonrası |
Yapılandırmada bir hatanın saptanması istenirse, bu yönerge yapılandırma çözümlemesinin durdurulması ve özel bir hata iletisi üretilmesi için kullanılabilir. Genelde kullanıldığı durum, gerekli modüllerin yapılandırmada bulunmadığının raporlanmasıdır.
# mod_include yüklü değilse bilelim
<IfModule !include_module>
Hata: mod_include mod_foo için gerekiyor. LoadModule ile yükleyin.
</IfModule>
# SSL veya NOSSL tanımlı mı bilelim
<IfDefine SSL>
<IfDefine NOSSL>
Hata: Ne SSL ne de NOSSL tanımlı. Sadece biri tanımlı olsa yeter.
</IfDefine>
</IfDefine>
<IfDefine !SSL>
<IfDefine !NOSSL>
Hata: Ya SSL ya da NOSSL tanımlı olmalı.
</IfDefine>
</IfDefine>
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 |
Bir sorun çıktığında veya hata oluştuğunda Apache httpd ş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 httpd
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.example.com/cgi-bin/dnmci
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Kusura bakmayın, bugün hizmet veremiyoruz."
ErrorDocument 403 Yasak!
Bunlardan başka, Apache httpd’nin kendi hata iletilerinin kullanılacağı
özel default
değeri ile belirtilebilir. Normal şartlar
altında gerekmese de, bir şey belirtilmediği takdirde mevcut bir
ErrorDocument
yönergesini miras alan
yapılandırmalarda Apache httpd’nin kendi hata iletilerinin kullanımı
default
değeri açıkça belirtilerek örnekteki gibi
zorlanabilir:
ErrorDocument 404 /cgi-bin/bad_urls.pl
<Directory /web/docs>
ErrorDocument 404 default
</Directory>
ErrorDocument
yönergesinde bir uzak URL (önünde
http
bulunan bir yol) belirtildiğinde, belge aynı sunucuda
olsa bile, Apache HTTP Sunucusunun istemciye belgeyi bulacağı yer için bir
yönlendirme göndereceğine dikkat ediniz. Bunun bazı istenmeyen etkileri
vardır; en önemlilerinden biri istemcinin hata kodu yerine bir
yönlendirme durum kodu alacak olmasıdır. Bu, bir URL’nin geçerliliğini
durum koduna göre saptayan istemciler veya robotlar için yanıltıcı
olacaktır. Buna ek olarak, ErrorDocument 401
için bir uzak
URL belirttiğiniz durumda istemci 401 durum kodunu almayacağı için
kullanıcıdan parola isteğinde bulunamayacaktır. Bu bakımdan,
ihtiyaç duyduğunuz takdirde, ErrorDocument 401
yönergesine yerel bir belge belirtmelisiniz.
Sunucunun ürettiği hata iletileri "çok kısa" olduğu takdirde, Microsoft Internet Explorer (MSIE) öntanımlı olarak bu hata iletilerini yoksayar ve bunun yerine kendi "kullanıcı dostu" hata iletilerini kullanır. "Çok kısa" eşiği duruma göre değişmekle birlikte, genellikle, hata iletileriniz 512 bayttan büyük olduğu takdirde MSIE kendi hata iletileri yerine sunucunun ürettiği hata iletilerini gösterecektir. Bu konuda daha fazla bilgiyi Q294807 kodlu Microsoft Knowledge Base makalesinde bulabilirsiniz.
Çoğu yerleşik hata iletisi özel iletilerle değiştirilebilse de bazı
durumlarda ErrorDocument
ile ne
belirtildiğine bakılmaksızın yerleşik hata iletileri kullanılır.
Özellikle, bozuk bir istek saptandığında normal istek işleme hemen
devre dışı bırakılır ve yerleşik hata iletisi döndürülür. Bu, hatalı
istekler yaparak güvenlik sorunlarına yol açılmak istenmesi
durumlarında gereklidir.
mod_proxy
kullanıyorsanız,
ProxyErrorOverride
yönergesini
etkin kılmak isteyebilirsiniz, böylece asıl sunucular adına özel hata
iletileri üretebilirsiniz. ProxyErrorOverride
etkin
kılınmak istenmezse, Apache httpd vekalet edilen içerik için özel hata
belgeleri üretmeyecektir.
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 için borulu günlüklere bakınız.
Dosya adı yerine syslog
kullanılırsa, sistem desteklediği
takdirde günlük kaydı syslogd(8) üzerinden yürütülür. Öntanımlı olarak
local7
syslog oluşumu kullanılır. Bunu
syslog:oluşum
sözdizimini kullanarak
değiştirebilirsiniz. Buradaki oluşum
syslog.conf(5) kılavuz sayfasında belirtilen oluşum isimlerinden biri
olabilir. Oluşum aslında küreseldir ve sanal konaklardan bazılarında
değiştirilmişse, belirtilen en son oluşum tüm sunucuyu
etkileyecektir.
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: | Hata günlüğü girdileri için biçem belirtimi |
---|---|
Sözdizimi: | ErrorLogFormat [connection|request] biçem |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache httpd 2.3.9 ve sonrasında kullanılabilmektedir. |
ErrorLogFormat
yönergesi, hata günlüğünde asıl
hata iletisine ek olarak günlüklenecek ek bilgiyi belirtmek için
kullanılabilir.
ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"
İlk değiştirge olarak connection
veya request
belirtilmesi ek biçemlerin belirtilebilmesini sağlar. Böylece, belli bir
bağlantı ya da istek için ilk ileti günlüklendiğinde ek bilgininde
günlüklenmesi sağlanır. Bu ek bilgi sadece bağlantı/istek başına bir
kere günlüklenir. herhangi bir günlük iletisine sebep olmadan işlenmişse
ek bilgi de günlüklenmez.
Bu, bazı biçem dizgesi öğeleri çıktı üretmediğinde olur. Örneğin,
Referer
başlığı sadece günlük iletisi bir istekle
ilişkilendirilmişse mevcuttur ve hata iletisi Referer
başlığı istemcide okunduğu anda oluşur. Eğer bir çıktı üretilmezse,
öntanımlı davranış önceki boşluk karakterinden sonraki boşluk
karakterine kadar herşeyi silmektir. Yani, günlük satırı örtük olarak
boşluklarla ayrılmış alanlara bölünür. Bir biçem dizgesi öğesi çıktı
üretmezse alanın tamamı çıktılanmaz. Örneğin, [%t] [%l] [%a]
%M
günlük biçeminde uzak adres %a
kullanılamazsa sarmalayıcı köşeli ayraçlar da günlüklenmeyecektir.
Boşluk karakterleri ters bölülerle öncelenerek bir alanı sınırlaması
önlenebilir. '% ' (yüzde boşluk) çifti sıfır genişlikte bir alan
ayracı olup herhangi bir çıktı üretmez.
Yukarıdaki davranış, biçem dizgesi öğesine değiştirciler eklenerek
değiştirilebilir. -
(tire) değiştircisi ilgili öğe bir
çıktı üretmediğinde tire iminin günlüklenmesine sebep olur.
Bağlantı/istek başına bir kere biçemlerinde +
(artı)
değiştircisini de kullanmak mümkündür.Artı değiştiricili bir öğe
herhangi bir çıktı üretmezse satırın tamamı günlüklenmez.
Bir biçem öğesine günlük önem derecesi atamak için değiştirici olarak bir sayı kullanılabilir. Bu öğenin günlüklenebilmesi için günlük iletisinin önem derecesinin belirtilen günlük önem derecesinden daha yüksek olmaması gerekir. Sayı 1'den (alarm) 4'e (uyarı) ve 7'den (hata ayıklama) 15'e (trace8) kadar olabilir.
Örneğin, Referer
istek başlığını günlükleyen
%{Referer}i
dizgeciğine değiştirciler eklendiğinde neler
olduğunu burada görebilirsiniz:
Değiştirlen Dizgecik | Anlamı |
---|---|
%-{Referer}i |
Referer atanmamışsa bir - günüklenir. |
%+{Referer}i |
Referer atanmamışsa satırın tamamı çıktılanmaz. |
%4{Referer}i |
Sadece hata iletisinin önemi 4'ten yüksek olduğu durumda
Referer günlüklenir. |
Bazı biçem dizfesi öğeleri ayraç içine alınmış ek değiştirgeler kabul eder.
Biçem Dizgesi | Açıklama |
---|---|
%% |
Yüzde imi |
%a |
İstekteki istemci IP adresi ve portu |
%{c}a |
Bağlantının emsal IP adresi and portu
(mod_remoteip modülüne bakın) |
%A |
Yerel IP adresi ve portu |
%{isim}e |
İstek ortam değişkeni isim |
%E |
APR/OS hata durum kodu ve iletisi |
%F |
Günlük çağrısının kaynak dosya ismi ve satır numarası |
%{isim}i |
İstek başlığı isim |
%k |
Bağlantıdaki keep-alive isteklerinin sayısı |
%l |
İletinin günlük seviyesi |
%L |
İsteğin günlük kimliği |
%{c}L |
Bağlantının günlük kimliği |
%{C}L |
Bağlantı etki alanında kullanılmışsa bağlantının günlük kimliği, aksi takdirde boş |
%m |
İletiyi günlükleyen modülün ismi |
%M |
Asıl günlük iletisi |
%{isim}n |
istek notu isim |
%P |
Geçerli sürecin süreç kimliği (PID'i) |
%T |
Geçerli evrenin evre kimliği |
%{g}T |
Geçerli evrenin eşsiz sistem evre kimliği (örn, top
tarafınan gösterilenle aynı kimlik: şimdilik sadece Linux'a
özgü) |
%t |
geçerli zaman |
%{u}t |
Mikro saniyeler dahil geçerli zaman |
%{cu}t |
ISO 8601 biçemiyle uyumlu mikro saniyeleri de içeren geçerli zaman |
%v |
Geçerli sunucunun kurallı ServerName |
%V |
UseCanonicalName ayarına
uygun olarak isteği sunan sunucunun sunucu ismi |
\ (tersbölü boşluk) |
Alan ayracı olmayan boşluk |
% (yüzde boşluk) |
Alan ayracı (çıktısız) |
The log ID format %L
günlük kimliği biçemi bağlantı veya
istek için eşsiz bir kimlik üretir. Bu, bağlantı üzerinden gelen istek
durumunda günlük satırlarının ait olduğu bağlantı veya isteği
bağdaştırmak için kullanılabilir. %L
biçem dizgesi ayrıca
mod_log_config
modülünde erişim günlüğü iletilerini
hata günlüğü iletileriyle ilşklendirmek için de kullanılabilmektedir.
mod_unique_id
modülü yüklüyse onun eşsiz kimliği
istekler için günlük kimliği olarak kullanılacaktır.
ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a]
%M% ,\ referer\ %{Referer}i"
Bunun hata iletilerindeki sonuçları şöyle olabilir:
[Thu May 12 08:28:57.652118 2011] [core:error] [pid 8777:tid 4326490112] [client ::1:58619] File does not exist: /usr/local/apache2/htdocs/favicon.ico
Dikkat edin, yukarıda açıklandığı gibi, bazı alanlar tanımlanmadıklarından tamamen yoksayılır.
ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a]
%M% ,\ referer\ %{Referer}i"
ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"
ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"
ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"
ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"
ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"
Açıklama: | Her istekte ek durum bilgisinin izini sürer |
---|---|
Sözdizimi: | ExtendedStatus On|Off |
Öntanımlı: | ExtendedStatus Off[*] |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
Bu yönerge, o an işlenmekte olan istek hakkında evre başına ek veriyi
ve kullanım özetini izler; mod_status
modülünü
yapılandırarak bu değişkenleri çalışma anında görebilirsiniz. Diğer
modüllerin bu sonuçlara bel bağlayabileceğini unutmayın.
Bu ayarlar sunucunun tamamına uygulanır ve bir sanal konakta etkin başka bir sanal konakta etkisiz kılınamaz. Ek durum bilgisinin toplanması sunucuyu yavaşlatabilir. Ayrıca, bu ayarın nazikçe yeniden başlatma sırasında değiştirilemeyeceğine dikkat ediniz.
Diğer üçüncü parti modüller aynısını yaparken
mod_status
modülünün yüklenmesi ExtendedStatus
On
için öntanımlı davranışı değiştirecektir. Böyle modüller,
tüm evrelerin durumu hakkında ayrıntılı bilgi toplanmasına bel bağlar.
Öntanımlı değer sürüm 2.3.6 itibariyle mod_status
tarafından değiştirilmiştir; önceki sürümlerde öntanımlı değer daima
Off
idi.
Açıklama: | Duruk dosyalar için ETag HTTP yanıt başlığını oluşturmakta kullanılacak dosya özniteliklerini belirler. |
---|---|
Sözdizimi: | FileETag bileşen ... |
Öntanımlı: | FileETag MTime Size |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | 2.3.14 ve öncesinde öntanımlı değer "INode MTime Size" idi. |
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.)
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
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.
FileETag
,
MTime
ve Size
değerleri değişmeksizin yanıt
öğesi değişebileceğinden mod_include
tarafından
çözümlenen yanıtlar için bir ETag
üretilmez.
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. ~
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 ortam türüyle sunulmasına sebep olur. |
---|---|
Sözdizimi: | ForceType ortam-türü|None |
Bağlam: | dizin, .htaccess |
Geçersizleştirme: | FileInfo |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache httpd 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 ortam-türü ile
belirtilen içerik türüyle sunulmasına sebep olur. Örneğin, altında
sadece GIF dosyaları bulunan bir dizininiz varsa ve bunlara tek tek
.gif
uzantısı belirtmek istemiyorsanız şu yapılandırmayı
kullanabilirsiniz:
ForceType image/gif
Bu yönerge, AddType
yönergesi
üzerinden ve mime.types
dosyasında örtük olarak
tanımlanmış ortam türü/dosya uzantısı ilişkilerini geçersiz kılar.
Ayrıca, daha genel ForceType
ayarlarını da
None
değeriyle geçersiz kılabilirsiniz:
# tüm dosyaların image/gif olarak sunulması için:
<Location /images>
ForceType image/gif
</Location>
# normal MIME-türüne geri dönmek için:
<Location /images/mixed>
ForceType None
</Location>
Bu yönerge, öncelikle dosya sisteminden sunulan duruk dosyalar için
üretilen içerik türlerini geçersiz kılar. Duruk dosyaların haricindeki
özkaynaklar için yanıt üretecinin genelde bir Content-Type
belirttiği durumda bu yönerge etkisizdir.
Açıklama: | gmon.out ayrıntılı inceleme verisinin yazılacağı dizin |
---|---|
Sözdizimi: | GprofDir /tmp/gprof/|/tmp/gprof/% |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Sunucu gprof ayrıntılı inceleme desteği ile derlenmişse,
GprofDir
yönergesi gmon.out
dosyalarının süreç çıktığında belirtilen dizine yazılmasını sağlar. Eğer
değiştirge bir yüzde simgesi ('%') ile bitiyorsa her süreç kimliği için
alt dizinler oluşturulur.
Bu yönerge şimdilik sadece prefork
MPM'i ile
çalışmaktadır.
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.
Son olarak, konak ismine dayalı
Require yönergelerine sahipseniz konak ismi araması
HostnameLookups
ayarına bakılmaksızın
gerçekleştirilecektir.
Açıklama: | Çalışma anında bir koşul bir istek tarafından yerine getirildiği takdirde uygulanacak yönergeleri barındırır. |
---|---|
Sözdizimi: | <If ifade> ... </If> |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | All |
Durum: | Çekirdek |
Modül: | core |
<If>
yönergesi bir ifadeyi çalışma
anında değerlendirir ve ifadenin sonucu doğru olduğu takdirde içerdiği
yönergeleri uygular. Örnek:
<If "-z req('Host')">
Bir Host: başlığı içermeyen HTTP/1.0 istekleriyle
eşleşir. İfadeler, dizge karşılaştırması (=
,
!=
, <
, ...), tamsayı karşılaştırması
(-eq
, -ne
, ...) ve diğerleri (-n
,
-z
, -f
, ...) için kabuktakilere benzer çeşitli
işleçler içerebilir. Ayrıca, düzenli ifadeleri,
<If "%{QUERY_STRING} =~ /(delete|commit)=.*?elem/">
kabuk tarzı kalıp eşleştirme ve birçok başka işlemi kullanmak da
mümkündür. Bu işlemler istek başlıklarında (req
), ortam
değişkenlerinde (env
) ve çok sayıda başka niteliklerin
üstünde yapılabilir. Apache HTTP Sunucusundaki
İfadeler belgesinde daha ayrıntılı bilgi bulabilirsiniz.
<ElseIf>
<Else>
<If>
,
<ElseIf>
ve
<Else>
son olarak uygulanır.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
veya Define
yönergesi ile
belirtilerek tanımlı hale getirilebilir.
<IfDefine>
bölümleri iç içe
olabilir, dolayısıyla çok parametreli basit sınamalar gerçeklenebilir.
Örnek:
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 cache_disk_module modules/mod_cache_disk.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 httpd içine dahil edilmişse veya
LoadModule
yönergesi ile devingen
olarak yüklenmişse işleme sokulur. İkinci durumda ise tersi yapılır, yani
sadece modül içerilmiş değil ise yönergeler
işleme sokulur.
modül argümanında bir modül betimleyici veya modülün derleme
sırasındaki dosya adı belirtilebilir. Örneğin, rewrite_module
bir betimleyici, mod_rewrite.c
ise bir dosya ismidir. Eğer
modül çok sayıda kaynak dosyasından oluşuyorsa
STANDARD20_MODULE_STUFF
dizgesini içeren dosyanın ismi
kullanılır.
<IfModule>
bölümleri iç içe
olabilir, dolayısıyla çok parametreli basit sınamalar gerçeklenebilir.
<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|joker |
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, dizin kalıbıyla eşleşme ise 2.3.6 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 yolun dosya
ismi ve dizin parçalarında kabuk tarzı (fnmatch()
) dosya
ismi kalıp karakterleri kullanılabilir. Ayrıca, eğer
Include
yönergesi bir dosya değil de bir dizin
gösteriyorsa Apache httpd bu dizindeki ve alt dizinlerindeki bütün
dosyaları okuyacaktır. Bunula birlikte, dizinin bir bütün olarak
okutulması önerilmez, çünkü dizinde httpd
programının
çökmesine sebep olabilecek geçici dosyalar unutulabilir. Bunun yerine,
belli bir şablona uyan dosyaları seçebilmek için, örneğin *.conf gibi
dosya kalıplarının kullanılmasını öneriyoruz.
Include
yönergesi, bir dosya
kalıbı ifadesi hiçbir dosyayla eşleşmezse bir hatayla
başarısız olacaktır. Eşleşmeyen dosya kalıbı ifadelerinin
yoksayılması gerekiyorsa IncludeOptional
yönergesi kullanılabilir.
Dosya yolu mutlak bir dosya yolu olarak belirtilebileceği gibi
ServerRoot
dizinine göreli olarak
da belirtilebilir.
Örnekler:
Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf
Veya dizinler ServerRoot
dizinine
göre belirtilebilir:
Include conf/ssl.conf
Include conf/vhosts/*.conf
Dosya kalıbı karakterleri yolun dizin ve dosya parçalarına
yerleştirilebilir. conf/vhosts
altında en azından bir
*.conf
içeren hiçbir alt dizin yoksa bu örnek başarısız
olacaktır:
Include conf/vhosts/*/*.conf
Bunun yerine, dizin ve dosyaların eksikliği durumunda aşağıdaki komut sadece yoksayılır:
IncludeOptional conf/vhosts/*/*.conf
Açıklama: | Diğer yapılandırma dosyalarının sunucu yapılandırma dosyasına dahil edilmesini sağlar |
---|---|
Sözdizimi: | IncludeOptional dosya-yolu|dizin-yolu|joker |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | 2.3.6 ve sonrasına kullanılabilmektedir. |
Bu yönerge, diğer yapılandırma dosyalarının sunucu yapılandırma
dosyasında içerilmesini sağlar. Çalışması Include
yönergesi ile bir istisna dışında
aynıdır. Dosya kalıp karakterlerinin hiçbir dosya veya dizinle
eşleşmemesi durumunda IncludeOptional
yönergesi bir hataya sebep olmak yerine
bunu sadece yoksayacaktır.
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,
MaxConnectionsPerChild
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 sayı[ms] |
Öntanımlı: | KeepAliveTimeout 5 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache httpd 2.3.2'den itibaren milisaniyelik değerler belirtilebilmektedir. |
Sunucunun kalıcı bir bağlantıyı kapatmadan önce bir sonraki isteği kaç
saniye bekleyeceğini belirler. Ayrıca, ms soneki kullanılarak süreyi
milisaniye olarak belirtmek de mümkündür. İstek alındıktan sonra
Timeout
yönergesiyle belirtilen
zaman aşımı değeri uygulanır.
KeepAliveTimeout
için yüksek bir değer belirtmek
ağır yüklü sunucularda başarım sorunlarına yol açar. Daha yüksek bir
zaman aşımı, boştaki istemcilerin bulunduğu bağlantıları bekleyen daha
fazla sunucu sürecini meşgul edecektir.
İsme dayalı sanal konak bağlamında, yerel IP adresi ve portu ile en iyi eşleşen ilk sanal konağın değeri kullanılır.
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: | dizin, .htaccess |
Geçersizleştirme: | AuthConfig, Limit |
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 (bkz, TraceEnable
).
<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.<Limit>
ve
<LimitExcept>
yönergeleri iç içe olabilirler. Bu durumda, başarılı her
<Limit>
veya <LimitExcept>
seviyesi, erişim
denetimlerinin uygulanacağı yöntemlerle sınırlı kalmalıdır.
<Limit>
veya
<LimitExcept>
yönergelerini
Require
yönergesi ile
birlikte kullanılırken, ilk Require
yönergesinin bir başka Require
yönergesinin varlığından
bağımsız olarak isteği başarıyla yetkilendirdiğine dikkat ediniz.Örneğin, aşağıdaki yapılandırmayı ele alalım; tüm kullanıcılar
POST
istekleri için yetkilendirilecek ve tüm durumlarda
Require group editors
yönergesi yoksayılacaktır:
<LimitExcept GET>
Require valid-user
</LimitExcept>
<Limit POST>
Require group editors
</Limit>
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: | dizin, .htaccess |
Geçersizleştirme: | AuthConfig, Limit |
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 httpd 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
httpd’nin kullandığı bir mekanizmadır. Örneğin,
mod_dir
, DirectoryIndex
yönergesinde listelenen dosyalara bakmak
için istek içi istekler kullanır.
LimitInternalRecursion
yönergesi sunucunun dahili
yönlendirmeler ve istek içi isteklerin oluşturduğu döngülerden dolayı
çökmemesini sağlar. Böyle döngüler genellikle yanlış yapılandırma sonucu
ortaya çıkarlar.
Yönerge her istek için değerlendirmeye alınacak iki farklı sınırlama için kullanılabilir. İlk sayı ardarda gelebilen dahili yönlendirmelerin azami sayısını, ikinci sayı ise istek içi isteklerin ne kadar iç içe olabileceğini belirler. Tek bir sayı belirtilirse iki sınırlama için de aynı değer kullanılır.
LimitInternalRecursion 5
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. Vekil isteklerinin snırlı uygulanabilirliği için aşağıdaki nota bakınız.
LimitRequestBody
yönergesi kullanıcıya yönergenin
kullanıldığı bağlam (sunucu, belli bir dizin, belli bir dosya, belli bir
yer) dahilinde bir HTTP istek iletisi gövdesinin izin verilen uzunluğu
için bir sınır belirleme imkanı verir. Eğer istemcinin isteği bu sınırı
aşarsa sunucu isteği sunmak yerine bir hata iletisi döndürecektir. Normal
bir istek ileti gövdesinin uzunluğu büyük oranda özkaynağın doğasına ve
bu özkaynak üzerinde izin verilen yöntemlere bağlıdır. CGI betikleri
genellikle ileti gövdesini form bilgisini almak için kullanır.
PUT
yöntemi gerçeklenimleri, en azından, sunucunun o
özkaynak için kabul etmek isteyeceği herhangi bir gösterim kadar büyük
bir değer gerektirecektir.
Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim imkanı sağlar.
Eğer, örneğin, belli bir yere dosya yükleme izni verir ve buraya yüklenebilecek dosya boyutunu 100 kB ile sınırlamak isterseniz yönergeyi şöyle kullanabilirsiniz:
LimitRequestBody 102400
Bu yönergenin vekil istekleri tarafından nasıl yorumlandığı
mod_proxy
belgesinde ayrıntılı olarak
açıklanmıştır.
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ıldığında, bu yönergenin değeri, yerel IP adresi ve port çifti için öntanımlı olan (listedeki ilk) sanal konaktan 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 ayarlama
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ıldığında, bu yönergenin değeri, yerel IP adresi ve port çifti için öntanımlı olan (listedeki ilk) sanal konaktan 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 ayarlama
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ıldığında, bu yönergenin değeri, yerel IP adresi ve port çifti için öntanımlı olan (listedeki ilk) sanal konaktan 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'nin yol bileşeni aşağıdaki koşullardan herhangi birini sağlıyorsa sarmalanan yönergeler isteğe uygulanır:
Aşağıdaki örnekte yer belirtimi bir bölü çizgisi ile bitirilmemiştir.
/private1
, /private1/
ve
/private1/file.txt
istekleri için sarmalanan yönergeler
uygulanacaktır, fakat /private1other
isteğine
uygulanmayacaktır.
<Location /private1>
...
Aşağıdaki örnekte yer belirtimi bir bölü çizgisi ile bitirilmiştir.
/private2/
ve /private2/file.txt
istekleri
için sarmalanan yönergeler uygulanacaktır, fakat /private2
ve /private2other
isteklerine 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 ve bir çok yazı tipinde ~
karakterini
-
karakterinden ayırmak zor olduğu için tercih edilir.
<Location>
işlevselliği özellikle
SetHandler
yönergesi ile birlikte
kullanışlı olur. Örneğin, durum isteklerini etkin kılmak ama sadece
example.com
’dan gelen isteklere izin vermek için şöyle bir
uygulama yapabilirsiniz:
<Location /status>
SetHandler server-status
Require host example.com
</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 [modül:]seviye
[modül:seviye] ...
|
Öntanımlı: | LogLevel warn |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Modül ve dizin bağlamındaki yapılandırmalar Apache HTTP Sunucusunun 2.3.6 ve sonraki sürümlerinde kullanılabilmektedir. |
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) |
trace1 |
İz sürme iletileri | "proxy: FTP: control connection complete" (vekil: FTP: denetim bağlantısı sağlandı) |
trace2 |
İz sürme iletileri | "proxy: CONNECT: sending the CONNECT request to the remote
proxy" (vekil: CONNECT: uzak vekile CONNECT isteği gönderiliyor) |
trace3 |
İz sürme iletileri | "openssl: Handshake: start" |
trace4 |
İz sürme iletileri | "read from buffered SSL brigade, mode 0, 17 bytes" (tamponlu SSL gruplamasından okuma, kip 0, 17 baytİz sürme iletileri |
trace5 |
İz sürme iletileri | "map lookup FAILED: map=rewritemap key=keyname" (eşleşme araması BAŞARISIZ: map=rewritemap key=keyname) |
trace6 |
İz sürme iletileri | "cache lookup FAILED, forcing new map lookup" (arabellek araması BAŞARISIZ, yeni bir eşleşme araması başlatılıyor) |
trace7 |
İz sürme iletileri, büyük miktarda veri dökümü | "| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |" |
trace8 |
İz sürme iletileri, büyük miktarda veri dökümü | "| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |" |
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.
Bir modül ismi olmaksızın bir seviye belirtmek seviyeyi bu seviyedeki
tüm modüller için sıfırlayacaktır. Bir seviyyi bir modül ismiyle
birlikte belirtmek seviyeyi sadece bu modül için sıfırlayacaktır. Modül
ismi olarak, modülün kaynak dosyası ismini, modül kimliği veya
_module
sonekli modül ismi belirtmek mümkündür.
Yani, aşağıdaki üç belirtim eşdeğerdedir:
LogLevel info ssl:warn
LogLevel info mod_ssl.c:warn
LogLevel info ssl_module:warn
Ayrıca seviyeyi dizin bağlamında değiştirmek de mümkündür:
LogLevel info
<Directory /usr/local/apache/htdocs/app>
LogLevel debug
</Files>
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ını döndürmeden önce izin verilen üst üste binen
aralık sayısı (100-200,150-300 gibi) |
---|---|
Sözdizimi: | MaxRangeOverlaps default | unlimited | none |
aralık-sayısı |
Öntanımlı: | MaxRangeOverlaps 20 |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache HTTP Sunucusunun 2.3.15 ve sonraki sürümlerinde kullanılabilmektedir. |
MaxRangeOverlaps
yönergesi, sunucunun istemciye
göndermeye gönüllü olacağı üst üste binen HTTP Range'lerinin sayısını
sınırlar. İzin verilenden daha fazlası istenmişse özkaynağın tamamı
döndürülür.
Açıklama: | Özkaynağın tamamını döndürmeden önce izin verilen ters sıralı
aralık sayısı (100-200,50-70 gibi) |
---|---|
Sözdizimi: | MaxRangeReversals default | unlimited | none |
aralık-sayısı |
Öntanımlı: | MaxRangeReversals 20 |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache HTTP Sunucusunun 2.3.15 ve sonraki sürümlerinde kullanılabilmektedir. |
The MaxRangeReversals
yönergesi, sunucunun
istemciye göndermeye gönüllü olacağı ter sıralı HTTP Range'lerinin
sayısını sınırlar. İzin verilenden daha fazlası istenmişse
özkaynağın tamamı döndürülür.
Açıklama: | Özkaynağın tamamını döndürmeden önce izin verilen aralık sayısı |
---|---|
Sözdizimi: | MaxRanges default | unlimited | none |
aralık-sayısı |
Öntanımlı: | MaxRanges 200 |
Bağlam: | sunucu geneli, sanal konak, dizin |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache HTTP Sunucusunun 2.3.15 ve sonraki sürümlerinde kullanılabilmektedir. |
MaxRanges
yönergesi, sunucunun istemciye
göndermeye gönüllü olacağı HTTP Range'lerinin sayısını sınırlar. İzin
verilenden daha fazlası istenmişse özkaynağın tamamı döndürülür.
Açıklama: | Muteks mekanizmasını ve kilit dosyası dizinini tüm muteksler veya belirtilenler için yapılandırır |
---|---|
Sözdizimi: | Mutex mekanizma [default|muteks-ismi] ... [OmitPID] |
Öntanımlı: | Mutex default |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache HTTP Sunucusunun 2.3.4 ve sonraki sürümlerinde kullanılabilmektedir. |
Mutex
yönergesi httpd ve diğer modüllerin
özkaynaklara erişimi dizgeleştirmekte kullandıkları mekanizmanın yanında
isteğe bağlı olarak kilit dosyasının yerini belirler. İlk değiştirge
olarak default
belirtilirse tüm mutekslerin ayarları
değişir; ilk değiştirge olarak bir muteks ismi belirtilirse (aşağıdaki
tabloya bakın) yalnızca bu muteksin öntanımlıları değişir.
Mutex
yönergesi genelde aşağıdaki istisnai
durumlarda kullanılır:
Bu yönerge sadece ap_mutex_register()
API'si kullanılarak
çekirdek sunucuda imlenmiş muteksleri yapılandırır. httpd ile birlikte
dağıtılan tüm modüller Mutex
yönergesini
destekler, fakat üçüncü parti modüllerin hepsi desteklemeyebilir. Bu
yönergenin desteklenip desteklenmediğini öğrenmek için üçüncü parti
modülün belgelerini inceleyin; destekliyorsa muteks ad(lar)ı
belirtilmiştir.
Kullanılabilen muteks mekanizmaları:
default | yes
APR tarafından saptanan öntanımlı kilitleme
gerçeklenimini seçer. Öntanımlı kilitleme gerçeklenimi
httpd
-V
seçeneği ile çalıştırılarak
öğrenilebilir.
none | no
Muteksi etkin şekilde iptal eder. Buna bir mutekste izin verilebilmesi için modülün bunun geçerli bir seçim olduğunu belirtmesi gerekir. Daha fazla bilgi için modül belgelerini inceleyin.
posixsem
POSIX semaforuna dayalı bir muteks çeşididir.
Süreçteki bir evre muteks parçalama arızalarını tutuyorsa, httpd'nin çökmesi sonucu, semafor sahipliği geri kazanılmaz.
sysvsem
SystemV IPC semaforuna dayalı bir muteks çeşididir.
Semafor geri kazanılmadan süreçler çökerse SysV semaforlarının "sızıntı" yapması mümkündür.
Semafor API'si, HTTP sunucusu ile aynı kullanıcı kimliği altında
çalışan bir CGI (örn, suexec
veya
cgiwrapper
gibi bir araç kullanmıyorsanız bütün
CGI'ler) tarafından hizmet reddi saldırısı yapılmasına izin
verir.
sem
POSIX ve SystemV IPC semaforları arasından kullanılabilir "en iyi" semafor gerçeklenimini seçer.
pthread
Süreç çaprazlamalı POSIX evre mutekslerine dayalı bir muteks çeşididir.
Çoğu sistemde, bir çocuk süreç bu gerçeklenim tarafından kullanılan bir muteksi tutarken olağandışı bir şekilde sonlanırsa httpd donar ve isteklere yanıt vermeyi durdurur. Bu olduğunda sunucuyu bu durumdan kurtarmak için elle yeniden başlatmak gerekir.
Bu duruma karşı bir mekanizma sağlayan Solaris dikkate değer bir istisnadır. Bu mekanizma, bir muteksi tutan bir çocuk süreç olağandışı bir şekilde sonlandıktan sonra muteksin kurtarılmasını sağlar.
Sisteminiz pthread_mutexattr_setrobust_np()
işlevini
sağlıyorsa pthread
seçeneğini rahatça
kullanabilirsiniz.
fcntl:/path/to/mutex
Muteks olarak fcntl()
işlevini ve fiziksel bir (lock-)
dosyasını kullanan bir muteks çeşididir.
Bu mekanizmaya dayalı çok sayıda muteks, çok evreli ve çok süreçli
ortamlarda kullanıldığında, örneğin Solaris'te olduğu gibi
fcntl()
evrelerden bihaberse, geçerli muteks
işlemlerinde donma hataları (EDEADLK) raporlanabilir.
flock:/path/to/mutex
flock()
işlevinin dosya kilitlemeyi sağlaması dışında
fcntl:/path/to/mutex
yöntemine benzer.
file:/path/to/mutex
fcntl
ve flock
arasından kullanılabilir
"en iyi" dosya kilitleme gerçeklenimini seçer.
Çoğu mekanizma, yalnız kendilerini destekleyen platformlarda APR tarafından da destekleniyorsa kullanılabilir. Tüm platformlarda kullanılamayan mekanizmalar posixsem, sysvsem, sem, pthread, fcntl, flock ve file mekanizmalarıdır.
fcntl ve flock dosya tabanlı mekanizmaları ile bir
yol sağlandığı takdirde bu, kilit dosyasının oluşturulacağı dizindir.
Öntanımlı dizin, httpd'nin çalışma anı dizini ServerRoot
'a görelidir.
/path/to/mutex
için daima bir yerel diskteki dosya sistemi
kullanılır, asla NFS- veya AFS gibi bir ağ dosya sistemi kullanılmaz.
Dosya ismi daima muteks ismi ile başlar, buna modül tarafından sağlanan
isteğe bağlı bir aşama dizgesi eklenebilir, OmitPID
değeri
belirtilmemişse httpd ebeveyn sürecinin süreç kimliği buna eklenerek
dosya ismi eşsiz kılınır. Böylece, çok sayıda httpd süreci aynı kilit
dosyası dizinini paylaştığı durumda çakışmalar önlenmiş olur. Örneğin,
muteks ismi mpm-accept
ise ve kilit dosyası dizini
/var/httpd/locks
ise ve ebeveyn süreç kimliği 12345 ise bu
httpd sürecine ait kilit dosyası ismi
/var/httpd/locks/mpm-accept.12345
olurdu.
Muteks dosyalarını herkesin yazabildiği /var/tmp
gibi
dizinlere koymaktan kaçınmak en iyisidir. Örneğin, birinin aynı
dizinde oluşturmaya çalıştığı bir dosya ile aynı isimde bir kilit
dosyasını sunucunun da oluşturmaya çalıştığı durumda sunucu engellenerek
bir hizmet reddi saldırısı gerçekleştirilmiş gibi olur.
httpd ve birlikte dağıtılan modüller tarafından kullanılan mutekslerin isimleri:
Muteks ismi | Modül(ler) | Korunan özkaynak |
---|---|---|
mpm-accept |
prefork ve worker MPM'leri
|
Gürleyen sürü sorunundan kaçınmak için gelen bağlantılar; daha fazla bilgi için başarımın arttırılması belgesine bakın. |
authdigest-client |
mod_auth_digest |
Paylaşımlı bellekteki istemci listesi |
authdigest-opaque |
mod_auth_digest |
Paylaşımlı bellekteki sayaç |
ldap-cache |
mod_ldap |
LDAP sonuç arabelleği |
rewrite-map |
mod_rewrite |
Çoklu isteklerdeki birbirine karışmış G/Ç'tan kaçınmak için harici eşleştirme progamlarıyla iletişim |
ssl-cache |
mod_ssl |
SSL oturum arabelleği |
ssl-stapling |
mod_ssl |
OCSP zımbalama yanıtı arabelleği |
watchdog-callback |
mod_watchdog |
Bir istemci modülünün geri çağırım işlevi |
OmitPID
seçeneği, httpd ebeveyn süreç kimliğinin kilit
dosyası ismine eklenmesini engeller.
Aşağıdaki örnekte, mpm-accept
muteksinin mekanizmasının
derleme sırasındaki öntanımlısı, kilit dosyasının oluşturulacağı dizinin
/var/httpd/locks
olarak belirtildiği fcntl
mekanizmasıyla değiştirilmektedir.Tüm diğer mutekslerin derleme anı
öntanımlı mekanizması ise sysvsem
ile
değiştirilmektedir.
Mutex sysvsem default
Mutex fcntl:/var/httpd/locks mpm-accept
Açıklama: | ÖNERİLMİYOR: İsme dayalı sanal konaklar için IP adresi belirtir |
---|---|
Sözdizimi: | NameVirtualHost adres[:port] |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
2.3.11 öncesinde, NameVirtualHost
yönergesi, isme dayalı sanal konaklar için belli bir IP adresi ve port çiftini sunucuya tanıtmak için gerekliydi. 2.3.11 ve sonrasında, bir IP adresi ve port çifti her zaman çok sayıda sanal konakta kullanılabilmekte, isme dayalı sanal barındırma bu adres için özdevinimli olarak etkin kılınmaktadır.
Bu yönerge şu an etkisizdir.
Açıklama: | Belli bir dizinde geçerli olacak özellikleri yapılandırır. |
---|---|
Sözdizimi: | Options
[+|-]seçenek [[+|-]seçenek] ... |
Öntanımlı: | Options FollowSymlinks |
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess |
Geçersizleştirme: | Options |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | 2.3.11 sürümünde öntanımlı değer All değiştirilip FollowSymlinks yapıldı. |
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.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.
Ayrıca, bu seçenek bir <Location>
bölümü içinde belirtildiği takdirde yok
sayılı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.
mod_negotiation
karşılaştırmak değerlendirmek için gerçek özkaynaklara ihtiyaç
duyduğundan <Directory>
yönergesinde belirtilendan farklı bir yer
ayarlanırsa bu seçenek yoksayılır.
SymLinksIfOwnerMatch
Bu seçenek bir <Location>
bölümü içinde belirtildiğinde yok
sayılı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ı aslında geçersiz bir sözdizimi olup sunucunun
başlatılması sırasında sözdizimi denetiminin çıkmasıyla reddedilir.
Ö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 FollowSymlinks
ö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: | Apache httpd 2.1.5 ve sonrasında kullanılabilmektedir. Windows'ta ise Apache httpd 2.3.3 ve sonrasında kullanılabilmektedir. |
Bu yönerge dinlenen belli bir soket için kullanılacak protokolü
belirler. Belirtilen protokol bir isteği hangi modülün ele alacağını ve
AcceptFilter
yönergesiyle yapılan özel
eniyilemelere uygulanacak protokolü belirler.
Bir protokol belirtme ihtiyacını sadece standartdışı portlarda
çalışıyorsanız duyarsınız. Aksi takdirde, http
protokolünün
port 80'i, https
'in ise 443'ü kullandığı varsayılır.
Örneğin, https
'i standartdışı bir portta çalıştırmak
isterseniz protokolü şöyle belirtebilirsiniz:
Protocol https
Protokolü Listen
yönergesini
kullanarak da belirtebilirsiniz.
AcceptFilter
Listen
Açıklama: | Apache httpd 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 httpd’nin kendi alt süreçlerine değil, isteklere yanıt verirken Apache httpd 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 httpd süreci tarafından çatallanmış süreçler olmazlar.
İşlemci özkaynak sınırları saniye cinsinden ifade edilir.
Açıklama: | Apache httpd 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 httpd’nin kendi alt süreçlerine değil, isteklere yanıt verirken Apache httpd 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 httpd 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 httpd 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 httpd’nin kendi alt süreçlerine değil, isteklere yanıt verirken Apache httpd 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 httpd 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: | 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
HTTP Sunucusunun 2.0 ve sonraki sürümleri için geçerlidir. |
Bu yönerge Apache httpd’nin CGI betiklerini çalıştıracak yorumlayıcıyı
nasıl tespit edeceğini belirler. Script
öntanımlı olup
Apache httpd’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.
ScriptAlias
’lı dizinlerde
Apache httpd 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 HTTP Sunucusunun 2.0
sürümünde 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: | İsteğin 63 karakterden büyük olduğu varsayımıyla, mod_status'un ilk 63 karakteri mi yoksa son 63 karakteri mi göstereceğini belirler. |
---|---|
Sözdizimi: | SeeRequestTail On|Off |
Öntanımlı: | SeeRequestTail Off |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
Uyumluluk: | Apache httpd 2.2.7 ve sonrasında kullanılabilmektedir. |
mod_status
modülü ExtendedStatus On
ile işleme alınan asıl isteği gösterir. Tarihsel amaçlarla, isteğin
sadece 63 karakteri gösterme amacıyla saklanır. Bu yönerge ilk 63
karakterin mi (önceki davranış ve öntanımlı durum) yoksa son 63
karakterin mi saklanacağını belirler. Bu, şüphesiz, isteğin uzunluğu 64
karakter veya daha fazlaysa uygulanabilirdir.
Apache httpd'ye gelen istek GET /disk1/storage/apache/htdocs/images/imagestore1/food/apples.jpg HTTP/1.1
ise mod_status
şunu gösterir:
Off (öntanımlı) | GET /disk1/storage/apache/htdocs/images/imagestore1/food/apples |
---|---|
On | orage/apache/htdocs/images/imagestore1/food/apples.jpg HTTP/1.1 |
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@example.com
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 server.example.com
ServerAlias server server2.example.com server2
ServerAlias *.example.com
UseCanonicalName Off
# ...
</VirtualHost>
İsme dayalı sanal konaklardan en iyi eşleşme kümesinde olanlar
yapılandırmada göründükleri sıraya göre işleme sokulur. Joker
kullanımları arasında fark gözetilmeksizin ServerName
veya ServerAlias
yönergesi eşleşen ilk sanal konak
kullanılı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 |
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.
Ek olarak, isme dayalı sanal
konaklar kullanılırken bir sanal konağı eşsiz bir şekilde betimlemek
için de ServerName
kullanılır (muhtemelen
ServerAlias
ile birlikte).
Örneğin, HTTP
sunucusunun barındırıldığı makinenin ismi mail.example.com
olduğu halde makinenin bir de www.example.com
diye bir de
DNS rumuzu varsa ve HTTP sunucunuzun bu rumuzla kendini
özdeşleştirmesini isterseniz bunu şöyle belirtebilirsiniz:
ServerName www.example.com
ServerName
yönergesi sunucu tanımının içinde
herhangi bir yerde görünebilirse de her göründüğü yerde bir öncekini
iptal eder.
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.
ServerName
yönergesine isim atamadaki bir
başarısızlık, sunucu başlatılırken isim bir IP adresine
çözümlenebileceğinden bir uyarı çıktılanmasına sebep olur.
httpd
böyle bir durumda sistemin hostname
komutunu kullanarak saptadığı konak ismini kullanacaktır. Bu konak ismi
hemen hemen daima sizin istediğiniz isim olmayacaktır.
httpd: Could not reliably determine the server's fully qualified domain name, using belgeler.yerel for ServerName
Çevirisi: Sunucunun tamamen nitelenmiş alan adı gerektiği gibi saptanamadı, ServerName için belgeler.yerel kullanılıyor
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
ServerRoot
için öntanımlı yer configure
betiğinin
--prefix
seçeneği ile değiştirilebilir ve sunucunun çoğu
üçüncü parti dağıtıcısı öntanımlı yeri yukardakilerden farklı bir yere
ayarlar.
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 Full
(veya belirtilmezse)Server: Apache/2.4.1
(Unix) PHP/4.2.2 MyMod/1.2
ServerTokens Prod[uctOnly]
Server:
Apache
ServerTokens Major
Server:
Apache/2
ServerTokens Minor
Server:
Apache/2.4
ServerTokens Min[imal]
Server:
Apache/2.4.1
ServerTokens OS
Server: Apache/2.4.1
(Unix)
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.
ServerTokens
yönergesinde
minimal
'den azının belirtilmesi önerilmez. Bunun sebebi ara
işlemlerle ilgili hata ayıklamasını zorlaştırmasıdır. Ayrıca,
Server:
başlığının iptal edilmesinin sunucunuzu daha güvenli
yapmayacağına dikkat ediniz; "çapraşıklıkla sağlanan güvenlik" düşüncesi
gerçekle bağdaşmaz ve güvenliği olumsuz etkiler.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 httpd 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.
SetHandler
yönergesi,
öntanımlı eylemcileri geçersiz kıldığından, index dosyaları ve dizinleri
belirtmek için URL’nin sonuna bölü çizgisi (/) getirmek şeklindeki
normal davranış baskılanır.
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: | 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 60 |
Bağlam: | sunucu geneli, sanal konak |
Durum: | Çekirdek |
Modül: | core |
TimeOut
yönergesi Apache httpd’nin aşağıdaki
durumlarda G/Ç için bekleyeceği süreyi belirler:
mod_cgi
modülünde, bir CGI betiğinden çıktı için
beklenecek süre.mod_ext_filter
modülünde, bir süzme işleminden çıktı
almak için beklenecek süre.mod_proxy
modülünde, ProxyTimeout
yönergesi
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 HTTP Sunucusunun 1.3.34, 2.0.55 ve sonraki sürümlerinde kuallanılabilir. |
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.
Aksine iddialara rağmen, TRACE
bir güvenlik açığı değildir
ve iptal etmek için geçerli hiçbir sebep yoktur. Böyle yapmak sunucunuzu
uyumsuz yapmaktan başka işe yaramaz.
Açıklama: | Bir değişkeni tanımsız yapar |
---|---|
Sözdizimi: | UnDefine değişken-ismi |
Bağlam: | sunucu geneli |
Durum: | Çekirdek |
Modül: | core |
Define
yönergesinde veya
httpd
'nin -D
seçeneğiyle belirtileni
geri alır.
Bu yönerge başlatma betiklerinde -D
seçeneğinin argümanını
değiştirmek gerekmeksizin <IfDefine>
bölümlerinin kullanımını değiştirmek için
kullanılabilir.
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 httpd‘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 httpd, 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 httpd, ö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 httpd onları
http://www.example.com/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.example.com
için; daha fazla bilgi için
SSS’ye bakınız). Fakat UseCanonicalName Off
olsaydı Apache httpd 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 httpd, 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 httpd‘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 httpd
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
ile sağlanan port
UseCanonicalName 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,
istemlik olarak ikinokta imi ve bir port numarası (veya *)
eklenebilir:
*
karakteri.*
için bir takma ad olarak _default_
dizgesi.
<VirtualHost 10.1.2.3:80>
ServerAdmin webmaster@host.example.com
DocumentRoot /www/docs/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
TransferLog logs/host.example.com-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]>
ServerAdmin webmaster@host.example.com
DocumentRoot /www/docs/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
TransferLog logs/host.example.com-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
httpd’nin dinleyeceği adresler üzerinde belirleyici değildir. Apache
httpd’nin doğru adresi dinlediğinden emin olmak için Listen
kullanmanız gerekebilir.
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.
Bir istek alındığında, sunucu isteği, sadece yerel IP adresi ve port
çiftine dayalı en iyi eşleşen ilk <VirtualHost>
bölümüne eşler. Joker kullanmayanlar daha
yüksek önceliğe sahiptir. IP ve port çiftine dayalı bir eşleşme
bulunamazsa istek için ana sunucu yapılandırması kullanılır.
En iyi eşleşen IP adresi ve port çiftini birden fazla sanal konak kullanıyorsa sunucu bu sanal konaklar (liste) arasından istenen konak ismiyle en iyi eşleşeni seçer. Eşleşen hiçbir isme dayalı sanal konak yoksa listedeki IP adresi ile eşleşen ilk sanal konak kullanılır. Bunun sonucu olarak, belirtilen IP adresi ve port çifti için listedeki ilk sanal konak, bu IP adresi ve port çifti için öntanımlı sanal konaktır.
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.