core
Apache HTTP Sunucusunda daima mevcut olan çekirdek özellikler
Core
AcceptFilter
Bir protokolün dinleyici soketleri için en iyilemeleri ayarlar
AcceptFilter protocol kabul_süzgeci
server config

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

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

AcceptFilter nntp none

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

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

AcceptFilter http httpready AcceptFilter https dataready

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

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

AcceptFilter http data AcceptFilter https data

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

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

AcceptFilter http connect AcceptFilter https connect

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

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

# `data` AcceptFilter (Windows)

2.4.23 ve öncesi sürümlerde, Windows `data` accept süzgeci veri aktarılana kadar bekletildikten sonra ilk veri tamponlanır ve uç ağ adresi için tek bir AcceptEx() çağrısı yapılır. Bu gerçeklenim hizmet reddi saldırısına konu olduğundan iptal edilmiştir.

httpd'nin şu anki dağıtımları için Windows'da `connect` süzgeci öntanımlıdır ve `data` belirtilmiş olsa dahi `connect` belirtilmiş gibi davranılır. Önceki sürümleri kullananların AcceptFilter satırını yukarıdaki gibi `connect` süzgecine ayarlamaları gerekmektedir.

Protocol
AcceptPathInfo
Dosya isminden sonra belirtilen yol verisini kabul veya reddeder.
AcceptPathInfo On|Off|Default
AcceptPathInfo Default
server config
virtual host
directory
.htaccess
FileInfo

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

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

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

`Off`
  Sadece dosya isminden sonra yol verisi bulunmayan istekler kabul edilir. Yukarıdaki örnekteki gibi `/test/here.html/more` şeklindeki istekler bir 404 (Nesne bulunamadı) hatasıyla sonuçlanır.
`On`
  Mevcut bir dosyaya ait bir dosya isminden sonra bir yol verisinin de belirtildiği istekler kabul edilir. Yukarıdaki örnekteki gibi `/test/here.html/more` şeklindeki istekler, `/test/here.html` geçerli bir dosya olduğu takdirde kabul edilir.
`Default`
  Dosya isminden sonra yol verisi belirtilen isteklerin nasıl ele alınacağı istekten sorumlu eylemci tarafından saptanır. Normal dosyalar için çekirdek eylemci öntanımlı olarak `PATH_INFO` isteklerini reddeder. `cgi-script` ve `isapi-handler` gibi betiklere hizmet eden eylemciler ise genellikle `PATH_INFO` isteklerini öntanımlı olarak kabul ederler.

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

<Files "mypaths.shtml"> Options +Includes SetOutputFilter INCLUDES AcceptPathInfo On </Files>
AccessFileName
Dağıtık yapılandırma dosyasının ismi belirtilir.
AccessFileName filename [filename] ...
AccessFileName .htaccess
server config
virtual host

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.

AllowOverride
Yapılandırma Dosyaları
.htaccess Dosyaları
AddDefaultCharset
Bir yanıtın içerik türü `text/plain` veya `text/html` olduğunda eklenecek öntanımlı karakter kümesi parametresini belirler.
AddDefaultCharset On|Off|karküm
AddDefaultCharset Off
server config
virtual host
directory
.htaccess
FileInfo

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.

AddCharset
AllowEncodedSlashes
Kodlanmış dosya yolu ayracı içeren URL’lere izin verilip verilmeyeceğini belirler.
AllowEncodedSlashes On|Off|NoDecode
AllowEncodedSlashes Off
server config
virtual host
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.

# Ek Bilgi

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.

AcceptPathInfo
AllowOverride
.htaccess
dosyalarında bulunmasına izin verilen yönerge türleri belirtilir.
AllowOverride All|None|yönerge-türü [yönerge-türü] ...
AllowOverride None (2.3.9 ve sonrası), AllowOverride All (2.3.8 ve öncesi)
directory

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.

# Sadece <Directory> bölümlerinde geçerli

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

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

AuthConfig
  AuthDBMGroupFile
  , AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require ve benzeri yetkilendirme yönergelerinin kullanımını izin verilir.
FileInfo
  Belge türünü denetleyen mod_mime `Add*` ve `Remove*` yönergeleri, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter yönergeleri ve benzerleri ile Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName belge meta veri yönergelerinin, mod_rewrite modülündeki RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule yönergelerinin, mod_alias modülündeki Redirect, RedirectTemp, RedirectPermanent, RedirectMatch) yönergelerinin ve mod_actions modülündeki Action yönergesinin kullanımına izin verilir.
Indexes
  Dizin içeriğinin listelenmesini denetleyen AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, `FancyIndexing`, HeaderName, IndexIgnore, IndexOptions, ReadmeName yönergelerinin ve benzerlerinin kullanımına izin verilir.
Limit
  Konak erişimini denetleyen Allow, Deny ve Order yönergelerinin kullanımına izin verilir.
Nonfatal=[Override|Unknown|All]
  .htaccess dosyalarındaki sözdizimi hatalarının ölümcül olarak ele alınmaması için `AllowOverride` yönergesinin kullanımına izin verir; bunun yerine bir dahili sunucu hatasına sebep olur, izin verilmeyen veya tanınmayan yönergeler yoksayılır ve günlüğe bir uyarı çıktılanır:
  - Nonfatal=Override ile `AllowOverride` tarafından yasaklanmış yönergeler ölümcül olarak ele alınmaz.
  - Nonfatal=Unknown ile bilinmeyen yönergeler ölümcül olarak ele alınmaz. Yazım hatalarını ve mevcut olmayan bir modül tarafından gerçeklenmiş yönergeleri kapsar.
  - Nonfatal=All ile yukarıdakilerin ikisi de ölümcül olarak ele alınmaz.

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

  # Güvenlik

  Ölümcül olmayan hatalar .htaccess kullanıcıları için güvenlikle ilgili sorunlara yol açabilir. Örneğin `AllowOverride AuthConfig`'e izin vermezse kullanıcıların siteye erişimini kısıtlayan yapılandırma iptal edilmiş olur.
Options[=seçenek,...]
  Dizinlere özgü özellikleri denetleyen Options ve XBitHack yönergelerinin kullanımına izin verilir. Options komutunda belirtilecek seçenekler bir eşit işaretinden sonra aralarına sadece virgül konarak, fakat virgülden sonra boşluk bırakmadan belirtilebilir.

  # Options'ın örtük iptali

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

  AllowOverride Options=Indexes,MultiViews

Örnek:

AllowOverride AuthConfig Indexes

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

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.

AccessFileName
AllowOverrideList
Yapılandırma Dosyaları
.htaccess Dosyaları
.htaccess için Geçersizleştirme Sınıfları
AllowOverrideList
.htaccess
dosyalarında izin verilecek yönergeler tek tek belirtilir
AllowOverrideList None|yönerge [yönerge-türü] ...
AllowOverrideList None
directory

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.

