From: Nilgun Belma Buguner
Date: Wed, 4 Feb 2009 01:09:28 +0000 (+0000)
Subject: update transformation
X-Git-Tag: 2.3.2~82
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a2b7cdd8bbf69dbfe1299eb4a4688356fb63e23b;p=thirdparty%2Fapache%2Fhttpd.git
update transformation
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@740553 13f79535-47bb-0310-9956-ffa450edef68
---
diff --git a/docs/man/rotatelogs.8 b/docs/man/rotatelogs.8
index 308ca799223..84f19af9338 100644
--- a/docs/man/rotatelogs.8
+++ b/docs/man/rotatelogs.8
@@ -19,7 +19,7 @@
.el .ne 3
.IP "\\$1" \\$2
..
-.TH "ROTATELOGS" 8 "2008-03-07" "Apache HTTP Server" "rotatelogs"
+.TH "ROTATELOGS" 8 "2009-02-02" "Apache HTTP Server" "rotatelogs"
.SH NAME
rotatelogs \- Piped logging program to rotate Apache logs
@@ -47,7 +47,7 @@ Causes the use of local time rather than GMT as the base for the interval or for
Causes the logfile to be opened immediately, as soon as rotatelogs starts, instead of waiting for the first logfile entry to be read (for non-busy sites, there may be a substantial delay between when the server is started and when the first request is handled, meaning that the associated logfile does not "exist" until then, which causes problems from some automated logging tools)
.TP
-v
-Produce verbose output on STDERR\&. The output contains the result of the configuration parsing, and all file open and close actions.
+Produce verbose output on STDERR\&. The output contains the result of the configuration parsing, and all file open and close actions\&.
.TP
\fIlogfile\fR
The path plus basename of the logfile\&. If \fIlogfile\fR includes any '%' characters, it is treated as a format string for strftime(3)\&. Otherwise, the suffix \fI\&.nnnnnnnnnn\fR is automatically added and is the time in seconds\&. Both formats compute the start time from the beginning of the current period\&. For example, if a rotation time of 86400 is specified, the hour, minute, and second fields created from the strftime(3) format will all be zero, referring to the beginning of the current 24-hour period (midnight)\&.
@@ -56,9 +56,7 @@ The path plus basename of the logfile\&. If \fIlogfile\fR includes any '%' chara
The time between log file rotations in seconds\&. The rotation occurs at the beginning of this interval\&. For example, if the rotation time is 3600, the log file will be rotated at the beginning of every hour; if the rotation time is 86400, the log file will be rotated every night at midnight\&. (If no data is logged during an interval, no file will be created\&.)
.TP
\fIfilesize\fR(B|K|M|G)
-The maximum file size followed by exactly one of the letters B (Bytes), K (KBytes), M (MBytes) or G (GBytes)\&.
-.br
-When time and size are specified, the size must be given after the time\&. Rotation will occur whenever either time or size limits are reached\&.
+The maximum file size in followed by exactly one of the letters B (Bytes), K (KBytes), M (MBytes) or G (GBytes)\&. .PP When time and size are specified, the size must be given after the time\&. Rotation will occur whenever either time or size limits are reached\&.
.TP
\fIoffset\fR
The number of minutes offset from UTC\&. If omitted, zero is assumed and UTC is used\&. For example, to use local time in the zone UTC -5 hours, specify a value of -300 for this argument\&. In most cases, -l should be used instead of specifying an offset\&.
diff --git a/docs/manual/howto/cgi.html.ja.utf8 b/docs/manual/howto/cgi.html.ja.utf8
index ea63926a127..237853a88fe 100644
--- a/docs/manual/howto/cgi.html.ja.utf8
+++ b/docs/manual/howto/cgi.html.ja.utf8
@@ -20,6 +20,7 @@
2.3 > How-To / ãã¥ã¼ããªã¢ã«
Apache 2.x, esneklik, taÅınabilirlik ve baÅarım arasında bir denge
+ saÄlamak üzere tasarlanmıŠgenel amaçlı bir HTTP sunucusudur. BaÅka
+ sunucularla kıyaslama denemelerinde öne geçmek üzere tasarlanmamıÅ
+ olsa da Apache 2.x gerçek yaÅamda karÅılaÅılan pek çok durumda oldukça
+ yüksek bir baÅarıma ulaÅacak yetenektedir.
+
+
Apache 1.3 ile karÅılaÅtırıldıÄında 2.x sürümleri toplam veri hızını
+ ve ölçeklenebilirliÄi arttırmak için pek çok en iyileme seçeneÄi
+ içerir. Bu iyileÅtirmelerin pek çoÄu zaten öntanımlı olarak etkin
+ olmakla birlikte derleme ve kullanım sırasında baÅarımı önemli ölçüde
+ etkileyebilen yapılandırma seçenekleri de mevcuttur. Bu belgede, bir
+ Apache 2.x kurulumunda sunucu yöneticisinin sunucunun baÅarımını
+ arttırmak amacıyla yapılandırma sırasında neler yapabileceÄinden
+ bahsedilmiÅtir. Bu yapılandırma seçeneklerinden bazıları, httpdânin
+ donanımın ve iÅletim sisteminin olanaklarından daha iyi
+ yararlanabilmesini saÄlarken bir kısmı da daha hızlı bir sunum için
+ yöneticinin iÅlevsellikten ödün verebilmesini olanaklı kılar.
HTTP sunucusunun baÅarımını etkileyen en önemli donanım bellektir
+ (RAM). Bir HTTP sunucusu asla takaslama yapmamalıdır. Ãünkü takaslama,
+ kullanıcının "yeterince hız" umduÄu noktada sunumun gecikmesine sebep
+ olur. Böyle bir durumda kullanıcılar yüklemeyi durdurup tekrar
+ baÅlatma eÄilimindedirler; sonuçta yük daha da artar. MaxClients yönergesinin deÄerini
+ deÄiÅtirerek takaslamaya sebep olabilecek kadar çok çocuk süreç
+ oluÅturulmasını engelleyebilirsiniz ve böyle bir durumda bunu mutlaka
+ yapmalısınız. Bunun için yapacaÄınız iÅlem basittir: top
+ benzeri bir araç üzerinden çalıÅan süreçlerinizin bir listesini alıp
+ Apache süreçlerinizin ortalama büyüklüÄünü saptayıp, mevcut bellekten
+ bir kısmını diÄer süreçler için ayırdıktan sonra kalan miktarı bu
+ deÄere bölerseniz yönergeye atayacaÄınız deÄeri bulmuÅ olursunuz.
+
+
Donanımın diÄer unsurları için kararı siz verin: Daha hızlı iÅlemci,
+ daha hızlı aÄ kartı, daha hızlı disk; daha hızlının ne kadar hızlı
+ olacaÄını deneyimlerinize baÄlı olarak tamamen sizin ihtiyaçlarınız
+ belirler.
+
+
İÅletim sistemi seçimi büyük oranda yerel ilgi konusudur. Fakat yine
+ de, genelde yararlılıÄı kanıtlanmıŠbazı kurallar bu seçimde size
+ yardımcı olabilir:
+
+
+
+
SeçtiÄiniz iÅletim sisteminin (çekirdeÄin) en son kararlı
+ sürümünü çalıÅtırın. Bir çok iÅletim sistemi, son yıllarda TCP
+ yıÄıtları ve evre kütüphaneleri ile ilgili belirgin iyileÅtirmeler
+ yapmıÅlar ve yapmaktadırlar.
+
+
+
+
İÅletim sisteminiz sendfile(2) sistem çaÄrısını
+ destekliyorsa bunun etkinleÅtirilebildiÄi sürümün kurulu olması
+ önemlidir. (ÃrneÄin, Linux için bu, Linux 2.4 ve sonraki sürümler
+ anlamına gelirken, Solaris için Solaris 8âden önceki sürümlerin
+ yamanması gerektirdiÄi anlamına gelmektedir.)
+ sendfile iÅlevinin desteklendiÄi sistemlerde Apache 2
+ duruk içeriÄi daha hızlı teslim etmek ve iÅlemci kullanımını
+ düÅürmek amacıyla bu iÅlevselliÄi kullanacaktır.
Apache 1.3 öncesinde, HostnameLookups yönergesinin öntanımlı deÄeri
+ On idi. İstek yerine getirilmeden önce bir DNS sorgusu
+ yapılmasını gerektirmesi sebebiyle bu ayarlama her istekte bir
+ miktar gecikmeye sebep olurdu. Apache 1.3âten itibaren yönergenin
+ öntanımlı deÄeri Off yapılmıÅtır. EÄer günlük
+ dosyalarınızda konak isimlerinin bulunmasını isterseniz, Apache ile
+ birlikte gelen logresolve programını
+ kullanabileceÄiniz gibi günlük raporlarını çözümleyen Apache ile
+ gelmeyen programlardan herhangi birini de kullanabilirsiniz.
Allow veya
+ Deny
+ yönergelerinde IP adresi yerine bir konak veya alan ismi
+ belirtirseniz, iki DNS sorguluk bir bedel ödersiniz (biri normal,
+ diÄeri IP taklidine karÅı ters DNS sorgusu). BaÅarımı en iyilemek
+ için bu yönergelerde mümkün olduÄunca isim yerine IP adreslerini
+ kullanınız.
+
+
HostnameLookups
+ yönergelerinin <Location /server-status> gibi
+ bölüm yönergelerinin içinde de yer alabileceÄini unutmayın. Bu gibi
+ durumlarda DNS sorguları sadece istek kuralla eÅleÅtiÄi takdirde
+ yapılacaktır. AÅaÄıdaki örnekte .html ve
+ .cgi dosyalarına yapılan istekler hariç DNS sorguları
+ iptal edilmektedir:
+
+
+ HostnameLookups off
+ <Files ~ "\.(html|cgi)$">
+
+ HostnameLookups on
+
+ </Files>
+
+
+
Yine de bazı CGIâlerin DNS isimlerine ihtiyacı olursa bu CGIâlerin
+ bu ihtiyaçlarına yönelik olarak gethostbyname çaÄrıları
+ yapabileceÄini gözardı etmeyiniz.
URL uzayınızda geçerli olmak üzere bir Options
+ FollowSymLinks yoksa veya Options
+ SymLinksIfOwnerMatch yönergeleri varsa, Apache her sembolik
+ baÄın üzerinde bazı sınamalar yapmak için ek bir sistem çaÄrısından
+ baÅka istenen her dosya için de ayrı bir çaÄrı yapacaktır.
Böylece DocumentRoot altındaki
+ dosyalar için fazladan bir çaÄrı yapılmasını engellemiÅ olursunuz.
+ EÄer bazı bölümlerde Alias, RewriteRule gibi yönergeler üzerinden belge kök
+ dizininizin dıÅında kalan dosya yollarına sahipseniz benzer
+ iÅlemleri onlar için de yapmalısınız. Sembolik baÄ koruması yapmamak
+ suretiyle baÅarımı arttırmak isterseniz, FollowSymLinks
+ seçeneÄini her yerde etkin kılın ve
+ SymLinksIfOwnerMatch seçeneÄini asla
+ etkinleÅtirmeyin.
Genellikle .htaccess dosyaları üzerinden yapıldıÄı
+ gibi URL uzayınızda geçersizleÅtirmelere izin veriyorsanız, Apache
+ her dosya bileÅeni için bu .htaccess dosyalarını açmaya
+ çalıÅacaktır.
BaÅarımı son kırıntısına kadar arttırmak istiyorsanız, mümkünse
+ içerik dili uzlaÅımı da yapmayın. Dil uzlaÅımından yararlanmak
+ isterken büyük baÅarım kayıplarına uÄrayabilirsiniz. Böyle bir
+ durumda sunucunun baÅarımını arttırmanın tek bir yolu vardır.
+
+
+ DirectoryIndex index
+
+
+
Yukarıdaki gibi bir dosya ismi kalıbı kullanmak yerine, aÅaÄıdaki
+ gibi seçenekleri tam bir liste halinde belirtin:
İstenen dosya için MultiViews kullanarak dizini
+ taratmak yerine, gerekli bilgiyi tek bir dosyadan okutmak suretiyle
+ baÅarımı arttırabilirsiniz. Bu amaçla türeÅlem
+ (type-map) dosyaları kullanmanız yeterli olacaktır.
+
+
Sitenizde içerik dili uzlaÅımına gerek varsa, bunu Options
+ MultiViews yönergesi üzerinden deÄil, türeÅlem dosyaları
+ kullanarak yapmayı deneyin. İçerik dili uzlaÅımı ve türeÅlem
+ dosyalarının oluÅturulması hakkında daha ayrıntılı bilgi edinmek
+ için İçerik UzlaÅımı
+ belgesine bakınız.
+
+
+
+
Bellek EÅlemleri
+
+
+
+
Apacheânin SSI sayfalarında olduÄu gibi teslim edilecek dosyanın
+ içeriÄine bakma gereÄi duyduÄu durumlarda, eÄer iÅletim sistemi
+ mmap(2) ve benzerlerini destekliyorsa çekirdek normal
+ olarak dosyayı belleÄe kopyalayacaktır.
+
+
Bazı platformlarda bu belleÄe eÅleme iÅlemi baÅarımı arttırsa da
+ baÅarımın veya httpd kararlılıÄının zora girdiÄi durumlar
+ olabilmektedir:
+
+
+
+
Bazı iÅletim sistemlerinde iÅlemci sayısı artıÅına baÄlı
+ olarak, mmap iÅlevi read(2) kadar iyi
+ ölçeklenmemiÅtir. ÃrneÄin, çok iÅlemcili Solaris sunucularda
+ mmap iptal edildiÄi takdirde içeriÄi sunucu
+ tarafından iÅlenen dosyalar üzerinde bazen daha hızlı iÅlem
+ yapılabilmektedir.
+
+
+
+
BelleÄe kopyalanacak dosya NFS üzerinden baÄlanan bir dosya
+ sistemindeyse ve dosya baÅka bir NFS istemcisi makine tarafından
+ silinmiÅ veya dosyanın boyutu deÄiÅtirilmiÅse sunucunuz dosyaya
+ tekrar eriÅmeye çalıÅtıÄında bir hata alabilecektir.
Apacheânin duruk dosyalarda olduÄu gibi teslim edilecek dosyanın
+ içeriÄine bakmadıÄı durumlarda, eÄer iÅletim sistemi
+ sendfile(2) desteÄine sahipse çekirdek normal olarak bu
+ desteÄi kullanacaktır.
+
+
Bazı platformlarda sendfile kullanımı, okuma ve yazma
+ iÅlemlerinin ayrı ayrı yapılmamasını saÄlasa da
+ sendfile kullanımının httpd kararlılıÄını bozduÄu bazı
+ durumlar sözkonusudur:
+
+
+
+
Bazı platformlar derleme sisteminin saptayamadıÄı bozuk bir
+ sendfile desteÄine sahip olabilir. Ãzellikle
+ derleme iÅleminin baÅka bir platformda yapılıp
+ sendfile desteÄi bozuk bir makineye kurulum
+ yapıldıÄı durumlarda bu desteÄin bozuk olduÄu
+ saptanamayacaktır.
+
+
+
Ãekirdek, NFS üzerinden eriÅilen aÄ dosyalarını kendi önbelleÄi
+ üzerinden gerektiÄi gibi sunamayabilir.
+
+
+
+
Böyle durumların olasılık dahilinde olduÄu kurulumlarda içeriÄin
+ sendfile desteÄiyle teslim edilmemesi için
+ yapılandırmanıza EnableSendfile off satırını ekleyiniz.
+ (Dikkat: Bu yönerge dizin seviyesinde geçersizleÅtirilebilen
+ yönergelerdendir.)
Apache 1.3 öncesinde MinSpareServers, MaxSpareServers ve StartServers ayarları, baÅka sunucularla kıyaslama
+ denemelerinde olaÄanüstü kötü sonuçlar alınmasına sebep olmaktaydı.
+ Ãzellikle uygulanan yükü karÅılamaya yetecek sayıda çocuk süreç
+ oluÅturulması aÅamasında Apacheânin elde ettiÄi ivme bunlardan
+ biriydi. BaÅlangıçta StartServers yönergesiyle belli sayıda süreç
+ oluÅturulduktan sonra her saniyede bir tane olmak üzere MinSpareServers sayıda çocuk süreç
+ oluÅturulmaktaydı. ÃrneÄin, aynı anda 100 isteÄe yanıt vermek için
+ StartServers
+ yönergesinin öntanımlı deÄeri olarak baÅta 5 süreç
+ oluÅturulduÄundan kalan süreçler için 95 saniye geçmesi gerekirdi.
+ Sık sık yeniden baÅlatılmadıklarından dolayı gerçek hayatta
+ sunucuların baÅına gelen de buydu. BaÅka sunucularla kıyaslama
+ denemelerinde ise iÅlem sadece on dakika sürmekte ve içler acısı
+ sonuçlar alınmaktaydı.
+
+
Saniyede bir kuralı, sunucunun yeni çocukları oluÅturması sırasında
+ sistemin aÅırı meÅgul duruma düÅmemesi için alınmıŠbir önlemdi.
+ Makine çocuk süreç oluÅturmakla meÅgul edildiÄi sürece isteklere
+ yanıt veremeyecektir. Böylesi bir durum Apacheânin baÅarımını
+ kötüleÅtirmekten baÅka iÅe yaramayacaktır. Apache 1.3âte saniyede
+ bir kuralı biraz esnetildi. Yeni gerçeklenimde artık bir süreç
+ oluÅturduktan bir saniye sonra iki süreç, bir saniye sonra dört
+ süreç oluÅturulmakta ve iÅlem, saniyede 32 çocuk süreç oluÅturulur
+ duruma gelene kadar böyle ivmelenmektedir. Ãocuk süreç oluÅturma
+ iÅlemi MinSpareServers
+ deÄerine ulaÅılınca durmaktadır.
+
+
Bu, MinSpareServers,
+ MaxSpareServers ve
+ StartServers ayarlarıyla
+ oynamayı neredeyse gereksiz kılacak kadar iyi sonuçlar verecek gibi
+ görünmektedir. Saniyede 4 çocuktan fazlası oluÅturulmaya
+ baÅlandıÄında hata günlüÄüne bazı iletiler düÅmeye baÅlar. Bu
+ iletilerin sayısı çok artarsa bu ayarlarla oynama vakti gelmiÅ
+ demektir. Bunun için mod_status çıktısını bir
+ kılavuz olarak kullanabilirsiniz.
+
+
Süreç oluÅturmayla ilgili olarak süreç ölümü MaxRequestsPerChild deÄeri ile
+ saÄlanır. Bu deÄer öntanımlı olarak 0 olup, çocuk süreç
+ baÅına istek sayısının sınırsız olduÄu anlamına gelir. EÄer
+ yapılandırmanızda bu deÄeri 30 gibi çok düÅük bir
+ deÄere ayarlarsanız bunu hemen kaldırmak zorunda kalabilirsiniz.
+ Sunucunuzu SunOS veya Solarisâin eski bir sürümü üzerinde
+ çalıÅtırıyorsanız bellek kaçaklarına sebep olmamak için bu deÄeri
+ 10000 ile sınırlayınız.
+
+
Kalıcı baÄlantı özelliÄini kullanıyorsanız, çocuk süreçler zaten
+ açık baÄlantılardan istek beklemekte olacaklardır. KeepAliveTimeout yönergesinin öntanımlı
+ deÄeri 5 saniye olup bu etkiyi en aza indirmeye yönelik
+ süredir. Burada aÄ band geniÅliÄi ile sunucu kaynaklarının kullanımı
+ arasında bir seçim yapmak söz konusudur. Hiçbir Åey umurunuzda
+ deÄilse
+ çoÄu ayrıcalıÄın yitirilmesi pahasına bu deÄeri rahatça
+ 60 saniyenin üzerine çıkarabilirsiniz.
Apache 2.x, Ãok Süreçlilik Modülleri
+ (MPM) adı verilen eklemlenebilir çok görevlilik modellerini
+ destekler. Apacheâyi derlerken bu MPMâlerden birini seçmeniz
+ gerekir. MPMâlerden bazıları platformlara özeldir:
+ beos, mpm_netware,
+ mpmt_os2 ve mpm_winnt. Unix
+ benzeri sistemler için ise seçebileceÄiniz modül sayısı birden
+ fazladır. MPM seçiminin httpdânin hızında ve ölçeklenebilirliÄinde
+ bazı etkileri olabilir:
+
+
+
+
worker modülü her biri çok evreli çok sayıda
+ çocuk süreç kullanımını destekler. Her evre aynı anda tek bir
+ baÄlantıya hizmet sunar. Aynı hizmeti daha az bellek harcayarak
+ vermesi nedeniyle yüksek trafiÄe sahip sunucularda
+ prefork modülüne göre daha iyi bir seçimdir.
+
+
prefork modülü her biri tek bir evreye sahip
+ çok sayıda çocuk süreç kullanımını destekler. Her süreç aynı anda
+ tek bir baÄlantıya hizmet sunar. ÃoÄu sistemde daha hızlı olması
+ nedeniyle worker modülüne göre daha iyi bir seçim
+ olarak görünürse de bunu daha fazla bellek kullanarak saÄlar.
+ prefork modülünün evresiz tasarımının
+ worker modülüne göre bazı yararlı tarafları
+ vardır: Ãok evreli sistemlerde güvenilir olmayan üçüncü parti
+ modülleri kullanabilir ve evrelerde hata ayıklamanın yetersiz
+ kaldıÄı platformlarda hatalarını ayıklamak daha kolaydır.
+
+
+
+
Bu modüller ve diÄerleri hakkında daha ayrıntılı bilgi edinmek için
+ Ãok Süreçlilik Modülleri belgesine
+ bakınız.
Bellek kullanımı baÅarım konusunda önemli olduÄundan gerçekte
+ kullanmadıÄınız modülleri elemeye çalıÅmalısınız. Modülleri birer DSO olarak derlediyseniz LoadModule yönergesinin bulunduÄu satırı
+ açıklama haline getirmeniz modülden kurtulmanız için yeterli
+ olacaktır. Modülleri bu Åekilde kaldırarak onların yokluÄunda
+ sitenizin hala iÅlevlerini yerine getirdiÄini görme Åansına da
+ kavuÅmuÅ olursunuz.
+
+
Ancak, eÄer modülleri Apache çalıÅtırılabilirinin içine
+ gömmüÅseniz istenmeyen modülleri kaldırmak için Apache'yi yeniden
+ derlemeniz gerekir.
+
+
Bu noktada bir soru akla gelebilir: Hangi modüller gerekli,
+ hangileri deÄil? Bu sorunun yanıtı Åüphesiz siteden siteye deÄiÅir.
+ Ancak, olmazsa olmaz moüller olarak mod_mime,
+ mod_dir ve mod_log_config
+ modüllerini sayabiliriz. Bunlardan mod_log_config
+ olmadan da bir sitenin çalıÅabileceÄinden hareketle bu modülün
+ varlıÄı isteÄe baÄlı olsa da bu modülü kaldırmanızı önermiyoruz.
+
+
+
+
Atomik İÅlemler
+
+
+
+
Worker MPM'nin en son geliÅtirme sürümleri ve
+ mod_cache gibi bazı modüller APR'nin atomik API'sini
+ kullanırlar. Bu API, düÅük ayarlı evre eÅzamanlamasında atomik
+ iÅlemler yapar.
+
+
Ãntanımlı olarak, APR bu iÅlemleri hedef iÅletim sistemi/iÅlemci
+ platformunda kullanılabilecek en verimli mekanizmayı kullanarak
+ gerçekleÅtirir. Günümüz iÅlemcilerinin çoÄu, örneÄin, bir atomik
+ karÅılaÅtırma ve takas (CAS) iÅlemini donanımda gerçekleÅtirmektedir.
+ Bazı platformlarda APR'nin atomik iÅlemler için öntanımlı olarak daha
+ yavaŠolan mutekslere dayalı gerçeklenimi kullanmasının sebebi eski
+ iÅlemcilerde bu tür makine kodlarının yokluÄudur. Apache'yi bu tür
+ platformalarda günümüz iÅlemcileriyde çalıÅtırmayı düÅünüyorsanız
+ Apache'yi derlemek için yapılandırırken en hızlı atomik iÅlemin
+ seçilebilmesi için --enable-nonportable-atomics
+ seçeneÄini kullanın:
SPARC üzerinde Solaris
+ APR öntanımlı olarak, SPARC/Solaris üzerinde mutekslere dayalı
+ atomik iÅlemleri kullanır. Ancak,
+ --enable-nonportable-atomics yapılandırmasını
+ kullanırsanız, donanım üzerinde hızlı karÅılaÅtırma ve takas
+ için uygun SPARC v8plus kodunu kullanacak Åekilde kod üretilir.
+ Apache'yi bu seçenekle yapılandırırsanız atomik iÅlemler daha
+ verimli olacak fakat derlenen Apache çalıÅtırılabiliri sadece
+ UltraSPARC kırmıÄı üzerinde çalıÅacaktır.
+
+
+
x86 üzerinde Linux
+ APR öntanımlı olarak, Linux üzerinde mutekslere dayalı atomik
+ iÅlemleri kullanır. Ancak,
+ --enable-nonportable-atomics yapılandırmasını
+ kullanırsanız, donanım üzerinde hızlı karÅılaÅtırma ve takas
+ için uygun 486 kodunu kullanacak Åekilde kod üretilir. Apache'yi
+ bu seçenekle yapılandırırsanız atomik iÅlemler daha verimli
+ olacak fakat derlenen Apache çalıÅtırılabiliri (386 üzerinde
+ deÄil) sadece 486 ve sonrası kırmıklarda çalıÅacaktır.
+
+
+
+
+
+
+
mod_status ve ExtendedStatus On
+
+
+
+
+
mod_status modülünü derlemiŠve Apache'yi
+ yapılandırır ve çalıÅtırırken ExtendedStatus On satırını
+ da kullanmıÅsanız Apache her istek üzerinde
+ gettimeofday(2) (veya iÅletim sistemine baÄlı olarak
+ time(2)) çaÄrısından baÅka (1.3 öncesinde) fazladan
+ defalarca time(2) çaÄrıları yapacaktır. Bu çaÄrılarla
+ durum raporununun zamanlama bilgilerini içermesi saÄlanır. BaÅarımı
+ arttırmak için ExtendedStatus off yapın (zaten öntanımlı
+ böyledir).
+
+
+
+
accept dizgilemesi ve çok soketli iÅlem
+
+
+
+
Uyarı:
+
Bu bölüm, Apache HTTP sunucusunun 2.x sürümlerinde yapılan
+ deÄiÅikliklere göre tamamen güncellenmemiÅtir. Bazı bilgiler hala
+ geçerliyse de lütfen dikkatli kullanınız.
+
+
+
Burada Unix soket arayüzü gerçeklenirken ihmal edilen bir durumdan
+ bahsedeceÄiz. HTTP sunucunuzun çok sayıda adresten çok sayıda portu
+ dinlemek için çok sayıda Listen yönergesi kullanmakta olduÄunu varsayalım. Her
+ soketi çalıÅtıÄını görmek için denerken Apache baÄlantı için
+ select(2) kullanacaktır. select(2) çaÄrısı
+ bu soketin üzerinde sıfır veya en azından bir
+ baÄlantının beklemekte olduÄu anlamına gelir. Apache'nin modeli çok
+ sayıda çocuk süreç içerir ve boÅta olanların tümünde aynı anda yeni
+ baÄlantılar denenebilir. Gerçekte çalıÅan kod bu olmasa da meramımızı
+ anlatmak için kodun Åöyle bir Åey olduÄunu varsayabiliriz:
+
+
+ for (;;) {
+
+ for (;;) {
+
+ fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+
+ FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+
+ if (FD_ISSET (i, &accept_fds)) {
+
+ new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ process the new_connection;
+
+ }
+
+
+
Bu özet gerçeklenim bir takım açlık sorunlarına sebep olur. Bu
+ döngünün çalıÅması sırasında aynı anda çok sayıda çocuk süreç yeniden
+ çaÄrılır ve istekler arasında kalan çoÄu çocuk da select
+ ile engellenir. Engellenen tüm bu çocuklar soketlerden herhangi biri
+ üzerinde tek bir istek göründüÄünde select tarafından
+ uyandırılıp iÅleme sokulmak üzere döndürülürler (uyandırılan çocuk
+ sayısı iÅletim sistemine ve zamanlama ayarlarına göre deÄiÅiklik
+ gösterir). Bunların hepsi döngüye katılıp baÄlantı kabul etmeye
+ (accept) çalıÅırlar. Fakat içlerinden yalnız biri
+ (sadece bir baÄlantı isteÄinin mevcut olduÄu varsayımıyla) bunu
+ baÅarabilir. Kalanının baÄlantı kabul etmesi (accept)
+ engellenir. Bu durum, bu çocukları istekleri baÅka baÅka soketlerden
+ deÄil mecburen tek bir soketten kabul etmeye kilitler ve bu soket
+ üzerinde yeni bir istek belirip uyandırılana kadar bu durumda
+ kalırlar. Bu açlık sorunu ilk olarak PR#467 sayılı raporla
+ belgelenmiÅtir. Bu sorunun en az iki çözümü vardır.
+
+
Ãözümün biri engellenmeyen soket kullanımıdır. Bu durumda
+ accept çocukları engellemeyecek ve yapılan bir
+ baÄlantının ardından diÄer çocuklar durumları deÄiÅmeksizin baÄlantı
+ beklemeye devam edeceklerdir. Fakat bu durum iÅlemci zamanının boÅa
+ harcanmasına sebep olur. SeçilmiÅ (select) boÅta on
+ çocuÄun olduÄunu ve bir baÄlantı geldiÄini varsayalım. Kalan dokuz
+ çocuk iÅine devam edip baÄlantı kabul etmeyi (accept)
+ deneyecek, baÅarızsız olacak, dönecek baÅa, tekrar seçilecek
+ (select) ve böyle hiçbir iŠyapmadan dönüp duracaktır. Bu
+ arada hizmet sunmakta olanlar da iÅlerini bitirdikten sonra bu
+ döngüdeki yerlerini alacaklardır. Aynı kutunun içinde boÅta bir sürü
+ iÅlemciniz (çok iÅlemcili sistemler) yoksa bu çözüm pek verimli
+ olmayacaktır.
+
+
DiÄer çözüm ise Apache tarafından kullanılan çözüm olup, girdiyi
+ bir iç döngüde sıraya sokmaktır. Döngü aÅaÄıda örneklenmiÅtir (farklar
+ vurgulanmıÅtır):
+
+
+ for (;;) {
+
+ accept_mutex_on ();
+ for (;;) {
+
+ fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+
+ FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+
+ if (FD_ISSET (i, &accept_fds)) {
+
+ new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ accept_mutex_off ();
+ process the new_connection;
+
+ }
+
+
+
accept_mutex_on ve accept_mutex_offiÅlevleri bir karÅılıklı red
+ semoforu oluÅtururlar. Mutekse aynı anda sadece bir çocuk sahip
+ olabilir. Bu muteksleri gerçeklemek için çeÅitli seçenekler vardır.
+ Seçim, src/conf.h (1.3 öncesi) veya
+ src/include/ap_config.h (1.3 ve sonrası) dosyasında
+ tanımlanmıÅtır. Bazı mimariler bir kilitleme seçeneÄine sahip
+ deÄildir. Böyle mimarilerde çok sayıda Listen yönergesi kullanmak güvenilir
+ olmayacaktır.
Bu yöntem, bir kilit dosyasını kilitlemek için
+ flock(2) sistem çaÄrısını kullanır (Kilit dosyasının
+ yeri LockFile
+ yönergesiyle belirtilir).
+
+
+
AcceptMutex fcntl
+
+
+
Bu yöntem, bir kilit dosyasını kilitlemek için
+ fcntl(2) sistem çaÄrısını kullanır (Kilit dosyasının
+ yeri LockFile
+ yönergesiyle belirtilir).
+
+
+
AcceptMutex sysvsem
+
+
+
(1.3 ve sonrası) Bu yöntem muteksi gerçeklemek için SysV tarzı
+ semaforları kullanır. Maalesef, SysV tarzı semaforların bazı yan
+ etkileri vardır. Bunlardan biri Apache'nin semaforu temizlemeden
+ ölme ihtimalidir (ipcs(8) kılavuz sayfasına bakınız).
+ DiÄer biri, CGI'lerin sunucu ile aynı kullanıcı kimliÄini
+ kullanmaları nedeniyle semafor arayüzünün hizmet reddi
+ saldırılarına açık olmasıdır (suexec veya
+ cgiwrapper gibi bir Åeyler kullanmadıkça bütün
+ CGI'ler için söz konusudur). Bu sebeple bu yöntem IRIX haricinde
+ hiçbir mimaride kullanılmaz (önceki ikisi çoÄu IRIX makine için
+ elde edilmesi imkansız derecede pahalı olduÄundan).
+
+
+
AcceptMutex pthread
+
+
+
(1.3 ve sonrası) Bu yöntem POSIX mutekslerini kullanır ve POSIX
+ evreleri belirtiminin tamamen gerçeklendiÄi mimarilerde çalıÅması
+ gerekirse de sadece Solaris (2.5 ve sonrası) üzerinde ve sadece
+ belli yapılandırmalarla çalıÅmakta gibi görünmektedir. Bunu
+ denemiÅseniz sunucunuzun çöktüÄünü ve yanıt vermediÄini
+ görmüÅsünüzdür. Sadece duruk içerikli sunucular iyi
+ çalıÅmaktadır.
+
+
+
AcceptMutex posixsem
+
+
+
(2.0 ve sonrası) Bu yöntem POSIX semaforlarını kullanır. EÄer
+ iÅlem sırasında bir evre muteks kaynaklı parçalama arızalarıyla
+ karÅı karÅıya kalırsa HTTP sunucusunun çökmesiyle semaforun sahibi
+ kurtarılamaz.
+
+
+
+
+
EÄer sisteminiz yukarıda bahsedilenler dıÅında baÅka bir dizgileme
+ yöntemi kullanıyorsa bununla ilgili kodun APR'ye eklenmesi girilen
+ zahmete deÄecektir.
+
+
BaÅka bir çözüm daha vardır ancak döngü kısmen dizgilenmeyeceÄinden
+ (yani belli sayıda sürece izin verilemeyeceÄinden) asla
+ gerçeklenmemiÅtir. Bu sadece, aynı anda çok sayıda çocuk sürecin
+ çalıÅabileceÄi ve dolayısıyla band geniÅliÄinin tüm yönleriyle
+ kullanılabileceÄi çok iÅlemcili sistemlerde ilginç olabilirdi. Bu
+ gelecekte incelenmeye deÄer bir konu olmakla beraber çok sayıda HTTP
+ sunucusunun aynı anda aynı amaca hizmet edecek Åekilde çalıÅması
+ standart olarak pek mümkün görülmediÄinden bu olasılık çok
+ düÅüktür.
+
+
En yüksek baÅarımı elde etmek için ideal olanı sunucuları
+ çalıÅtırırken çok sayıda Listen yönergesi kullanmamaktır. Fakat siz yine de
+ okumaya devam edin.
+
+
+
+
accept dizgilemesi - tek soket
+
+
+
+
Ãok soketli sunucular için yukarıda açıklananlar iyi güzel de tek
+ soketli sunucularda durum ne? Kuramsal olarak, bunların hiçbiriyle bir
+ sorunları olmaması gerekir. Ãünkü yeni bir baÄlantı gelene kadar tüm
+ çocuklar accept(2) ile engellenirler dolayısıyla hiçbir
+ açlık sorununun ortaya çıkmaması gerekir. Uygulamada ise son
+ kullanıcıdan gizli olarak, yukarıda engellenmeyen çocuklar çözümünde
+ bahsedilenle hemen hemen aynı "boÅa dönüp durma" davranıÅı mevcuttur.
+ ÃoÄu TCP yıÄıtı bu yolu gerçeklemiÅtir. Ãekirdek, yeni bir baÄlantı
+ ortaya çıktıÄında accept ile engellenen tüm süreçleri
+ uyandırır. Bu süreçlerden baÄlantıyı alan kullanıcı bölgesine geçerken
+ çekirdek içinde döngüde olan diÄerleri de yeni baÄlantı keÅfedilene
+ kadar uykularına geri dönerler. Bu çekirdek içi döngü, kullanıcı
+ bölgesindeki kodlara görünür deÄildir ama bu olmadıkları anlamına
+ gelmez. Bu durum, çok soketli engellenmeyen çocuklar çözümündeki boÅa
+ döngünün sebep olduÄu gereksiz iÅlemci yükü sorununu içinde
+ barındırır.
+
+
Bununla birlikte, tek soketli durumda bile bundan daha verimli bir
+ davranıŠsergileyen bir çok mimari bulduk. Bu aslında hemen hemen her
+ durumda öntanımlı olarak böyledir. Linux altında yapılan üstünkörü
+ denemelerde (128MB bellekli çift Pentium pro 166 iÅlemcili makinede
+ Linux 2.0.30) tek sokette dizgilemenin dizgilenmemiŠduruma göre
+ saniyede %3 daha az istekle sonuçlandıÄı gösterilmiÅtir. Fakat
+ dizgilenmemiÅ tek soket durumunda her istekte 100ms'lik ek bir gecikme
+ olduÄu görülmüÅtür. Bu gecikmenin sebebi muhtemelen uzun mesafeli
+ hatlar olup sadece yerel aÄlarda söz konusudur. Tek soketli
+ dizgilemeyi geçersiz kılmak için
+ SINGLE_LISTEN_UNSERIALIZED_ACCEPT tanımlarsanız tek
+ soketli sunucularda artık dizgileme yapılmayacaktır.
+
+
+
+
Kapatmayı zamana yaymak
+
+
+
+
draft-ietf-http-connection-00.txt taslaÄının 8. bölümünde
+ bahsedildiÄi gibi, bir HTTP sunucusunun protokolü güvenilir
+ Åekilde gerçeklemesi için her iki yöndeki iletiÅimi
+ birbirinden baÄımsız olarak (iki yönlü bir TCP baÄlantısının her
+ yarısını diÄerinden baÄımsız olarak) kapatması gerekir. Bu olgu baÅka
+ sunucular tarafından çoÄunlukla dikkate alınmaz fakat Apache'nin 1.2
+ sürümünden beri gerektiÄi gibi gerçeklenmektedir.
+
+
Bu özellik Apache'ye eklendiÄinde Unix'in çeÅitli sürümlerinde
+ uzgörüsüzlükten dolayı bir takım geçici telaŠsorunlarına sebep oldu.
+ TCP belirtimi FIN_WAIT_2 durumunda bir zaman aÅımından
+ bahsetmez ama yasaklamaz da. Zaman aÅımı olmayan sistemlerde, Apache
+ 1.2 çoÄu soketin sonsuza kadar FIN_WAIT_2 durumunda
+ takılıp kalmasına sebep olur. ÃoÄu durumda, satıcıdan saÄlanan en son
+ TCP/IP yamalarını uygulanarak bu önlenebilir. Satıcının hiçbir yeni
+ yama daÄıtmadıÄı durumlarda (örneÄin, SunOS4 -- bir kaynak lisansı ile
+ insanlar bunu kendileri yamayabilirse de) bu özelliÄi devre dıÅı
+ bırakmaya karar verdik.
+
+
Bunun üstesinden gelmenin iki yolu vardır. Bunlardan biri
+ SO_LINGER soket seçeneÄidir. Bu iÅin kaderi buymuÅ gibi
+ görünürse de çoÄu TCP/IP yıÄıtında bu gerektiÄi gibi
+ gerçeklenmemiÅtir. Bu yıÄıtlar üzerinde, bu yöntemin, doÄru bir
+ gerçeklenimle bile (örneÄin, Linux 2.0.31) sonraki çözümden daha
+ pahalı olduÄu ortaya çıkmıÅtır.
+
+
ÃoÄunlukla, Apache bunu (http_main.c içindeki)
+ lingering_close adında bir iÅlevle gerçekler. Bu iÅlev
+ kabaca Åöyle görünür:
+
+
+ void lingering_close (int s)
+ {
+
+ char junk_buffer[2048];
+
+ /* gönderen tarafı kapat */
+ shutdown (s, 1);
+
+ signal (SIGALRM, lingering_death);
+ alarm (30);
+
+ for (;;) {
+
+ /* s'i okumak için, 2 saniyelik zaman aÅımı ile seç */
+ select (s for reading, 2 second timeout);
+ /* Hata oluÅmuÅsa döngüden çık */
+ if (error) break;
+ /* s okumak için hazırsa */
+ if (s is ready for reading) {
+
+ if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+
+ break;
+
+ }
+ /* geri kalan herÅey burada */
+
+ }
+
+ }
+
+ close (s);
+
+ }
+
+
+
BaÄlantı sonunda bu doÄal olarak biraz daha masrafa yol açar, fakat
+ güvenilir bir gerçeklenim için bu gereklidir. HTTP/1.1'in daha yaygın
+ kullanılmaya baÅlanması ve tüm baÄlantıların kalıcı hale gelmesiyle bu
+ gerçeklenim daha fazla istek üzerinden kendi masrafını
+ karÅılayacaktır. AteÅle oynamak ve bu özelliÄi devre dıÅı bırakmak
+ isterseniz NO_LINGCLOSE'u tanımlayabilirsiniz, fakat bu
+ asla önerilmez. Ãzellikle, HTTP/1.1'den itibaren boruhatlı kalıcı
+ baÄlantıların lingering_close kullanmaya baÅlaması mutlak
+ bir gerekliliktir (ve
+ boruhatlı baÄlantıların daha hızlı olması nedeniyle bu
+ baÄlantıları desteklemek isteyebilirsiniz).
+
+
+
+
Ãetele Dosyası
+
+
+
+
Apache'nin ana ve alt süreçleri birbirleriyle çetele denen birÅey
+ üzerinden haberleÅirler. Bunun en mükemmel Åekilde paylaÅımlı bellekte
+ gerçeklenmesi gerekir. EriÅtiÄimiz veya portlarını ayrıntılı olarak
+ belirttiÄimiz iÅletim sistemleri için bu, genellikle paylaÅımlı bellek
+ kullanılarak gerçeklenir. Geri kalanlar, öntanımlı olarak bunu bir
+ disk dosyası kullanarak gerçekler. Bir disk dosyaı yavaŠolmanın yanı
+ sıra güvenilir de deÄildir (ve daha az özelliÄe sahiptir). Mimarinizin
+ src/main/conf.h dosyasını inceleyin ve
+ USE_MMAP_SCOREBOARD veya
+ USE_SHMGET_SCOREBOARD'a bakın. Bu ikisinden birinin (ve
+ yanı sıra sırasıyla HAVE_MMAP veya
+ HAVE_SHMGET'in) tanımlanmıŠolması, saÄlanan paylaÅımlı
+ bellek kodunu etkinleÅtirir. EÄer sisteminiz diÄer türdeki paylaÅımlı
+ belleÄe sahipse, src/main/http_main.c dosyasını açıp,
+ Apache'de bu belleÄi kullanması gereken kanca iÅlevleri ekleyin (Bize
+ de bir yama yollayın, lütfen).
+
+
Tarihsel bilgi: Apache'nin Linux uyarlaması, Apache'nin 1.2
+ sürümüne kadar paylaÅımlı belleÄi kullanmaya baÅlamamıÅtı. Bu kusur,
+ Apache'nin Linux üzerindeki erken dönem sürümlerinin davranıÅlarının
+ zayıf ve güvenilmez olmasına yol açmıÅtı.
+
+
+
+
DYNAMIC_MODULE_LIMIT
+
+
+
+
Devingen olarak yüklenen modülleri kullanmamak niyetindeyseniz
+ (burayı okuyan ve sunucunuzun baÅarımını son kırıntısına kadar
+ arttırmakla ilgilenen biriyseniz bunu düÅünmezsiniz), sunucunuzu
+ derlerken seçenekler arasına -DDYNAMIC_MODULE_LIMIT=0
+ seçeneÄini de ekleyin. Bu suretle, sadece, devingen olarak yüklenen
+ modüller için ayrılacak belleÄi kazanmıŠolacaksınız.
Bu izlemede, dinleyen evre HS #67 içinde çalıÅmaktadır.
+
+
accept(2) dizgelemesinin olmayıÅına dikkat edin.
+ Ãzellikle bu platformda worker MPM, çok sayıda portu dinlemedikçe,
+ öntanımlı olarak dizgeleÅtirilmemiÅ bir accept çaÄrısı kullanır.
BaÄlantının kabul edilmesiyle, dinleyici evre isteÄi yerine getirmek
+ üzere bir worker evresini uyandırır. Bu izlemede, isteÄi yerine getiren
+ worker evresi HS #65'e aittir.
Sanal konakların gerçeklenimi sırasında, Apache'nin, baÄlantıları
+ kabul etmek için kullanılan yerel soket adreslerini bilmesi gerekir.
+ ÃoÄu durumda bu çaÄrıyı bertaraf etmek mümkündür (hiç sanal konaÄın
+ olmadıÄı veya Listen
+ yönergelerinin mutlak adreslerle kullanıldıÄı durumlarda). Fakat bu en
+ iyilemeleri yapmak için henüz bir çaba harcanmamıÅtır.
Bu httpd Options FollowSymLinks ve AllowOverride
+ None ile yapılandırılmıÅtır. Bu bakımdan, ne istenen dosya ile
+ sonuçlanan yol üzerindeki her dizinde lstat(2) çaÄrısına ne
+ de .htaccess dosyalarına bakılmasına gerek vardır.
+ stat(2) çaÄrısı basitçe dosya için Åunları doÄrulamak
+ amacıyla yapılır: 1) dosya mevcuttur ve 2) bir dizin deÄil normal bir
+ dosyadır.
Bu örnekte, httpd, istenen dosyayı ve HTTP yanıt baÅlıÄını tek bir
+ sendfilev(2) sistem çaÄrısı ile göndermektedir. Dosya
+ gönderim iÅleminin anlamı sistemden sisteme deÄiÅiklik gösterir. Bazı
+ sistemlerde, sendfile(2) çaÄrısından önce baÅlıkları
+ göndermek için write(2) veya writev(2)
+ çaÄrısı yapmak gerekir.
Bu write(2) çaÄrısı isteÄi eriÅim günlüÄüne kaydeder. Bu
+ izlemede eksik olan tek Åey, time(2) çaÄrısıdır. Apache
+ 1.3'ün aksine, Apache 2.x zamana bakmak için
+ gettimeofday(3) çaÄırısını kullanır. Linux ve Solaris gibi
+ bazı iÅletim sistemleri, gettimeofday iÅlevinin, sıradan
+ bir sistem çaÄrısından daha fazla götürüsü olmayan en iyilenmiÅ bir
+ gerçeklenimine sahiptir.
Son olarak, worker evresi teslim edilen dosyayı kapattıktan sonra
+ dinleyici evre tarafından baÅka bir baÄlantı atanıncaya kadar beklemeye
+ alınır.
Bu arada, dinleyici evre baÄlantıyı bir worker evresine atar atamaz
+ baÅka bir baÄlantıyı beklemeye baÅlar (Mevcut tüm evreler meÅgulse
+ dinleyici evreyi baskılayan worker MPM'nin akıŠdenetim Åemasına konu
+ olur). Bu izlemede görünmüyor olsa da sonraki accept(2)
+ çaÄrısı, yeni baÄlantı kabul eden worker evresine paralel olarak
+ yapılabilir (aÅırı yük durumlarında normal olarak, bu yapılır).
Bu yönerge yanıtın ortam türüne
baÄlı olarak bir istek için belli bir çıktı
süzgecini etkin kılar. AÅaÄıda açıklanan belli baÅlı sorunlardan
dolayı bu yönergenin kullanımı önerilmemektedir. Aynı iÅlevsellik
@@ -353,13 +352,10 @@ kullanımı önerilmemektedir.
Ek Bilgi
Süzgeçlerin AddOutputFilterByType ile etkin
kılınması bazı durumlarda kısmen bazılarında da tamamen baÅarısızlıÄa
- uÄrayabilir. ÃrneÄin, MIME türü
- saptanamadıÄı takdirde hiçbir süzgeç uygulanmaz ve DefaultType aynı olsa bile son çare olarak
- DefaultType ayarlarına geri
- dönülür.
-
-
Bununla birlikte, süzgeçlerin uygulanacaÄına emin olmak isterseniz,
- bir kaynaÄa içerik türünü örneÄin, AddType veya
+ uÄrayabilir. ÃrneÄin, ortam türü
+ saptanamadıÄı takdirde hiçbir süzgeç uygulanmaz. Süzgeçlerin
+ uygulanacaÄına emin olmak isterseniz, bir kaynaÄa içerik türünü
+ örneÄin, AddType veya
ForceType ile açıkça
atayabilirsiniz. Ayrıca, içerik türünü (bir nph-olmayan) CGI betiÄi
içinde ayarlamak da bu güvenceyi saÄlar.
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.
none deÄeri Apache 2.2.7 ve sonrasında mevcuttur.
-
+DiÄer tüm seçenekler Apache'nin 2.3.x ve sonraki sürümleri için iptal
+edilmiÅtir.
-
Sunucudan zaman zaman kendi MIME
- türü ile uyuÅmayan bir belge sunması istenir.
-
-
Sunucu, belgenin içerik türünü istemciye bildirmek zorundadır. EÄer
- sunucu bunu normal yollardan saptayamazsa içerik türü olarak
- DefaultType ile belirtilen deÄeri gönderir. ÃrneÄin, GIF
- dosyaları bulunan bir dizinde .gif uzantısına sahip
- olmayan dosyaların da bulunması durumunda, bu dizin için,
+
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 image/gif
+ DefaultType none
-
belirtilmesi uygun olurdu.
-
-
İçerik türünün ne sunucu ne de yönetici (örneÄin, vekil) tarafından
- saptanabildiÄi durumlarda MIME türünün yanlıŠbelirtilmesindense tür
- belirtmemek tercih edilebilir. Bu, Åöyle yapılabilir:
-
- DefaultType None
-
DefaultType None sadece httpd-2.2.7 ve sonrasında
mevcuttur.
-
Bu yönergenin sadece öntanımlı MIME-türünü saÄlaması nedeniyle
- ForceType yönergesinden farklı
- olduÄuna dikkat ediniz. Dosya ismi uzantıları dahil, tüm diÄer
- MIME-türü tanımları ortam türünü tanımladıÄı noktada bu öntanımlı türü
- sunulan veri için geçersiz kılacaktır.
+
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.
Defines a default language-tag to be sent in the Content-Language
header field for all resources in the current context that have not been
assigned a language-tag by some other means.
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.