<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 1772678:1787736 (outdated) -->
+<!-- English Revision: 1787736 -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.gen.tr>
Reviewed by: Orhan Berent <berent belgeler.gen.tr>
gerçekleniminde hatalı olarak izin verilmişti. Geriye uyumluluk amacıyla
(önceden sezilmeyen sonuçlarıyla) bu durum muhafaza edilmiştir.</p>
</usage>
+<seealso><directive module="core">UnDefine</directive></seealso>
+<seealso><directive module="core">IfDefine</directive></seealso>
</directivesynopsis>
<directivesynopsis type="section">
>RFC 7230 §3.2</a>) uygulanmış kuralları öntanımlı olarak veya
<code>Strict</code> 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 <code>Unsafe</code> seçeneği eklenmiştir. Bu kurallar
- istek işlenmeden önce uygulanır. Dolayısıyla yönerge, ana bölümde veya
- öntanımlı (ilk) eşleşen sanal konak bölümünde yapılandırılmalıdır.</p>
-
- <p>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ı. <a href="https://tools.ietf.org/html/rfc7230#section-9.4"
- >RFC 7230 §9.4 İstek bölme</a> ve
- <a href="https://tools.ietf.org/html/rfc7230#section-9.5"
- >§9.5 Yanıt kaçırma</a> çağrıları uyumsuz istek iletilerinin kabulündeki
- olası risklerden yalnızca iki tanesidir.
- <a href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230
- §3.5</a> "İ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ı <code>Strict</code> 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.</p>
-
- <p>Kullanıcılar, özellikle dışa bakan, herkes tarafından erişilebilen sunucu
- konuşlandırmalarında <code>Unsafe</code> 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 <code>Unsafe</code> işlem kipine geçiş yapmalıdır.</p>
+ dönmeyi sağlamak üzere <code>Unsafe</code> seçeneği eklenmiştir.</p>
+
+ <p>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.</p>
+
+ <p>Bu yönergeye aşağıdaki parametrelerden seçilen üç tanesi uygulanabilir.
+ Belirtilmeyenlerin yerine öntanımlılar uygulanır.</p>
+
+ <dl>
+ <dt>Strict|Unsafe</dt>
+ <dd>
+ <p>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ı. <a href="https://tools.ietf.org/html/rfc7230#section-9.4"
+ >RFC 7230 §9.4 İstek bölme</a> ve
+ <a href="https://tools.ietf.org/html/rfc7230#section-9.5"
+ >§9.5 Yanıt kaçırma</a> çağrıları uyumsuz istek iletilerinin
+ kabulündeki olası risklerden yalnızca iki tanesidir.
+ <a href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230
+ §3.5</a> "İ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ı
+ <code>Strict</code> 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.</p>
+
+ <note type="warning"><title>Unsafe için güvenlik riskleri</title>
+ <p>Kullanıcılar, özellikle dışa bakan, herkes tarafından erişilebilen
+ sunucu konuşlandırmalarında <code>Unsafe</code> 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 <code>Unsafe</code> işlem
+ kipine geçiş yapmalıdır.</p>
+ </note>
+
+ <example>
+ <title>Strict kipte HTTP 400 ile sonuçlanan bir istek örneği</title>
+ # Eksik CRLF<br />
+ GET / HTTP/1.0\n\n
+ </example>
+ <note type="warning"><title>Komut satırı araçları ve CRLF</title>
+ <p>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, <strong>OpenSSL s_client düzgün çalışmak için -crlf
+ değiştirgesine ihtiyaç duyar</strong>.</p>
+ <p>CRLF yokluğu gibi durumları saptamak için HTTP isteğini görünümlemek
+ isterseniz <directive module="mod_dumpio">DumpIOInput</directive>
+ yönergesi yardımcı olabilir.</p>
+ </note>
+ </dd>
+ <dt>RegisteredMethods|LenientMethods</dt>
+ <dd>
+ <p><a href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231
+ §4.1</a> "İ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. <code>LenientMethods</code>
+ seçeneği kullanıldığında olan zaten budur. <code>RegisteredMethods</code>
+ seçeneğine geçiş yapmak isteyen yöneticiler
+ <directive>RegisterHttpMethod</directive> yönergesini kullanarak standart
+ olmayan yöntemleri belirlemelidir. Özellikle <code>Unsafe</code> seçeneğine
+ geçiş yapılacaksa bu yol izlenmelidir.</p>
+
+ <note type="warning"><title>İleri Vekil Uyumluluğu</title>
+ <p>Özgün sunucunun kullandığı yöntemleri vekil sunucu bilemeyeceği için
+ ileri vekil konaklarda <code>RegisteredMethods</code> seçeneğine geçiş
+ yapılmamalıdır.</p>
+ </note>
+
+ <example>
+ <title>Example of a request leading to HTTP 501 with LenientMethods mode</title>
+ # Unknown HTTP method<br />
+ WOW / HTTP/1.0\r\n\r\n<br /><br />
+ # Lowercase HTTP method<br />
+ get / HTTP/1.0\r\n\r\n<br />
+ </example>
+ </dd>
+ <dt>Allow0.9|Require1.0</dt>
+ <dd>
+ <p><a href="https://tools.ietf.org/html/rfc2616#section-19.6">RFC 2616
+ §19.6</a> "Ö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 <a
+ href="https://tools.ietf.org/html/rfc7230#appendix-A"
+ >RFC 7230 Ek A</a> bölümünde bununla ilgili yorumlar yer almıştır.
+ <code>Require1.0</code> seçeneği kullanıcıya öntanımlı
+ <code>Allow0.9</code> seçeneğinin davranışına verilen desteği kaldırma
+ imkanını vermektedir.</p>
+
+ <example>
+ <title>Require1.0 kipinde HTTP 400 ile sonuçlanan bir istek
+ örneği</title>
+ # Desteklenmeyen HTTP sürümü<br />
+ GET /\r\n\r\n
+ </example>
+ </dd>
+ </dl>
<p><directive>LogLevel</directive> <code>debug</code> seviyesiyle
yapılandırılmış <directive>ErrorLog</directive> ile kaydedilmiş günlüklerin
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.</p>
-
- <p><a href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231
- §4.1</a> "İ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. <code>LenientMethods</code>
- seçeneği kullanıldığında olan zaten budur. <code>RegisteredMethods</code>
- seçeneğine geçiş yapmak isteyen yöneticiler
- <directive>RegisterHttpMethod</directive> yönergesini kullanarak standart
- olmayan yöntemleri belirlemelidir. Özellikle <code>Unsafe</code> seçeneğine
- geçiş yapılacaksa bu yol izlenmelidir. Özgün sunucunun kullandığı yöntemleri
- vekil sunucu bilemeyeceği için ileri vekil konaklarda
- <code>RegisteredMethods</code> seçeneğine geçiş yapılmamalıdır.</p>
-
- <p><a href="https://tools.ietf.org/html/rfc2616#section-19.6">RFC 2616
- §19.6</a> "Ö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 <a href="https://tools.ietf.org/html/rfc7230#appendix-A"
- >RFC 7230 Ek A</a> bölümünde bununla ilgili yorumlar yer almıştır.
- <code>Require1.0</code> seçeneği kullanıcıya öntanımlı <code>Allow0.9</code>
- seçeneğinin davranışına verilen desteği kaldırma imkanını vermektedir.</p>
</usage>
</directivesynopsis>
değişkenler ve diğer yanıt başlıkları zaten yorumlanmış olacaklarından bu
yönerge için kullanılabilir olmayacaktır.
</note>
+
+ <note><title>Betik dillerindeki gibi değil</title>
+ Bu yönergenin ismi yöneticiler ve yazılımcılara çok tanıdıktır fakat betik
+ dillerinde rastladığınız benzeri ile karıştırılmamalıdır. Örneğin, mevcut
+ gerçeklenimde iç içe <directive type="section">If</directive> yönergeleri
+ desteklenmemektedir.
+ </note>
</usage>
<seealso><a href="../expr.html">Apache HTTP Sunucusundaki
<li>Veriyi istemciye yazarken, gönderme tamponu dolu olduğu takdirde bir
paket alındısı için beklenecek süre.</li>
- <li><module>mod_cgi</module> modülünde, bir CGI betiğinden çıktı için
- beklenecek süre.</li>
+ <li><module>mod_cgi</module> ve <module>mod_cgid</module> modülünde, bir CGI
+ betiğinden belli bir çıktı kümesi için beklenecek süre.</li>
<li><module>mod_ext_filter</module> modülünde, bir süzme işleminden çıktı
almak için beklenecek süre.</li>
konaklar haricinde, değişiklikleri kendisinden sonraki tüm yapılandırma
yönergelerinde görünür kılar.</p>
</usage>
+<seealso><directive module="core">Define</directive></seealso>
+<seealso><directive module="core">IfDefine</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>
-<!-- English Revision: 1755978:1787736 (outdated) -->
+<!-- English Revision: 1787736 -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.gen.tr>
Reviewed by: Orhan Berent <berent belgeler.gen.tr>
module="core">If</directive> bölümü <directive type="section"
module="core">Directory</directive>, <directive type="section"
module="core">Location</directive> ve <directive
- type="section" module="core">Files</directive> bölümlerinde bulunabilir.
- Bu bölümlerin düzenli ifadeli türevleri de benzer tarzda davranır.</p>
+ type="section" module="core">Files</directive> bölümlerinde bulunabilir fakat
+ başka bir <directive type="section" module="core">If</directive> bölümünün
+ içinde bulunamaz. Bu bölümlerin düzenli ifadeli türevleri de benzer tarzda
+ davranır.</p>
<p>İç içe bölümler, aynı türdeki iç içe olmayan bölümlerin sonrasına
yerleştirilir.</p>
</li>
</ol>
- <p><directive type="section" module="core">Directory</directive>
- bölümündekiler hariç, her grup, yapılandırma dosyasında bulundukları
- sıraya göre işleme sokulurlar. Yukarıda 1. grup olan <directive
- type="section" module="core">Directory</directive> bölümü en kısa dizin
- elemanından en uzun dizin elemanına doğru işleme sokulur. Yani, örneğin,
- <code><Directory "/var/web/dir"></code> bölümü <code><Directory
- "/var/web/dir/subdir"></code> bölümünden önce işleme sokulacaktır. Eğer
- aynı uzunlukta çok sayıda dizin varsa <directive type="section"
- module="core">Directory</directive> bölümleri yapılandırma dosyasında
- bulundukları sıraya göre işleme sokulurlar. <directive
- module="core">Include</directive> yönergeleri ile yapılandırmaya dahil
- edilen dosyaların içerikleri <directive module="core">Include</directive>
- yönergesinin bulunduğu yere konulduktan sonra işleme sokulurlar.</p>
-
- <p><directive type="section" module="core">VirtualHost</directive>
- bölümlerinin içindeki bölümler, sanal konak tanımı dışındaki
- karşılıklarından <em>sonra</em> uygulanırlar.</p>
-
- <p>İstek <module>mod_proxy</module> tarafından sunulduğu takdirde,
- <directive module="mod_proxy" type="section">Proxy</directive> taşıyıcısı
- işlem sırasında <directive module="core" type="section"
- >Directory</directive> taşıyıcısının yerini alır.</p>
+ <p>Bazı önemli durumlar:</p>
+ <ul>
+ <li><directive type="section" module="core">Directory</directive>
+ bölümündekiler hariç, her grup, yapılandırma dosyasında bulundukları
+ sıraya göre işleme sokulurlar. Örneğin, 4. grupta <em>/foo</em> için yapılan
+ bir istek <code><Location "/foo/bar"></code> ve <code><Location
+ "/foo"></code> bölümleriyle de eşleşir ve bunlar yapılandırma
+ dosyalarında bulundukları sıraya göre değerlendirilir.</li>
+
+ <li>Yukarıda 1. grup olan <directive type="section"
+ module="core">Directory</directive> bölümü en kısa dizin elemanından en uzun
+ dizin elemanına doğru işleme sokulur. Yani, örneğin, <code><Directory
+ "/var/web/dir"></code> bölümü <code><Directory
+ "/var/web/dir/subdir"></code> bölümünden önce işleme sokulacaktır.</li>
+
+ <li>Eğer aynı dizin için birden fazla <directive type="section"
+ module="core">Directory</directive> bölümü varsa bunlar yapılandırma
+ dosyasında bulundukları sıraya göre işleme sokulurlar.</li>
+
+ <li><directive module="core">Include</directive> yönergeleri ile
+ yapılandırmaya dahil edilen dosyaların içerikleri <directive
+ module="core">Include</directive> yönergesinin bulunduğu yere konulduktan
+ sonra işleme sokulurlar.</li>
+
+ <li><directive type="section" module="core">VirtualHost</directive>
+ bölümlerinin içindeki bölümler, sanal konak tanımı dışındaki
+ karşılıklarından <em>sonra</em> uygulanırlar. Bu yöntemle ana sunucu
+ yapılandırmasındaki tanımlar geçersiz kılınabilir</li>
+
+ <li>İstek <module>mod_proxy</module> tarafından sunulduğu takdirde,
+ <directive module="mod_proxy" type="section">Proxy</directive> taşıyıcısı
+ işlem sırasında <directive module="core" type="section"
+ >Directory</directive> taşıyıcısının yerini alır.</li>
+ </ul>
<note><title>Bazı Teknik Bilgiler</title>
Aslında, isim dönüşüm aşamasından (<code>Aliases</code> ve
projects / apache / commitdiff