# Sadece <Directory> bölümlerinde kullanılabilir

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.

AccessFileName
AllowOverride
Yapılandırma Dosyaları
.htaccess Dosyaları
CGIMapExtension
CGI betik yorumlayıcısını saptama tekniğini belirler.
CGIMapExtension cgi-yolu .uzantı
directory
.htaccess
FileInfo
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.

CGIPassAuth
HTTP yetkilendirme başlıklarının betiklere CGI değişkenleri olarak aktarılmasını etkin kılar
CGIPassAuth On|Off
CGIPassAuth Off
directory
.htaccess
AuthConfig
Apache HTTP Sunucusunun 2.4.13 ve sonraki sürümlerinde kullanılabilmektedir

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

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

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

CGIVar
Bazı CGI değişkenlerinin nasıl atanacağını belirler
CGIVar değişken kural
directory
.htaccess
FileInfo
Apache HTTP Server 2.4.21 ve sonrasında kullanılabilir

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

REQUEST_URI kuralları:

`original-uri` (default)
  Değer özgün istek satırından alınır ve dahili yöneldirmeler veya istenen özkaynakları değiştiren alt istekler dikkate alınmaz.
`current-uri`
  Değer özgün istek satırından farklı olabilecek dahili yönlendirmeleri veya istenen özkaynakları değiştiren alt istekleri de yansıtır.

ContentDigest
Content-MD5
HTTP yanıt başlıklarının üretimini etkin kılar.
ContentDigest On|Off
ContentDigest Off
server config
virtual host
directory
.htaccess
Options
Experimental

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.

DefaultRuntimeDir
Sunucunun çalışma anı dosyaları için temel dizin
DefaultRuntimeDir dizin-yolu
DefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/)
server config
Apache 2.4.2 ve sonrasında kullanılabilmektedir.

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

Örnek

DefaultRuntimeDir scratch/

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

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

ServerRoot
üzerindeki izinlerin düzgün olarak nasıl ayarlanacağını öğrenmek için: güvenlik ipuçları
DefaultType
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.
DefaultType ortam-türü|none
DefaultType none
server config
virtual host
directory
.htaccess
FileInfo
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.

Define
Bir değişken tanımlar
Define değişken-ismi [değişken-değeri]
server config
virtual host
directory

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

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

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

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

# Sanal konak bağlamı ve tuzaklar

Bu yönerge sanal konakta ve dizin içeriğinde desteklendiğinden yapılan değişiklikler (eşleşsin eşleşmesin) yönergeyi sarmalayan yapılandırma bölümünden başka, sonraki yapılandırma yönergelerine de görünür olur.

UnDefine
IfDefine
Directory
Sadece ismi belirtilen dosya sistemi dizininde ve bunun altdizinlerinde ve bunların içeriğinde uygulanacak bir yönerge grubunu sarmalar.
<Directory dizin-yolu> ... </Directory>
server config
virtual host

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

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

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

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}">

</Directory>

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

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

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

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

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

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

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

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

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

`<Directory "/">` için öntanımlı erişimin tüm erişime izin vermek oluşuna dikkat ediniz. Bunu şöyle bir blokla değiştirmeniz,

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

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

