<a href="../ja/mod/core.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
<a href="../tr/mod/core.html" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Bu çeviri güncel olmayabilir. Son değişiklikler için İngilizce sürüm geçerlidir.</div>
<table class="module"><tr><th><a href="module-dict.html#Description">Açıklama:</a></th><td>Apache HTTP Sunucusunda daima mevcut olan çekirdek
özellikler</td></tr>
<tr><th><a href="module-dict.html#Status">Durum:</a></th><td>Çekirdek</td></tr></table>
gerçekleniminde hatalı olarak izin verilmişti. Geriye uyumluluk amacıyla
(önceden sezilmeyen sonuçlarıyla) bu durum muhafaza edilmiştir.</p>
+<h3>Ayrıca bakınız:</h3>
+<ul>
+<li><code class="directive"><a href="#undefine">UnDefine</a></code></li>
+<li><code class="directive"><a href="#ifdefine">IfDefine</a></code></li>
+</ul>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="Directory" id="Directory"><Directory></a> <a name="directory" id="directory">Yönergesi</a></h2>
(<a href="https://tools.ietf.org/html/rfc7230#section-3.2">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>
+
+ <div class="warning"><h3>Unsafe için güvenlik riskleri</h3>
+ <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>
+ </div>
+
+ <div class="example"><h3>Strict kipte HTTP 400 ile sonuçlanan bir istek örneği</h3><p><code>
+
+ # Eksik CRLF<br />
+ GET / HTTP/1.0\n\n
+ </code></p></div>
+ <div class="warning"><h3>Komut satırı araçları ve CRLF</h3>
+ <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 <code class="directive"><a href="../mod/mod_dumpio.html#dumpioinput">DumpIOInput</a></code>
+ yönergesi yardımcı olabilir.</p>
+ </div>
+ </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
+ <code class="directive">RegisterHttpMethod</code> yönergesini kullanarak standart
+ olmayan yöntemleri belirlemelidir. Özellikle <code>Unsafe</code> seçeneğine
+ geçiş yapılacaksa bu yol izlenmelidir.</p>
+
+ <div class="warning"><h3>İleri Vekil Uyumluluğu</h3>
+ <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>
+ </div>
+
+ <div class="example"><h3>Example of a request leading to HTTP 501 with LenientMethods mode</h3><p><code>
+
+ # 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 />
+ </code></p></div>
+ </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>
+
+ <div class="example"><h3>Require1.0 kipinde HTTP 400 ile sonuçlanan bir istek
+ örneği</h3><p><code>
+
+ # Desteklenmeyen HTTP sürümü<br />
+ GET /\r\n\r\n
+ </code></p></div>
+ </dd>
+ </dl>
<p><code class="directive">LogLevel</code> <code>debug</code> seviyesiyle
yapılandırılmış <code class="directive">ErrorLog</code> ile kaydedilmiş günlüklerin
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
- <code class="directive">RegisterHttpMethod</code> 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>
-
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="If" id="If"><If></a> <a name="if" id="if">Yönergesi</a></h2>
yönerge için kullanılabilir olmayacaktır.
</div>
+ <div class="note"><h3>Betik dillerindeki gibi değil</h3>
+ 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 <code class="directive"><If></code> yönergeleri
+ desteklenmemektedir.
+ </div>
+
<h3>Ayrıca bakınız:</h3>
<ul>
<li><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><code class="module"><a href="../mod/mod_cgi.html">mod_cgi</a></code> modülünde, bir CGI betiğinden çıktı için
- beklenecek süre.</li>
+ <li><code class="module"><a href="../mod/mod_cgi.html">mod_cgi</a></code> ve <code class="module"><a href="../mod/mod_cgid.html">mod_cgid</a></code> modülünde, bir CGI
+ betiğinden belli bir çıktı kümesi için beklenecek süre.</li>
<li><code class="module"><a href="../mod/mod_ext_filter.html">mod_ext_filter</a></code> 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>
+<h3>Ayrıca bakınız:</h3>
+<ul>
+<li><code class="directive"><a href="#define">Define</a></code></li>
+<li><code class="directive"><a href="#ifdefine">IfDefine</a></code></li>
+</ul>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="UseCanonicalName" id="UseCanonicalName">UseCanonicalName</a> <a name="usecanonicalname" id="usecanonicalname">Yönergesi</a></h2>
<a href="./ko/sections.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="./tr/sections.html" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Bu çeviri güncel olmayabilir. Son değişiklikler için İngilizce sürüm geçerlidir.</div>
<p><a href="configuring.html">Yapılandırma dosyaları</a>ndaki
yönergeler sunucunun tamamına uygulanacağı gibi sadece belli dizinler,
<p>Bazı bölüm türleri başka bölüm türlerinin içinde olabilir. Bir yandan,
<code class="directive"><a href="./mod/core.html#files"><Files></a></code> bölümü
<code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> bölümünün
- içinde bulunabilirken diğer yandan bir <code class="directive"><a href="./mod/core.html#if"><If></a></code> bölümü <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>, <code class="directive"><a href="./mod/core.html#location"><Location></a></code> ve <code class="directive"><a href="./mod/core.html#files"><Files></a></code> bölümlerinde bulunabilir.
- Bu bölümlerin düzenli ifadeli türevleri de benzer tarzda davranır.</p>
+ içinde bulunabilirken diğer yandan bir <code class="directive"><a href="./mod/core.html#if"><If></a></code> bölümü <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>, <code class="directive"><a href="./mod/core.html#location"><Location></a></code> ve <code class="directive"><a href="./mod/core.html#files"><Files></a></code> bölümlerinde bulunabilir fakat
+ başka bir <code class="directive"><a href="./mod/core.html#if"><If></a></code> 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><code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>
- 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 <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> 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 <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> bölümleri yapılandırma dosyasında
- bulundukları sıraya göre işleme sokulurlar. <code class="directive"><a href="./mod/core.html#include">Include</a></code> yönergeleri ile yapılandırmaya dahil
- edilen dosyaların içerikleri <code class="directive"><a href="./mod/core.html#include">Include</a></code>
- yönergesinin bulunduğu yere konulduktan sonra işleme sokulurlar.</p>
-
- <p><code class="directive"><a href="./mod/core.html#virtualhost"><VirtualHost></a></code>
- 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 <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code> tarafından sunulduğu takdirde,
- <code class="directive"><a href="./mod/mod_proxy.html#proxy"><Proxy></a></code> taşıyıcısı
- işlem sırasında <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> taşıyıcısının yerini alır.</p>
+ <p>Bazı önemli durumlar:</p>
+ <ul>
+ <li><code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>
+ 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 <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> 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 <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> bölümü varsa bunlar yapılandırma
+ dosyasında bulundukları sıraya göre işleme sokulurlar.</li>
+
+ <li><code class="directive"><a href="./mod/core.html#include">Include</a></code> yönergeleri ile
+ yapılandırmaya dahil edilen dosyaların içerikleri <code class="directive"><a href="./mod/core.html#include">Include</a></code> yönergesinin bulunduğu yere konulduktan
+ sonra işleme sokulurlar.</li>
+
+ <li><code class="directive"><a href="./mod/core.html#virtualhost"><VirtualHost></a></code>
+ 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 <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code> tarafından sunulduğu takdirde,
+ <code class="directive"><a href="./mod/mod_proxy.html#proxy"><Proxy></a></code> taşıyıcısı
+ işlem sırasında <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> taşıyıcısının yerini alır.</li>
+ </ul>
<div class="note"><h3>Bazı Teknik Bilgiler</h3>
Aslında, isim dönüşüm aşamasından (<code>Aliases</code> ve
projects / apache / commitdiff