Günlük Dosyaları

Mevcut Diller: en | + es | + ja | + ko | + tr

+ +

Bir HTTP sunucusunu verimli şekilde yönetebilmek için oluşabilecek + sorunlardan başka sunucunun başarımı ve etkinliği hakkında da bazı geri + bildirimler almak gerekir. Apache HTTP Sunucusu çok kapsamlı ve esnek + bir günlükleme yeteneğine sahiptir. Bu belgede sunucunun günlükleme + yeteneğini nasıl yapılandıracağınızdan ve günlük kayıtlarını nasıl + yorumlayacağınızdan bahsedilecektir.

Güvenlik Uyarısı
Hata Günlüğü
Erişim Günlüğü
Günlük Çevrimi
Borulu Günlükler
Sanal Konaklar
Diğer Günlük Dosyaları

Güvenlik Uyarısı

+ + +

Apache’nin günlük dosyalarını yazdığı dizine yazabilen birinin sunucuyu + başlatan kullanıcı kimliğine (bu genellikle root olur) erişim + kazanabileceğine hemen hemen kesin gözüyle bakılabilir. Sonuçlarının + neler olacağını kestiremiyorsanız günlüklerin yazıldığı dizinde hiç + kimseye yazma erişimi vermeyin; ayrıntılı bilgi için güvenlik ipuçları belgesine + bakınız.

+ +

Buna ilaveten, günlük dosyaları istemci tarafından sağlanmış bilgiler + de içerebilir. Bu nedenle, kötü niyetli istemcilerin günlük dosyalarına + denetim karakterleri girmeleri olasılığına karşı ham günlükler ele + alınırken dikkatli olunmalıdır.

Hata Günlüğü

İlgili Modüller	İlgili Yönergeler
	`ErrorLog` `LogLevel`

+ + + + +

İsmi ve yeri ErrorLog yönergesi + ile belirtilen sunucu hata günlüğü, en önemli günlük dosyasıdır. Apache + httpd tarafından istekler işlenirken saptanan hatalar ve tanı bilgileri + bu dosyaya gönderilir. Sunucuyu başlatırken veya sunucu çalışırken bir + sorunla karşılaşıldığında, neyin yanlış gittiğini öğrenmek için + bakılacak ilk yer burasıdır. Günlük kaydı çoğunlukla sorunun nasıl + düzeltileceği ile ilgili ayrıntıları da içerir.

+ +

Hata günlüğü normal olarak bir dosyaya yazılır (genellikle, dosyanın + ismi Unix sistemlerinde error_log, Windows ve OS/2’de ise + error.log’dur). Ayrıca, Unix sistemlerinde sunucunun + hataları syslog’a veya borulamak suretiyle + bir programa aktarması da mümkündür.

+ +

Hata günlüğünün biçemi anlaşılır olup içeriği kısmen serbestçe + belirlenir. Çoğu hata günlüğü girdisinde bulunan belli başlı bilgiler + vardır. Örnek tipik bir hata iletisi içermektedir:

+ +

+ [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] + client denied by server configuration: + /export/home/live/ap/htdocs/test +

+ +

Günlük girdisinin ilk öğesi iletinin yazıldığı tarih ve saatten oluşur. + İkinci öğe raponlanan bilginin önem derecesini belirtir. Hata günlüğüne + gönderilecek hata türlerinin önem seviyesini belirlemek için LogLevel yönergesi kullanılır. Üçüncü öğe + hatanın üretilmesine sebep olan istemcinin IP adresini içerir. Kalanı + iletinin kendisidir (duruma bakılırsa sunucu istemci erişimini reddetmek + üzere yapılandırılmış). Sunucu istenen belgenin (belge yolunu değil) + dosya sistemindeki yolunu raporlamıştır.

+ +

Hata günlüğünde görünebilecek ileti çeşitliliği oldukça fazladır. Çoğu + yukarıdaki örneğin benzeridir. Hata günlüğü ayrıca, CGI betiklerinin + hata ayıklama çıktılarını da içerir. Bir CGI betiği tarafından standart + hataya (stderr) yazılan her türlü bilgi doğrudan hata + günlüğüne kopyalanır.

+ +