Dizin bölümleri `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.

Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.
DirectoryMatch
Bir düzenli ifade ile eşleşen dosya sistemi dizinlerinin içeriklerine uygulanacak bir yönerge grubunu sarmalar.
<DirectoryMatch düzifd> ... </DirectoryMatch>
server config
virtual host

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

düzenli ifade
alır. Örnek:

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

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

# Uyumluluk

2.3.9 öncesinde, bu yönerge örtük olarak (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.

# Sondaki bölü çizgileri

Bu yönerge bir bölü çizgisi ile sonlanan veya sonlanmayan dizinler için yapılan isteklere uygulanır, dolayısıyla satır sonuna ($) çıpalanmış ifadeler dikkatli yazılmalıdır.

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

<DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)"> require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example </DirectoryMatch>
Normal Directory bölümlerindeki yönergelerle düzenli ifadelerin nasıl karıştırıldığının bir açıklaması için Directory yönergesine bakınız.
Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.
DocumentRoot
İstemciye görünür olan ana belge ağacının kök dizinini belirler.
DocumentRoot dizin-yolu
DocumentRoot "/usr/local/apache/htdocs"
server config
virtual host

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.

URL’lerin Dosya Sistemi ile Eşlenmesi
Else
Ö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
<Else> ... </Else>
server config
virtual host
directory
.htaccess
All
İç içe geçmiş koşullar 2.4.26 ve sonrasında değerlendirilmeye alınır

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
Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız. If, ElseIf ve Else son olarak uygulanır.
ElseIf
İç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
<ElseIf ifade> ... </ElseIf>
server config
virtual host
directory
.htaccess
All
İç içe geçmiş koşullar 2.4.26 ve sonrasında değerlendirilmeye alınır

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.

Tam bir kaynak ve daha fazla örnek için: Apache HTTP Sunucusundaki ifadeler
If
Else
Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız. If, ElseIf ve Else son olarak uygulanır.
EnableMMAP
Teslimat sırasında okunacak dosyalar için bellek eşlemeyi etkin kılar.
EnableMMAP On|Off
EnableMMAP On
server config
virtual host
directory
.htaccess
FileInfo
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:

- Bazı çok işlemcili sistemlerde bellek eşleme httpd’nin başarımını düşürebilmektedir.
- httpd
  bellek eşlemli çalışırken bir dosyanın silinmesi veya boyutunun küçültülmesi httpd'nin parçalama arızası vererek çökmesine yol açabilir.

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

EnableMMAP Off

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

<Directory "/nfs-dosyaları-yolu"> EnableMMAP Off </Directory>
EnableSendfile
Dosyaların istemciye tesliminde çekirdeğin dosya gönderme desteğinin kullanımını etkin kılar.
EnableSendfile On|Off
EnableSendfile Off
server config
virtual host
directory
.htaccess
FileInfo
Ö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:

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

Bu sorunlardan muzdarip sunucu yapılandırmaları için bu özelliği şöyle etkin kılabilirsiniz:

EnableSendfile On

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

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

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

HttpProtocolOptions
HTTP İstek İletilerindeki sınırlamalarda değişiklik yapar
HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods] [Allow0.9|Require1.0]
HttpProtocolOptions Strict LenientMethods Allow0.9
server config
virtual host
2.2.32 veya 2.4.24 ve sonrası

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

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

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

Strict|Unsafe

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

  # Unsafe için güvenlik riskleri

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

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

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

  # Komut satırı araçları ve CRLF

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

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

RegisteredMethods|LenientMethods

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

  # İleri Vekil Uyumluluğu

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

  # Example of a request leading to HTTP 501 with LenientMethods mode

  # Unknown HTTP method
  WOW / HTTP/1.0\r\n\r\n
  # Lowercase HTTP method
  get / HTTP/1.0\r\n\r\n
Allow0.9|Require1.0

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

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

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

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

Error
Özel bir hata iletisiyle yapılandırma çözümlemesini durdurur
Error ileti
server config
virtual host
directory
.htaccess
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.

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

# SSL veya NOSSL tanımlı mı bilelim <IfDefine SSL> <IfDefine NOSSL> Error "Ne SSL ne de NOSSL tanımlı. Sadece biri tanımlı olsa yeter." </IfDefine> </IfDefine> <IfDefine !SSL> <IfDefine !NOSSL> Error "Ya SSL ya da NOSSL tanımlı olmalı." </IfDefine> </IfDefine>
ErrorDocument
Bir hata durumunda sunucunun istemciye ne döndüreceğini belirler.
ErrorDocument hata-kodu belge
server config
virtual host
directory
.htaccess
FileInfo

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

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

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

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

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

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

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

ErrorDocument 404 /cgi-bin/bad_urls.pl

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

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

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

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

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

Özel Hata Yanıtları
ErrorLog
Sunucunun hata günlüğünü tutacağı yeri belirler.
ErrorLog dosya-yolu|syslog[:[oluşum][:etiket]]
ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows ve OS/2)
server config
virtual host

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

ErrorLog "/var/log/httpd/error_log"

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

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

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

Dosya adı yerine `syslog` kullanılırsa, sistem desteklediği takdirde günlük kaydı syslogd(8) üzerinden yürütülür. Öntanımlı olarak `local7` syslog oluşumu kullanılır. Bunu `syslog:oluşum` sözdizimini kullanarak değiştirebilirsiniz. Buradaki `oluşum` syslog.conf(5) kılavuz sayfasında belirtilen oluşum isimlerinden biri olabilir. Oluşum aslında küreseldir ve sanal konaklardan bazılarında değiştirilmişse, belirtilen en son oluşum tüm sunucuyu etkileyecektir. `etiket` için de aynı kurallar uygulanır. Genellikle, öntanımlı etiket olarak Apache çalıştırılabilirinin ismi olan `httpd` kullanılır. Öntanımlı etiketi `syslog::etiket` sözdizimini kullanarak değiştirebilirsiniz

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

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

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

# Ek Bilgi

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.

LogLevel
Apache HTTP Sunucusunun Günlük Dosyaları
ErrorLogFormat
Hata günlüğü girdileri için biçem belirtimi
ErrorLogFormat [connection|request] biçem
server config
virtual host

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

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

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

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

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

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

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

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 ilişklendirmek için de kullanılabilmektedir. mod_unique_id modülü yüklüyse onun eşsiz kimliği istekler için günlük kimliği olarak kullanılacaktır.

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

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

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

#Örnek (2.2.x biçimine benzer) ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"
#İstek/bağlantı günlük kimlikli gelişkin bir örnek ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M" ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T" ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'" ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'" ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"
ErrorLog
LogLevel
Apache HTTP Sunucusu Günlük Dosyaları
ExtendedStatus
Her istekte ek durum bilgisinin izini sürer
ExtendedStatus On|Off
ExtendedStatus Off[*]
server config

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.

FileETag
Duruk dosyalar için `ETag` HTTP yanıt başlığını oluşturmakta kullanılacak dosya özniteliklerini belirler.
FileETag bileşen ...
FileETag MTime Size
server config
virtual host
directory
.htaccess
FileInfo
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.) FileETagyönergesi ne kullanılması gerektiğini belirleyebilmenizi sağlar. Değer olarak belirtilebilecek anahtar sözcükler şunlardır:

INode
  Dosyanın düğüm numarası hesaba katılır.
MTime
  Dosyanın son değişiklik tarih ve saati dahil edilir.
Size
  Dosyanın bayt cinsinden uzunluğu dahil edilir.
All
  Olası tüm alanlar kullanılır. Bu şuna eşdeğerdir: FileETag INode MTime Size
None
  Bir belge dosyasıyla sunulsa bile yanıta hiçbir `ETag` alanı dahil edilmez.

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

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

# Uyarı

WebDAV’ın etkin olduğu yerlerde veya dizinlerde saklama alanı sağlayıcı olarak 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.

# Sunucu Taraflı İçerik

Gömülü SSI yönergeleri ile bir duruk dosyanın `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.
Files
Dosya isimleriyle eşleşme halinde uygulanacak yönergeleri içerir.
<Files dosya-adı> ... </Files>
server config
virtual host
directory
.htaccess
All

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

dosya-adı argümanının bir dosya ismi veya bir dosya ismi kalıbı içermesi gerekir. Bir dosya ismi kalıbındaki her `?` imi bir karakterle eşleştirilirken `*` imi karakter dizileri ile eşleştirilir.

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

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

`~` imine ek olarak

düzenli ifadeler
de kullanılabilir. Örneğin

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

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

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

Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.
FilesMatch
Düzenli ifadelerin dosya isimleriyle eşleşmesi halinde uygulanacak yönergeleri içerir.
<FilesMatch düzifd> ... </FilesMatch>
server config
virtual host
directory
.htaccess
All

FilesMatch yönergesi, içerdiği yönergelerin etki alanını Files yönergesinin yaptığı gibi dosya isimlerine göre sınırlandırır. Ancak, argüman olarak bir

düzenli ifade
kabul eder. Örneğin

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

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

Düzenli ifadenin başlangıcındaki bir `.+` `.png`veya `.gif` dosyalarının, örnek olarak, eşleşmemesini garanti eder.

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

<FilesMatch "^(?<sitename>[^/]+)"> Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example </FilesMatch>
Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.
ForceType
Bütün dosyaların belirtilen ortam türüyle sunulmasına sebep olur.
ForceType ortam-türü|None
directory
.htaccess
FileInfo
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.

# Ek Bilgi

SetHandler veya AddHandler gibi örtük yönergeler geçerli isteğe uygulanmadığı takdirde, normalde bu yönergeler tarafından belirlenen dahili eylemcinin ismi ForceType yönergesi tarafından belirtilen içerik türü ile eşleşecek şekilde belirlenir. Bu, bazı üçüncü parti modüller (mod_php gibi) tarafından kullanılan tarihi bir uygulama olup, bu modüller istekle eşleşecek modüllerin sorumluluğu almasını sağlamak için "sihirli" içerik türleri kullanabilir. Bu tür "sihirli" içerik türlerini kullanan yapılandırmalarda SetHandler veya AddHandler kullanımından kaçınılmalıdır.

GprofDir
gmon.out ayrıntılı inceleme verisinin yazılacağı dizin
GprofDir /tmp/gprof/|/tmp/gprof/%
server config
virtual host

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

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

HostnameLookups
İstemci IP adresleri üzerinde DNS sorgularını etkin kılar.
HostnameLookups On|Off|Double
HostnameLookups Off
server config
virtual host
directory

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.

If
Çalışma anında bir koşul bir istek tarafından yerine getirildiği takdirde uygulanacak yönergeleri barındırır.
<If ifade> ... </If>
server config
virtual host
directory
.htaccess
All
İç içe geçmiş koşullar 2.4.26 ve sonrasında değerlendirilmeye alınır

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

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

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

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

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

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

<If> sonrasında atanan `CONTENT_TYPE` gibi belli değişkenler ve diğer yanıt başlıkları zaten yorumlanmış olacaklarından bu yönerge için kullanılabilir olmayacaktır.

Apache HTTP Sunucusundaki İfadeler belgesinde daha ayrıntılı bilgi ve örnek bulabilirsiniz.
ElseIf
Else
Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız. If, ElseIf ve Else son olarak uygulanır.
IfDefine
Başlatma sırasında bir doğruluk sınamasından sonra işleme sokulacak yönergeleri sarmalar.
<IfDefine [!]parametre-adı> ... </IfDefine>
server config
virtual host
directory
.htaccess
All

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

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

- parametre-adı
- `!` parametre-adı

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

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

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

httpd -DReverseProxy -DUseCache -DMemCache ...
<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>
IfFile
Başlatma sırasında bir dosyanın varlığı durumunda işleme sokulacak yönergeleri sarmalar.
<IfFile [!]dosyaadı> ... </IfFile>
server config
virtual host
directory
.htaccess
All
2.4.34 ve sonrsında kullanılabilir.

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

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

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

IfModule
Belli bir modülün varlığına veya yokluğuna göre işleme sokulacak yönergeleri sarmalar.
<IfModule [!]modül-dosyası|modül-betimleyici> ... </IfModule>
server config
virtual host
directory
.htaccess
All
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:

- modül
- !modül

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

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

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

Bu bölümü sadece yapılandırma dosyanızın belli modüllerin varlığına veya yokluğuna bağlı olarak çalışması gerektiği durumlarda kullanmalısınız. Normal işlemlerde yönergelerin IfModule bölümlerine yerleştirilmeleri gerekmez.

IfDirective
Belirtilen yönerge adının varlığı veya yokluğuna bağlı olarak çalıştırılacak yönergeleri sarmalar.
<IfDirective [!]yönerge-adı> ... </IfDirective>
server config
virtual host
directory
.htaccess
All
2.4.34 ve sonrasında kullanılabilir.

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

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

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

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

Bu yönergeyi kullanma ihtiyacı sadece çok sayıda httpd tek bir yapılandırma dosyası ile çalıştırılmak zorundaysa ortaya çıkar. Böyle bir ihtiyacın olmadığı normal durumlarda yönergelerin IfDirective bölümlerine yerleştirlmesine gerek yoktur.

IfSection
IfSection
Belirtilen bölüm adının varlığı veya yokluğuna bağlı olarak çalıştırılacak yönergeleri sarmalar.
<IfSection [!]bölüm-adı> ... </IfSection>
server config
virtual host
directory
.htaccess
All
2.4.34 ve sonrasında kullanılabilir.

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

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

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

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

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

Örnek:

<IfSection VirtualHost> ... </IfSection>

Bu yönergeyi kullanma ihtiyacı sadece çok sayıda httpd tek bir yapılandırma dosyası ile (belli bir bölüm yönergesinin var olup olmamasına bakmaksızın) çalıştırılmak zorundaysa ortaya çıkar. Böyle bir ihtiyacın olmadığı normal durumlarda yönergelerin IfSection bölümlerine yerleştirlmesine gerek yoktur.

IfDirective
Include
Sunucu yapılandırma dosyalarının başka dosyaları içermesini sağlar.
Include dosya-yolu|dizin-yolu|joker
server config
virtual host
directory
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
IncludeOptional
apachectl
IncludeOptional
Diğer yapılandırma dosyalarının sunucu yapılandırma dosyasına dahil edilmesini sağlar
IncludeOptional dosya-yolu|dizin-yolu|joker
server config
virtual host
directory
2.3.6 ve sonrasına kullanılabilmektedir. Dosya kalıp karakterleri içermeyen dosya yollarından mevcut olmayanlar 2.4.30 sürümünden itibaren sözdizimi hatalarına sebep olmamaktadır.

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

Include
apachectl
KeepAlive
HTTP kalıcı bağlantılarını etkin kılar
KeepAlive On|Off
KeepAlive On
server config
virtual host

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

MaxKeepAliveRequests
KeepAliveTimeout
Bir kalıcı bağlantıda sunucunun bir sonraki isteği bekleme süresi
KeepAliveTimeout sayı[ms]
KeepAliveTimeout 5
server config
virtual host

Sunucunun kalıcı bir bağlantıyı kapatmadan önce bir sonraki isteği kaç saniye bekleyeceğini belirler. Ayrıca, ms soneki kullanılarak süreyi milisaniye olarak belirtmek de mümkündür. İstek alındıktan sonra Timeout yönergesiyle belirtilen zaman aşımı değeri uygulanır.

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

İsme dayalı sanal konak için KeepAliveTimeout atanmamışsa, yerel IP adresi ve portu ile en iyi eşleşen ilk sanal konağın değeri kullanılır.

Limit
Erişimi sınırlanacak HTTP yöntemleri için erişim sınırlayıcıları sarmalar.
<Limit yöntem [yöntem] ... > ... </Limit>
directory
.htaccess
AuthConfig, Limit

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

Erişimi sınarlarken bir 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>
LimitExcept
İsimleri belirtilenler dışında kalan HTTP yöntemleri için kullanılacak erişim sınırlayıcıları sarmalar.
<LimitExcept yöntem [yöntem] ... > ... </LimitExcept>
directory
.htaccess
AuthConfig, Limit

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

Örnek:

<LimitExcept POST GET> Require valid-user </LimitExcept>
LimitInternalRecursion
Dahili yönlendirmelerin ve istek içi isteklerin azami sayısını belirler.
LimitInternalRecursion sayı [sayı]
LimitInternalRecursion 10
server config
virtual host

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

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

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

LimitInternalRecursion 5
LimitRequestBody
İstemci tarafından gönderilen HTTP istek gövdesinin toplam uzunluğunu sınırlar.
LimitRequestBody bayt-sayısı
LimitRequestBody 0
server config
virtual host
directory
.htaccess
All

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.