Hata günlüğünü bilgi ekleyerek veya kaldırarak kişiselleştirmek + mümkündür. Bununla birlikte, hata günlüğü girdilerinin ilgili olduğu + isteklerin erişim günlüğünde de girdileri + vardır. Örneğin, yukarıdaki girdi, erişim günlüğünde 403 durum kodlu bir + girdiyle ilgilidir. Erişim günlüğünü de kişiselleştirmek mümkün + olduğundan hata durumlarında bu günlük dosyasını da kullanarak daha + fazla bilgi sağlayabilirsiniz.

+ +

Sunucuyu denerken olası sorunlara karşı hata günlüğünü sürekli + izlemelisiniz. Unix sistemlerinde bunu şöyle bir komutla + sağlayabilirsiniz:

+ +

+ tail -f error_log +

Erişim Günlüğü

İlgili Modüller	İlgili Yönergeler
`mod_log_config` `mod_setenvif`	`CustomLog` `LogFormat` `SetEnvIf`

+ + + + +

Sunucu erişim günlüğü sunucu tarafından işleme alınan tüm istekleri + kaydeder. Erişim günlüğünün yeri ve içeriği CustomLog yönergesi ile belirlenir. + LogFormat yönergesi ile + günlük içeriğini kişiselleştirmek mümkündür. Bu bölümde sunucunun + bilgileri erişim günlüğüne kaydetmesi için nasıl yapılandırılacağından + bahsedilecektir.

+ +

Şüphesiz, bilginin erişim günlüğünde saklanması günlük yönetiminde ilk + adımı oluşturur. Sonraki adım yararlı istatistikleri üretmek için bu + bilgiyi incelemektir. Günlük incelemesi bu belgenin kapsamına dahil + değildir ve aslında bu işlem sunucunun yaptığı işlerden biri değildir. + Bu konu ve günlük incelemesi yapan uygulamalar hakkında daha ayrıntılı + bilgi edinmek için dmoz.org veya Yahoo’ya bakınız.

+ +

Apache httpd’nin çeşitli sürümlerinde erişim günlüklerini denetlemek + için kullanılan diğer modüller ve yönergeler arasında mod_log_referer, + mod_log_agent modülleri ve TransferLog yönergesi + sayılabilir. Artık, daha eski tüm diğer yönergelerin işlevselliklerini + bir araya toplayan CustomLog yönergesi kullanılmaktadır.

+ +

Erişim günlüğünün girdi biçemi kolayca isteğe göre + düzenlenebilmektedir. Biçemi belirtmekte kullanılan biçem dizgesi, C + tarzı printf(1) biçem dizgesini andırır. Sonraki bölümlerde bazı + örneklere yer verilmiştir. Biçem dizgesini oluşturan belirteçlerin tam + listesi için mod_log_config belgesinin Günlük Girdilerinin + Kişiselleştirilmesi bölümüne bakınız.

+ +

Ortak Günlük Biçemi (OGB)

+ + +

Erişim günlüğü için sıklıkla kullanılan bir yapılandırma:

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b" common + CustomLog logs/access_log common +

+ +