LimitRequestFields
İstemciden kabul edilecek HTTP isteği başlık alanlarının sayısını sınırlar.
LimitRequestFields sayı
LimitRequestFields 100
server config
virtual host

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

# Uyarı

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

.
LimitRequestFieldSize
İstemciden kabul edilecek HTTP isteği başlık uzunluğunu sınırlar.
LimitRequestFieldSize bayt-sayısı
LimitRequestFieldSize 8190
server config
virtual host

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

Normal şartlar altında öntanımlı değer değiştirilmemelidir. Ayrıca, kaynak kodu değiştirip yeniden derlemeden bu değeri 8190'dan büyük yapamazsınız.

# Uyarı

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

LimitRequestLine
İstemciden kabul edilecek HTTP istek satırının uzunluğunu sınırlar.
LimitRequestLine bayt-sayısı
LimitRequestLine 8190
server config
virtual host

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

Normal şartlar altında öntanımlı değer değiştirilmemelidir.

# Uyarı

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

LimitXMLRequestBody
Bir XML temelli istek gövdesinin uzunluğunu sınırlar.
LimitXMLRequestBody bayt-sayısı
LimitXMLRequestBody 1000000
server config
virtual host
directory
.htaccess
All

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
Location
İçerdiği yönergeler sadece eşleşen URL’lere uygulanır.
<Location URL-yolu|URL> ... </Location>
server config
virtual host

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:

- Belirtilen yer URL'nin yol bileşeni ile tam olarak eşleşiyordur.
- Belirtilen yer bir bölü çizgisi öncesinde bitiyorsa URL'nin yol bileşeninin öneklerinden biriyle eşleşiyordur (bağlamsal bir kök dizin olarak).
- Belirtilen yer bir bölü çizgisi ile bitiyorsa URL'nin yol bileşeninin öneklerinden biriyle eşleşiyordur (bağlamsal bir kök dizin olarak).

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"> # ... </Location>

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>

# 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"> #... </Location>

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ü çizgisi) hakkında

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.

Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.
LocationMatch
İçerdiği yönergeler sadece düzenli ifadelerle eşleşen URL’lere uygulanır.
<LocationMatch düzifade> ... </LocationMatch>
server config
virtual host

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"> # ... </LocationMatch>

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

Eğer hedef, `/ek/veri` içeren değil de `/ek/veri` ile başlayan bir URL ise düzenli ifadenin önüne `^` getirmek gerekir.

<LocationMatch "^/(ek|hususi)/veri">

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

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

# / (bölü çizgisi) hakkında

Bölü çizgisi karakteri URL üzerinde göründüğü yere bağlı olarak farklı anlamlar içerir. İnsanlar, birden çok bitişik bölü çizgisinin sık sık tek bir bölü çizgisine daraltıldığı dosya sistemindeki davranışına alışkın olabilir (örn, `/home///foo` ile `/home/foo` aynıdır). URL bakımından bu her zaman doğru değildir. Eğer niyetiniz buysa, LocationMatch yönergesi ve Location yönergesinin regex ile kullanımı, bölü çizgisinin özel anlam ifade etmesi nedeniyle gerektiği kadarının belirtilmesini gerektirir.

Örneğin, `<LocationMatch "^/abc">` ile `/abc` isteği eşleşirken `//abc` isteği eşleşmez. Location yönergesinin regex olmayan kullanımı vekil isteklerindeki gibi davranır. Fakat vekil harici işlemlerde Location yönergesinin regex olmayan kullanımında çok sayıda bölü çizgisi örtük olarak tek bölü çizgisiyle eşleşir. Örneğin, `<Location "/abc/def">` belirtirseniz `/abc//def` isteği bu ifade ile eşleşecektir.

Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.
LogLevel
Hata günlüklerinin ayrıntı seviyesini belirler.
LogLevel [modül:]seviye [modül:seviye] ...
LogLevel warn
server config
virtual host
directory
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

# Ek Bilgi

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 </Directory>

Dizin bağlamında günük seviyesi yapılandırması sadece istek çözümlendikten ve istek dizinle ilişkilendirildikten sonra günlüklenen iletileri etkiler. Bağlantı veya sunucu ile ilişkilendirilmemiş günlük iletileri etkilenmez.

ErrorLog
ErrorLogFormat
Apache HTTP Server Log Files
MaxKeepAliveRequests
Bir kalıcı bağlantıda izin verilen istek sayısı
MaxKeepAliveRequests sayı
MaxKeepAliveRequests 100
server config
virtual host

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
MaxRanges
Özkaynağın tamamını döndürmeden önce izin verilen aralık sayısı
MaxRanges default | unlimited | none | aralık-sayısı
MaxRanges 200
server config
virtual host
directory
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.

default
  HTTP Range'lerinin sayısını derleme sırasında belirlenen öntanımlı 200 değeriyle sınırlar.
none
  Range başlıkları yoksayılır.
unlimited
  Sunucunun sağlamaya gönüllü olacağı HTTP Range'lerinin sayısı sınırlanmaz.
aralık-sayısı
  Sunucunun sağlamaya gönüllü olacağı HTTP Range'lerinin azami sayısını ifade eden pozitif bir tamsayı.

MaxRangeOverlaps
Özkaynağın tamamını döndürmeden önce izin verilen üst üste binen aralık sayısı (`100-200,150-300` gibi)
MaxRangeOverlaps default | unlimited | none | aralık-sayısı
MaxRangeOverlaps 20
server config
virtual host
directory
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.

default
  Üst üste binen HTTP Range'lerinin sayısını derleme sırasında belirlenen öntanımlı 20 değeriyle sınırlar.
none
  Üst üste binen Range başlıkları yoksayılır.
unlimited
  Sunucunun sağlamaya gönüllü olacağı üst üste binen HTTP Range'lerinin sayısı sınırlanmaz.
aralık sayısı
  Sunucunun sağlamaya gönüllü olacağı üst üste binen HTTP Range'lerinin azami sayısını ifade eden pozitif bir tamsayı.

MaxRangeReversals
Özkaynağın tamamını döndürmeden önce izin verilen ters sıralı aralık sayısı (`100-200,50-70` gibi)
MaxRangeReversals default | unlimited | none | aralık-sayısı
MaxRangeReversals 20
server config
virtual host
directory
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.

default
  Ters sıralı HTTP Range'lerinin sayısını derleme sırasında belirlenen öntanımlı 20 değeriyle sınırlar.
none
  Ters sıralı Range başlıkları yoksayılır.
unlimited
  Sunucunun sağlamaya gönüllü olacağı ters sıralı HTTP Range'lerinin sayısı sınırlanmaz.
aralık-sayısı
  Sunucunun sağlamaya gönüllü olacağı ters sıralı HTTP Range'lerinin azami sayısını ifade eden pozitif bir tamsayı.

Mutex
Muteks mekanizmasını ve kilit dosyası dizinini tüm muteksler veya belirtilenler için yapılandırır
Mutex mekanizma [default|muteks-ismi] ... [OmitPID]
Mutex default
server config
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; ikinci 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:

- İşlevsel veya başarımsal bir soruna sahip
  APR
  tarafından öntanımlı mekanizma seçildiği takdirde muteks mekanizmasını değiştirmek için
- Öntanımlı dizin, kilitlemeyi desteklemediği takdirde dosya tabanlı muteksler tarafından kullanılan dizini değiştirmek için

# Destekleyen modüller

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.

  # Uyarı

  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.

  # Uyarı

  Semafor geri kazanılmadan süreçler çökerse SysV semaforlarının "sızıntı" yapması mümkündür.

  # Güvenlik

  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.

  # Uyarı

  Ç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 ve Linux 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 POSIX uyumluysa veya `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.

  # Uyarı

  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.

# Güvenlik

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
NameVirtualHost
ÖNERİLMİYOR: İsme dayalı sanal konaklar için IP adresi belirtir
NameVirtualHost adres[:port]
server config

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.

Apache Sanal Konak Belgeleri
Options
Belli bir dizinde geçerli olacak özellikleri yapılandırır.
Options [+|-]seçenek [[+|-]seçenek] ...
Options FollowSymlinks
server config
virtual host
directory
.htaccess
Options
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`
  Sunucu bu dizindeki sembolik bağları izler. Bu öntanımlıdır.

  Sembolik bağlar izlense bile Directory bölümleriyle eşleşen dosya yolları değiştirilmez.

  `FollowSymLinks` ve `SymLinksIfOwnerMatch` Options sadece Directory bölümlerinde veya `.htaccess` dosyaları içinde çalışır.

  Sembolik bağ sınamaları, atlatılabilir yarış koşullarına konu olduğundan bu seçeneğin yokluğu bir güvenlik sınırlaması olarak değerlendirilmemelidir.

`Includes`
  mod_include
  tarafından sağlanan sunucu taraflı içeriklere izin verilir.
`IncludesNOEXEC`
  Sunucu taraflı içeriklere izin verilir fakat `#exec cmd` ve `#exec cgi` iptal edilir. Ancak, ScriptAlias’lı dizinlerdeki CGI betikleri için `#include virtual` hala mümkün olacaktır.