İlk satırda belli bir biçem dizgesi için common diye bir + takma ad tanımlanmaktadır. Biçem dizgesi, sunucuya hangi + belli bir bilgi parçalarını günlükleyeceğini söyleyen % imli biçem + belirteçlerinden oluşur. Biçem dizgesine ayrıca dizgesel sabitler de + yerleştirilebilir ve bunlar erişim günlüğüne oldukları gibi + kopyalanırlar. Biçem dizgesi içinde çift tırnak karakteri (") biçem + dizgesini vaktinden önce sonlandırmaması için ters bölü çizgisi ile + öncelenmelidir. Biçem dizgesi ayrıca, satır sonlarını belirtmek için + "\n" ve sekmeleri belirtmek için "\t" + denetim karakterlerini de içerebilir.

+ +

CustomLog yönergesi + evvelce tanımlanmış bir takma adı kullanarak yeni bir günlük + dosyası tanımlar. Erişim günlüğünün dosya ismi bölü çizgisi ile + başlamadıkça dosya yolunun ServerRoot değerine göreli olduğu varsayılır.

+ +

Yukarıdaki yapılandırma günlük dosyasına girdileri Ortak Günlük + Biçemi (Common Log Format) adı verilen standart biçemde yazar. + Bu standart biçem başka HTTP sunucuları tarafından da kullanılır ve + çoğu günlük inceleme yazılımı tarafından tanınır. Ortak Günlük + Biçeminde üretilen günlük girdileri şöyle görünür:

+ +

+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 +

+ +

Bu günlük girdisini parça parça açıklayalım:

+ +

127.0.0.1 (%h): Bu, sunucuya istek yapan istemcinin (uzak konağın) IP adresidir. + Eğer HostnameLookups + yönergesine On değeri atanmışsa sunucu bu IP adresi + için DNS sorgusu yapacak ve IP adresi yerine bulduğu konak ismini + yazmaya çalışacaktır. Bununla birlikte, bu işlem sunucuyu epeyce + yavaşlattığından önerilmemektedir. Konak isimlerini saptamak için en + iyisi günlük girdilerini logresolve gibi bir + günlük işlemcisinden geçirmektir. Burada raporlanan IP adresi + doğrudan istemcinin IP adresi olmayabilir. Eğer sunucu ile istemci + arasında bir vekil sunucu varsa bu IP adresi, vekil sunucunun IP + adresi olacaktır.
- (%l): Çıktıdaki bir "tire" imi istenen bilgi parçasının mevcut olmadığı + anlamına gelir. Bu durumda, mevcut olmayan bilgi istemci makine + üzerinde identd tarafından belirlenen istemcinin RFC + 1413 kimliğidir. Bu bilgi oldukça güvenilmezdir ve sıkıca denetlenen + iç ağlar haricinde hemen hemen asla kullanılmamalıdır. Apache, + IdentityCheck yönergesine + On değeri atanmış olmadıkça bu bilgiyi saptamaya + uğraşmaz.
frank (%u): Bu, belge isteğinde bulunan kişinin HTTP kimlik doğrulamasıyla + saptanan kullanıcı kimliğidir. Bu değer CGI betiklerine + REMOTE_USER ortam değişkeni ile sağlanır. Eğer istek + için durum kodu 401 ise (aşağıya bakınız) henüz kullanıcının kimliği + doğrulanmamış olacağından bu değere güvenilmemelidir. Eğer belge + parola korumalı değilse günlüğün bu kısmı da yukarıdaki gibi + "-" olacaktır.
[10/Oct/2000:13:55:36 -0700] + (%t): İsteğin alındığı tarih ve saat. Biçemi şöyledir: + +
+ [gün/ay/yıl:saat:dakika:saniye dilim] + gün = 2 hane + ay = 3 harf + yıl = 4 hane + saat = 2 hane + dakika = 2 hane + saniye = 2 hane + dilim = (`+' | `-') 4 hane +
+ Günlük biçem dizgesinde zaman gösterim biçemini + %{biçem}t şeklinde belirtmek de mümkündür. + Buradaki biçem dizgesi, stardart C + kütüphanesindeki strftime(3) işlevi için tanımlanmış + biçem belirteçleriyle oluşturulabilir. +
"GET /apache_pb.gif HTTP/1.0" + (\"%r\"): İstemciden alınan istek satırının çift tırnaklar arasında + gösterilmesi istenmiştir. İstek satırı en yararlı bilgi parçalarını + içerir. Birincisi, istemci tarafından kullanılan yöntem + GET’miş. İkinci olarak istemci + /apache_pb.gif dosyasını istemiş ve üçüncü olarak + istemci HTTP/1.0 protokolünü kullanmış. İstek satırının + bazı parçalarını bağımsız olarak da günlüklemek mümkündür. Örneğin, + "%m %U%q %H" dizgesi, yöntem, yol, sorgu dizgesi ve + protokolü kaydedecektir; bu dizge "%r" biçem + belirtecinin tek başına yaptığı işi yapar.
200 (%>s): Bu, sunucunun istemciye gönderdiği durum kodudur. İsteğin + başarıyla yerine getirilip getirilmediğini gösterdiği için bu bilgi + çok değerlidir. Durum kodu 2 ile başlıyorsa istek başarıyla yerine + getirilmiştir, 3 ile başlıyorsa yönlendirilmiştir, 4 ile başlıyorsa + istemci tarafında bir hata oluşmuştur, 5 ile başlıyorsa sunucuda bir + hata oluşmuştur. Olası hata kodlarının tam listesi RFC2616 Hiper + Metin Aktarım Protokolünün 10. bölümünde bulunabilir.
2326 (%b): Son parça istemciye döndürülen nesnenin yanıt başlığı hariç + uzunluğudur. Eğer istemciye bir içerik döndürülmemişse bu değer + "-" olacaktır. Bunun yerine günlüğe "0" + yazdırmak için %B belirtecini kullanınız.

+ + +

Birleşik Günlük Biçemi

+ + +

Sıklıkla kullanılan diğer bir biçem dizgesi Birleşik Günlük Biçemi + (Combined Log Format) olup şöyle kullanılabilir:

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" + \"%{User-agent}i\"" combined + CustomLog log/access_log combined +

+ +

Bu biçem ilaveten 2 alan içermesi dışında Ortak Günlük Biçemi ile + aynıdır. İlave alanların ikisi de %{başlık}i + biçeminde olup buradaki başlık, HTTP isteğindeki + başlık alanlarından biridir. Bu biçemin kullanıldığı bir erişim + günlüğü girdisi şöyle olurdu:

+ +

+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 + "http://www.example.com/start.html" "Mozilla/4.08 [en] + (Win98; I ;Nav)" +

+ +

Ek alanlar:

+ +

"http://www.example.com/start.html" + (\"%{Referer}i\"): HTTP istek başlığı "Referer". İstemcinin raporladığı isteğin + kaynaklandığı URI. (Bu isteğin yapılmasını sağlayan bağlantıyı + içeren URL veya istek bir sayfanın bileşenleri ile ilgiliyse istenen + sayfanın URL’si olabilir.)
"Mozilla/4.08 [en] (Win98; I ;Nav)" + (\"%{User-agent}i\"): Tarayıcı kimliğini içeren HTTP istek başlığı. Bu istemcinin + tarayıcısının raporladığı kendi tanıtım bilgisidir.

+ + +

Çok Sayıda Erişim Günlüğü

+ + +

Yapılandırma dosyasında çok sayıda CustomLog yönergesi kullanarak çok + sayıda erişim günlüğü kolayca oluşturulabilir. Örneğin aşağıdaki + yönergelerle 3 tane erişim günlüğü oluşturulacaktır. İlki temel OGB + bilgisini içerirken diğer ikisi isteğin kaynaklandığı yeri ve tarayıcı + kimliğini içerir. Son iki CustomLog satırı ayrıca, ReferLog ve + AgentLog yönergelerinin etkilerinin nasıl taklit + edileceğini de göstermektedir.

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b" common + CustomLog logs/access_log common + CustomLog logs/referer_log "%{Referer}i -> %U" + CustomLog logs/agent_log "%{User-agent}i" +

+ +

Bu örnek ayrıca, LogFormat yönergesi ile bir takma ad tanımlamanın şart + olmadığını da göstermektedir. Günlük biçemi doğrudan CustomLog yönergesinde + belirtilebilir.

+ + +

Şarta Bağlı Günlükler

+ + +

Bazı durumlarda istemcinin yaptığı isteğe bağlı olarak erişim + günlüğünde belli girdilerin dışlanması gerekebilir. Bu, ortam değişkenleri sayesinde kolayca yerine + getirilebilir. Önce isteğin belli koşulları sağladığını belirten bir + ortam değişkeni ataması yapılır. Bu işlem SetEnvIf yönergesi ile yapılır. + Sonra da, ortam değişkenine bağlı olarak isteklerin günlüğe dahil + edilip edilmeyeceği CustomLog yönergesinin + env= deyimi kullanılarak belirtilir. Bazı örnekler:

+ +

+ # yerel konaktan kaynaklanan istekleri imleyelim + SetEnvIf Remote_Addr "127\.0\.0\.1" kaydetme + # robots.txt dosyası isteklerini imleyelim + SetEnvIf Request_URI "^/robots\.txt$" kaydetme + # Kalanları günlüğe kaydedelim + CustomLog logs/access_log common env=!kaydetme +

+ +

Başka bir örnek olarak, Türkçe belge isteklerini bir dosyaya diğer + dillerdeki istekleri başka bir dosyaya kaydedelim.

+ +

+ SetEnvIf Accept-Language "tr" turkce + CustomLog logs/turkce_log common env=turkce + CustomLog logs/diger_diller_log common env=!turkce +

+ +

Şarta bağlı günlük kaydının çok esnek ve güçlü olabileceğini + göstermiş olsak da günlük içeriğini denetlemenin tek yolu bu değildir. + Günlük dosyaları sunucu etkinliğini eksiksiz olarak kaydedebildikleri + takdirde daha yararlı olurlar. Günlük dosyalarını sonradan işleme tabi + tutarak istenmeyen girdileri kaldırılmış bir kopya almak hem kolay hem + de daha yararlıdır.

+ +

Günlük Çevrimi

+ + +

Yükü ağır sunucularda günlük dosyalarına kaydedilen bilginin miktarı + çok büyük boyutlara ulaşabilir. 10.000 istek içeren bir erişim günlüğü + yaklaşık 1MB yer kaplar. Etkin günlük dosyasını belirli aralıklarla + değiştirmek veya silmek gerekebilir. Apache çalışırken dosyayı sürekli + açık tuttuğu ve yazdığı için bu işlem sunucu çalışırken yapılamaz. Bu + bakımdan, günlük dosyası değiştirildikten veya silindikten sonra yeni + dosyanın açılması için sunucunun yeniden + başlatılması gerekir.

+ +

Nazikçe yeniden başlatmak + suretiyle sunucunun, mevcut ve bekleyen bağlantıları kaybetmeden yeni + günlük dosyalarını açması sağlanabilir. Bununla birlikte, bu işlem + sırasında sunucunun eski isteklere sunumu bitirene kadar eski günlük + dosyalarına yazmaya devam edebilmesi gerekir. Bu bakımdan, yeniden + başlatmanın ardından eski günlük dosyaları üzerinde bir işlem yapmadan + önce biraz beklemek gerekir. Günlük dosyalarını döndürürken kullanılan + senaryolarda genellikle eski günlük dosyaları yer kazanmak için + sıkıştırılırlar:

+ +

+ mv access_log access_log.old + mv error_log error_log.old + apachectl graceful + sleep 600 + gzip access_log.old error_log.old +

+ +

Günlük çevrimi yapmanın başka bir yolu da sonraki bölümde açıklandığı + gibi borulu günlükler kullanmaktır.

Borulu Günlükler

+ + +

Apache httpd hata ve erişim günlüklerini doğrudan bir dosyaya yazmak + yerine bir boru üzerinden başka bir sürece yazabilir. Bu yetenek ana + sunucuya herhangi bir kod eklemeksizin günlükleme esnekliğini şaşırtıcı + derecede arttırır. Günlükler boruya yazılmak istenirse dosya ismini boru + karakteriyle ("|") değiştirip ardına günlük girdilerini + standart girdisinden kabul edecek programın ismini eklemek yeterlidir. + Apache sunucusu başlatıldığı zaman borulu günlük işlemini de + başlatacaktır. Eğer sunucu çalışırken günlükleri kabul eden süreç + çökerse Apache bu programı yeniden başlatır. (Bu son özelliği sebebiyle + bu tekniğe “güvenilir borulu günlükleme” adını veriyoruz.)

+ +

Borulu günlük süreçleri ana Apache httpd süreci tarafından başlatılır + ve bu süreçler ana Apache httpd sürecinin kullanıcı kimliğini miras + alırlar. Yani borulu günlükleme programları aslında root tarafından + çalıştırılmış gibi olur. Bu bakımdan, bu programları basit ve güvenilir + kılmak çok önemlidir.

+ +

Borulu günlüklerin önemli kullanım alanlarından biri de sunucuyu + yeniden başlatmak gerekmeksizin günlük çevrimini mümkün kılmaktır. + Apache HTTP sunucusu bu amaçla kullanılmak üzere + rotatelogs diye bir program içerir. Örneğin, + günlükleri 24 saatte bir döndürmek isterseniz bunu şöyle + yapabilirsiniz:

+ +

+ CustomLog "|/usr/local/apache/bin/rotatelogs + /var/log/access_log 86400" common +

+ +

Borunun diğer ucundaki süreci başlatacak komutun tırnak içine + alındığına dikkat ediniz. Bu örnekler erişim günlüğü için verilmişse de + aynı teknik hata günlüğü için de kullanılabilir.

+ +

Hariçten bir uygulama olarak cronolog isminde buna benzer ancak + çok daha esnek bir program daha vardır.

+ +

Borulu günlükler de şarta bağlı günlükleme kadar güçlü olmakla beraber + çevrimdışı ardıl işlemler gibi daha basit çözümler için + kullanılmamalıdır.

Sanal Konaklar

+ + +

Bir sunucu çok sayıda sanal konak ile hizmet + sunarken bunların günlük kayıtları için çeşitli seçenekler mevcuttur. + İlk seçenekte, sanki sunucu tek bir konakla hizmet sunuyormuş gibi + günlük kaydı yapılır. Günlükleme yönergelerini <VirtualHost> bölümlerinin dışına, ana sunucu + bağlamına yerleştirerek tüm isteklerin aynı erişim ve hata günlüğüne + yazılmasını sağlamak olasıdır. Bu teknik, tek tek sanal konaklar için + kolayca istatistik toplamaya izin vermez.

+ +

Eğer CustomLog + veya ErrorLog yönergesi bir + <VirtualHost> bölümüne + yerleştirilirse bu sanal konağa bütün erişimler veya hatalar belirtilen + dosyaya günlüklenecektir. Böyle günlükleme yönergeleri içermeyen sanal + konakların günlükleri hala ana sunucunun hata ve erişim günlüklerine + yazılmaya devam edecektir. Bu teknik az sayıda sanal konak barındıran + sunucular için çok kullanışlıdır. Fakat sanal konak sayısı çok fazlaysa + bu teknikle günlük dosyalarını yönetmek çok karmaşık bir hal alabilir. + Ayrıca, yetersiz dosya tanıtıcısı + sorunlarıyla çok sık karşılaşılabilir.

+ +

Erişim günlükleri için çok az bir fedakarlıkla çok iyi bir çözüm vardır. + Günlük biçemine sanal konaklarla ilgili bilgi eklemek suretiyle tüm + konakların aynı günlük dosyasını kullanmaları olasıdır. Böylece günlük + dosyası sonradan her sanal konak için ayrı bir dosya oluşturmak üzere + ayrıştırılabilir. Örneğin, bu işlem için şu yönergeler kullanılıyor + olsun:

+ +

+ LogFormat "%v %l %u %t \"%r\" %>s %b" + ortaksankon + CustomLog logs/access_log ortaksankon +

+ +

%v belirteci isteği sunan sanal konağın ismini günlüğe + yazmak için kullanılır. Daha sonra split-logfile gibi bir program + kullanarak, bu dosyadan her sanal konak için ayrı birer dosya elde + edilebilir.

Diğer Günlük Dosyaları

İlgili Modüller	İlgili Yönergeler
`mod_cgi` `mod_rewrite`	`PidFile` `RewriteLog` `RewriteLogLevel` `ScriptLog` `ScriptLogBuffer` `ScriptLogLength`

+ + + + +

PID Dosyası

+ + +

Apache httpd başlatıldığında, ana httpd sürecinin kimliği (PID) + logs/httpd.pid dosyasına kaydedilir. Bu dosyanın ismi + PidFile yönergesi ile + değiştirilebilir. Bu süreç kimliği sistem yöneticisi tarafından ana + sürece sinyal göndererek artalan sürecini sonlandırmak veya yeniden + başlatmak için kullanılır. Windows üzerinde bu işlem için + -k komut satırı seçeneği kullanılır. Bu konuda daha + ayrıntılı bilgi edinmek için Durdurma ve + Yeniden Başlatma belgesine bakınız.

+ + +

Betik Günlüğü

+ + +

ScriptLog yönergesi CGI + betiklerinin girdi ve çıktılarını kaydetmenizi mümkün kılmak suretiyle + hata ayıklamaya yardımcı olur. Bu sadece deneysel amaçla kullanılmalı, + asıl sunucuya uygulanmamalıdır. mod_cgi + belgesinde daha fazla bilgi bulunabilir.

+ + +

Yeniden Yazım Günlüğü

+ + +

Güçlü ve karmaşık mod_rewrite + özellikleri kullanılırken, hata ayıklamaya yardımcı olmak için + RewriteLog yönergesini + kullanmak gerekebilir. Yönerge, günlük dosyasında yeniden yazım + motorunun istekleri nasıl dönüştürdüğüyle ilgili ayrıntılı bir döküm + üretir. Ayrıntı seviyesi RewriteLogLevel yönergesi ile belirlenir.

+ +