`Indexes`
  İstenen URL bir dizin ile eşleşiyorsa ve bu dizin için bir 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.

  # Bilgi

  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`
  Sunucu sembolik bağları sadece sembolik bağın hedefi ile bulunduğu dizinin sahibinin aynı kullanıcı olması halinde izleyecektir.

  `FollowSymLinks` ve `SymLinksIfOwnerMatch` Options sadece Directory bölümlerinde veya `.htaccess` dosyaları içinde çalışır.

  Sembolik bağ sınamaları, atlatılabilir yarış koşullarına konu olduğundan bu seçenek bir güvenlik sınırlaması olarak değerlendirilmemelidir.

Normalde, bir dizine çok sayıda Options uygulanabilirse de, dizine en uygun olanı uygulanıp diğerleri yok sayılır; seçenekler katıştırılmaz (bkz, Bölümler Nasıl Katıştırılır?). Bununla birlikte, önüne bir `+` veya `-` simgesi konmuş seçenekler varsa, o seçenekler katıştırılır. Önüne `+` konmuş seçenekler mevcutlara eklenirken `-` konmuş seçenekler silinir.

# Bilgi

`+` 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.

# Ek Bilgi

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

Protocol
Dinlenen bir soket için protokol
Protocol protokol
server config
virtual host
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
AcceptFilter
Listen
Protocols
Sunucu/sanal konak için kullanılabilecek protokoller
Protocols protokol ...
Protocols http/1.1
server config
virtual host
Sadece Apache 2.4.17 ve sonrasında kullanılabilir.

Bu yönerge bir sunucu/sanal konak için kullanılabilecek protokolleri belirtmekte kullanılır. Bu liste, bir istemcinin bir sanal konak veya sunucu ile uzlaşabilmesini sağlayan prokolleri belirler.

Bir sanal konak veya sunucuda kullanılabilecek protolleri çeşitlendirmek isterseniz bu protokolleri belirtmeniz gerekir. 1.0 ve 0.9 istemcilerle uyumlu olan http/1.1 protokolü öntanımlıdır.

Örneğin, bir sunucunun TLS'li HTTP/2 protokolünü desteklemesini şöyle sağlayabilirsiniz:

Protocols h2 http/1.1

Geçerli protokoller, http ve https bağlantıları için `http/1.1` htps bağlantıları için `h2` ve http bağlantıları için `h2c` protokolleridir. Modüller başka protokollerin de etkinleştirilmesini gerektirebilir.

Kullanımından vazgeçilmiş protokollerin silinmesi gerekmez. Böyle protokol isimleri basitçe yoksayılır.

Ana sunucu için belirtilen protokoller, kendi protokol yönergesi olmayan sanal konaklar için de geçerlidir. Diğer yandan sanal konaklarda protokol belirtilmesi ana sunucuda belirtien protollerin bu sanal konaklarda geçersiz olmasına sebep olur.

ProtocolsHonorOrder
ProtocolsHonorOrder
Uzlaşma sırasında protokollerin öncelik sırasını belirler
ProtocolsHonorOrder On|Off
ProtocolsHonorOrder On
server config
virtual host
Sadece Apache 2.4.17 ve sonrasında kullanılabilir.

Sunucuda Protocols yönergesinde listelemiş protokollerin mi yoksa istemcinin protokol listesinin mi öncelikli olacağı bu yönerge ile belirtilir.

Off belirtilirse, istemcinin protokol listesi sunucu yapılandırmasındaki sıralamanın önüne geçer.

ProtocolsHonorOrder yönergesine `on` belirtilirse (öntanımlıdır), istemicinin protokol sıralaması dikkate alınmaz ve protokol uzlaşımının sonucunu sunucu ayarlarındaki sıralama belirler.

Protocols
RegexDefaultOptions
Regex düzenli ifadeleri için öntanımlı/küresel seçenekleri yapılandırır
RegexDefaultOptions [none] [+|-]seçenek [[+|-]seçenek] ...
RegexDefaultOptions DOLLAR_ENDONLY
server config
Sadece Apache 2.4.30 ve sonrasında kullanılabilmektedir.

Bu yönerge kendisinden sonra kullanılan bütün düzenli ifsdelerin davranışını etkiler.

'+' ile öncelenmiş bütün seçenekler önceden atanmış seçeneklere eklenir.
'-' ile öncelenmiş bütün seçenekler önceden atanmış seçeneklerden çıkarılır.
'+' veya '-' ile öncelenmemiş her seçenek önceden atanmış seçenekleri silerek onların yerini alır.
`none` ile önceden atanmış tüm seçenekler sıfırlanır.

seçenek şunlardan biri olabilir:

`ICASE`
  Harf büyüklüğüne duyarlı eşleşmeler kullanılır.
`DOTALL`
  Perl'ün /s seçeneği.
`DOLLAR_ENDONLY`
  '$' dizgenin sonu ile eşleşir.
  .

# RegexDefaultOptions +ICASE +DOLLAR_ENDONLY ... # ICASE seçeneği silinir, diğer seçenekler tutulur: RegexDefaultOptions -ICASE ... # Atanmuş seçenekler silinir, DOTALL öntanımlı seçenek yapılır: RegexDefaultOptions DOTALL ... # Tüm seçenekler silinir, öntanımlı seçenek kalmaz. RegexDefaultOptions none ...
RLimitCPU
Apache httpd alt süreçleri tarafından çalıştırılan süreçlerin işlemci tüketimine sınırlama getirir.
RLimitCPU saniye|max [saniye|max]
Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
server config
virtual host
directory
.htaccess
All

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.

RLimitMEM
RLimitNPROC
RLimitMEM
Apache httpd alt süreçleri tarafından çalıştırılan süreçlerin bellek tüketimine sınırlama getirir.
RLimitMEM bayt-sayısı|max [bayt-sayısı|max]
Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
server config
virtual host
directory
.htaccess
All

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.

RLimitCPU
RLimitNPROC
RLimitNPROC
Apache httpd alt süreçleri tarafından çalıştırılabilecek süreç sayısına sınırlama getirir.
RLimitNPROC sayı|max [sayı|max]
Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
server config
virtual host
directory
.htaccess
All

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.

# Ek Bilgi

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.

RLimitMEM
RLimitCPU
ScriptInterpreterSource
CGI betikleri için yorumlayıcı belirleme tekniği
ScriptInterpreterSource Registry|Registry-Strict|Script
ScriptInterpreterSource Script
server config
virtual host
directory
.htaccess
FileInfo
Sadece Win32 için.

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.

# Güvenlik

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.

SeeRequestTail
İ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.
SeeRequestTail On|Off
SeeRequestTail Off
server config
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

ServerAdmin
Sunucunun hata iletilerinde istemciye göstereceği eposta adresi
ServerAdmin eposta-adresi|URL
server config
virtual host

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@foo.example.com
ServerAlias
İstekleri isme dayalı sanal konaklarla eşleştirilirken kullanılacak konak adları için başka isimler belirtebilmeyi sağlar.
ServerAlias konakadı [konakadı] ...
virtual host

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.

VirtualHost bölümü içindeki isimlerin sırası (jokersiz) ServerAlias yönergesindeki gibi ele alınır.

UseCanonicalName
Apache HTTP Sunucusu Sanal Konak Belgeleri
ServerName
Sunucunun özdeşleşeceği konak ismi ve port.
ServerName [şema://]alan-adı|ip-adresi[:port]
server config
virtual host

ServerName yönergesi, sunucunun kendini betimlemekte kullanacağı şema, konak adı ve port değerlerini belirler.

isme dayalı sanal konaklar kullanılırken bir sanal konağı eşsiz bir şekilde betimlemek için ServerName kullanılır (muhtemelen ServerAlias ile birlikte).

Ek olarak, UseCanonicalName yönergesine öntanımlı olmayan bir değer atanarak özüne yönlendiren URL'ler oluştururken de bu yönerge kullanılır.

Ö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 istemciye görünen sunucu ismini anlamak için önce işletim sistemine sistemin konak adını sorar. Bu başarılı olmazsa sistem üzerinde IP adresine bir ters DNS sorgusu yapar.

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

DNS ile ilgili konular ve Apache HTTP Sunucusu
Apache HTTP Sunucusu Sanal Konak Belgeleri
UseCanonicalName
UseCanonicalPhysicalPort
ServerAlias
ServerPath
Uyumsuz bir tarayıcı tarafından erişilmesi için bir isme dayalı sanal konak için meşru URL yolu
ServerPath URL-yolu
virtual host

ServerPath yönergesi isme dayalı sanal konaklarda kullanmak için konağa meşru bir URL yolu belirler.

Apache HTTP Sunucusu Sanal Konak Belgeleri
ServerRoot
Sunucu yapılandırması için kök dizin
ServerRoot dizin-yolu
ServerRoot /usr/local/apache
server config

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ği
ServerRoot
dizininin erişim izinlerinin nasıl ayarlanması gerektiğini öğrenmek için güvenlik ipuçları
ServerSignature
Sunucu tarafından üretilen belgelerin dipnotunu ayarlar.
ServerSignature On|Off|EMail
ServerSignature Off
server config
virtual host
directory
.htaccess
All

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.

ServerTokens
ServerTokens
Server
HTTP yanıt başlığını yapılandırır.
ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full
ServerTokens Full
server config

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)
  Sunucu şunu gönderir (örnek): `Server: Apache/2.4.2 (Unix) PHP/4.2.2 MyMod/1.2`
`ServerTokens Prod[uctOnly]`
  Sunucu şunu gönderir (örnek): `Server: Apache`
`ServerTokens Major`
  Sunucu şunu gönderir (örnek): `Server: Apache/2`
`ServerTokens Minor`
  Sunucu şunu gönderir (örnek): `Server: Apache/2.4`
`ServerTokens Min[imal]`
  Sunucu şunu gönderir (örnek): `Server: Apache/2.4.2`
`ServerTokens OS`
  Sunucu şunu gönderir (örnek): `Server: Apache/2.4.2 (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.

ServerSignature
SetHandler
Eşleşen tüm dosyaların belli bir eylemci tarafından işlenmesine sebep olur.
SetHandler eylemci-ismi|none|ifade
server config
virtual host
directory
.htaccess
FileInfo
ifade seçeneği 2.4.19 sürümünde eklendi

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>

Bu yönergeyi ayrıca, belli bir dosya uzantısına sahip dosyalara uygun bir eylemci atamak için de kullanabilirsiniz. örnek:

<FilesMatch "\.php$"> SetHandler application/x-httpd-php </FilesMatch>

Dizge değerli ifadeler istek öncesi değişkenleri içerecek şekilde düzenlenebilir. Buna ismli düzenli ifadelere yapılan geriye başvurular dahildir:

<LocationMatch ^/app/(?<sub>[^/]+)/> SetHandler "proxy:unix:/var/run/app_%{env:MATCH_sub}.sock|fcgi://localhost:8080" </LocationMatch>

Evvelce tanımlanmış bir SetHandler yönergesini `None` değeriyle geçersiz hale getirebilirsiniz.

# Bilgi

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.

AddHandler
SetInputFilter
POST girdilerini ve istemci isteklerini işleyecek süzgeçleri belirler.
SetInputFilter süzgeç[;süzgeç...]
server config
virtual host
directory
.htaccess
FileInfo

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.

Süzgeçler belgesi
SetOutputFilter
Sunucunun yanıtlarını işleyecek süzgeçleri belirler.
SetOutputFilter süzgeç[;süzgeç...]
server config
virtual host
directory
.htaccess
FileInfo

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.

Süzgeçler belgesi
TimeOut
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.
TimeOut saniye
TimeOut 60
server config
virtual host

TimeOut yönergesi Apache httpd’nin aşağıdaki durumlarda G/Ç için bekleyeceği süreyi belirler:

- Veriyi istemciden okurken, okuma tamponu boş olduğu takdirde bir TCP paketinin gelmesini bekleyeceği süre.

  Yeni bir bağlantıda ilk veri için, sunucuya yeni bağlantıyı aktaran bir AcceptFilter yönergesi ile ilgili yapılandırma ele alınıncaya kadar bu yönerge etkilenmez.

- Veriyi istemciye yazarken, gönderme tamponu dolu olduğu takdirde bir paket alındısı için beklenecek süre.
- mod_cgi
  ve mod_cgid modülünde, bir CGI betiğinden belli bir çıktı kümesi 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.

TraceEnable
TRACE
isteklerinde davranış şeklini belirler
TraceEnable [on|off|extended]
TraceEnable on
server config
virtual host

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 64kB ile sınırlar (`Transfer-Encoding: chunked` kullanılmışsa bölüm başlıkları için 8kB 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 64kB’lık sınır yoktur.

# Bilgi

Aksine iddialara rağmen, `TRACE` yöntemini etkinleştirmek Apache httpd'de bir güvenlik açığı değildir. `TRACE` yöntemi HTTP/1.1 belirtiminde tanımlanmış olup desteklenmesi umulmuştur.

UnDefine
Bir değişkeni tanımsız yapar
UnDefine değişken-ismi
server config

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.

Bu yönerge sanal konak bağlamında desteklenirken, kapsanan sanal konaklar haricinde, değişiklikleri kendisinden sonraki tüm yapılandırma yönergelerinde görünür kılar.

Define
IfDefine
UseCanonicalName
Sunucunun kendi adını ve portunu nasıl belirleyeceğini ayarlar
UseCanonicalName On|Off|DNS
UseCanonicalName Off
server config
virtual host
directory

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.

# Uyarı

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.

UseCanonicalPhysicalPort
ServerName
Listen
UseCanonicalPhysicalPort
Sunucunun kendi adını ve portunu nasıl belirleyeceğini ayarlar
UseCanonicalPhysicalPort On|Off
UseCanonicalPhysicalPort Off
server config
virtual host
directory

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.

# Ek Bilgi

Fiziksel port kullanımı etkin olduğunda işlemler şu sırayla yürütülür:

`UseCanonicalName On`
  1. Servername
     ile sağlanan port
  2. Fiziksel port
  3. Öntanımlı port
`UseCanonicalName Off | DNS`
  1. `Host:` başlığından çözümlenen port
  2. Fiziksel port
  3. Servername
     yönergesinde belirtilen port
  4. Öntanımlı port

`UseCanonicalPhysicalPort Off` olduğunda işlem sırasında fiziksel port adımları atlanır.

UseCanonicalName
ServerName
Listen
VirtualHost
Sadece belli bir konak ismine ve porta uygulanacak yönergeleri barındırır.
<VirtualHost adres[:port] [adres[:port]] ...> ... </VirtualHost>
server config

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:

- Sanal konağın IP adresi.
- Sanal konağın IP adresi için tam nitelenmiş alan adı (önerilmez).
- Tüm IP adresleri ile eşleşmek üzere `*` 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]: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>

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

# Ek Bilgi

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üvenlik

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.

Apache HTTP Sunucusu Sanal Konak Belgeleri
DNS ile İlgili Konular ve Apache HTTP Sunucusu
Apache HTTP Sunucusunun belli adresleri ve portları dinlemek üzere yapılandırılması
Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının açıklaması için <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.
MergeTrailers
Trailer alanlarının başlığa dahil edilip edilmeyeceğini belirler
MergeTrailers [on|off]
MergeTrailers off
server config
virtual host
2.4.11 ve sonrası

Bu yönerge HTTP Trailer alanlarının dahili HTTP başlıklarına kopyalanıp kopyalanmayacağını belirler. Kopyalama işlemi istek gövdesi tamamen alındığında gerçekleşir, çoğu başlık işleminin çok sonra istek başlıklarını inceleme veya değiştirme şansı olur.

Bu seçenek, Trailer alanlarını daima kopyalayan 2.4.11 öncesi dağıtımlarla uyumluluk için vardır.

QualifyRedirectURL
REDIRECT_URL ortam değişkeninin tamamen nitelenmiş olup olmayacağını denetler
QualifyRedirectURL ON|OFF
QualifyRedirectURL OFF
server config
virtual host
directory
FileInfo
Yönerge 2.4.18 ve sonrasında desteklenmektedir. 2.4.17 sürümünde 'QualifyRedirectURL ON' yapılandırması mevcutmuş gibi davranılır.

Bu yönerge sunucuya REDIRECT_URL ortam değişkenin tamamen nitelenmiş olacağını temin eder. Değişken öntanımlı olarak istemci tarafından talep edilen URL'yi harfi harfine içerir, "/index.html" gibi. QualifyRedirectURL ON belirtilseydi aynı istek "http://www.example.com/index.html" gibi bir değerle sonuçlanırdı.

Böyle belirtilmemiş olsa bile, istek tam nitelenmiş bir URL içerseydi REDIRECT_URL de tam nitelenmiş URL'yi içerirdi.

RegisterHttpMethod
Standart olmayan HTTP yöntemlerini devreye alır
RegisterHttpMethod yöntem [yöntem [...]]
server config
Apache HTTP Sunucusunun 2.4.24 ve sonraki sürümlerinde kullanılabilmektedir.

Bu yönerge sunucunun standatta bulunmayan ek HTTP yöntemlerini kullanabilmesini sağlar. Yönergelerde standartta olmayan yöntem isimleri kullanmak gerektiğinde veya sunucunun modüllere sadece standart yöntemleri aktaracak şekilde yapılandırıldığı durumlarda bazı standart-dışı yöntemleri vekil veya CGI betikleriyle aktarmayı mümkün kılmak için bu gereklidir.

HTTPProtocolOptions
AllowMethods