Asp Güncesi

Asp Güncesi

1.      ASP’yi Anlama

1.1.   İnternet protokollerine bakış ve HTTP

İlerideki bölümler, sunucu taraflı programlama dillerinden ASP’yi (Active Server Pages) ayrıntılı olarak anlatmak üzere hazırlanmıştır. Fakat burada şu soru olabilir : Bir sunucu taraflı programlama dili tam olarak nedir ?

 

Sunucu taraflı programlamanın ne demek olduğunu anlamak için isterseniz ilk önce client taraflı (istemci taraflı) programlama dillerinden HTML dilinin çalışma prensibine bakalım.

 

HTTP (HyperText Transfer Protokol), web üstünde bilgi dağıtımı için kullanılan temel protokoldür. HTTP, dosyaların kolaylıkla transfer edilebilmesi için oldukça etkin ve hızlıdır. HTTP diğer web teknolojileri ile birlikte gelişmektedir. HTTP’nin temel özellikleri HTTP 0.9 da bulunmaktadır. HTTP’nin 0.9 sürümünde birçok eksikler bulunuyordu. Bunlardan başlıcaları içerik tiplemesine (content typing) izin vermemesi ile istek ve cevapların sağlanmasında meta-bilgilerin kullanılması için koşullar olmamasıdır.

 

HTTP/0.9 un eksikliklerini gidermek için HTTP’nin şu anda kullandığımız sürümü olan HTTP/1.0 geliştirilmiştir. Bu sayede Content-Type (içerik tipi) alanı bulunan başlıklara ve diğer tipte meta bilgilerine izin verilmiştir. Aktarılan verinin tipi Content-Type alanında tanımlanır. Ayrıca dil, verinin kodlanma tipi ve durum bilgisi gibi veri hakkında başka bilgiler de sağlayabilirsiniz.

 

Çoğu web kullanıcısı ve yayımcısının HTTP’de istediği özelliklerden biri de güvenliktir. Web yayımcıları ve kullanıcıları güvenli olarak işlemleri (transaction) iletebilmeyi istemektedir. Elektronik ticaretin yaygın olarak kullanımını sağlamak için güvenlikle ilgili anahtar nokta, işlemlerin güvenliğini sağlayabilme ve kodlayabilmektir. Şu anda HTTP’nin güvenlik özellikli sürümleri için çeşitli taslaklar bulunmaktadır. Bu özelliklerden birisi kabul gördüğünde HTTP kullanan güvenlikli işlemler bir hayal olmaktan çıkacaktır.

1.1.1.      Bağlantısız protokoller ve bağlantılı protokoller.

HTTP etkin bir protokoldür çünkü hızlı, rahat ve ayrıca yeteneklidir. Bu hız, yeteneklilik ve kuvvetliliği sağlayabilmek için HTTP, bağlantısız (connectionless) ve durumu olmayan (stateless) bir protokol olarak tanımlanmıştır.

 

HTTP bağlantısız bir protokoldür. Bağlantısız protokoller, bağlantı temelli protokollerden isteklere verilen cevap karşılıklar noktasında ayrılırlar. Bağlantısız bir protokolde istemci sunucuya bağlanır, bir istekte bulunur, cevap alır ve ardından diğer isteklere hizmet vermek için bağlantıyı keser.

 

Bağlantı temelli bir protokol örneği FTP’dir. Bir FTP sunucusuna bağlanıldığında dosya aktarımı bittikten sonra bile bağlantı devam eder. Bu bağlantının korunabilmesi için sistem kaynakları gerekir. Yani çok sayıda açık bağlantı tutmak sunucunun kolaylıkla çökmesine sebep olabilir. Sonuç olarak FTP sunucularının çoğu belirli bir anda en fazla 250 açık bağlantıya izin verecek şekilde ayarlanmaktadır. Bunun anlamı FTP sunucusuna aynı anda en fazla 250 kullanıcı bağlanarak işlem yapabileceğidir (bu özellik çeşitli FTP sunucularında değişiklik göstermektedir). Bu sorunla beraber doğru sonlandırılmayan bağlantılarda problemler yaratabilmektedir. Bu tip protokollerde işlemler kontrolden çıkarak sunucunun çökmesi gibi istenmeyen sonuçlar görülmektedir.

 

Tersine HTTP bağlantısız bir protokoldür. İstemciler sunucuya bağlanır bağlandıklarında istekte bulunur, cevabını alır ve ardında bağlantıyı keser. Bağlantı devamlı korunmadığı için işlemler tamamlanırken hiçbir sistem kaynağı meşgul edilmez. Sonuç olarak HTTP sunucuları sadece aktif bağlantılarla sınırlıdır ve az bir sistem yükü ile binlerce işleme olanak tanımaktadır. Bağlantısız protokollerin dezavantajı ise aynı istemci bir daha bilgi isteğinide bulunduğunda bağlantının yeniden kurulması gereğidir. İstemci browserlar bu yükü en aza indirebilmek için alınan verileri saklayarak yine aynı veri istendiğinde kullanan sistemler geliştirmişlerdir.

1.1.2.      Durumu olmayan protokoller ve durumu olan protokoller.

HTTP durumu olmayan (stateless) bir protokoldür. Durumu olamayan protokoller durumlu protokollerden isteklerle ilgili bilgilerin tutuluş şeklinde farklılık gösterirler. Durumu olmayan protokollerde işlem işlendikten sonra işlem hakkında bilgi saklanmaz. Durumlu protokollerde ise işlem işlendikten sonra durum bilgisi saklanır.

 

Durumlu protokol kullanan sunucular işlemlerle ilgili bağlantının durumu, çalışmakta olan işler, bu işlerin durumu vs. gibi bilgileri tutar. Genel olarak bu durum bilgisi bellekte kalır ve sistem kaynaklarını kullanır. İstemci durumlu bir protokol kullanan sunucu ile bağlantısını kestiğinde bu durum bilgisi silinmeli ve oturum sonlanmalıdır.

 

Durumu olamaya protokoller küçük hacimlidir. Bu protokolleri kullanan sunucular tamamlanmış işlemler ve işler hakkında hiçbir bilgi tutmazlar. Bir istemci durumu olmayan protokol kullanan sunucu ile olan bağlantısını kestiğinde hiçbir verinin silinmesine ya da oturumun sonlandırılmasına gerek kalmaz. Durum bilgisinin kaydının tutulmaması sayesinde sunucu üzerine daha az yük biner ve sunucular işlemleri hızlı bir şekilde işleyebilirler. Web yayımcıları için bu protokolün dezavantajı ise eğer web dokümanları için durum bilgisinin tutulmasını istiyorsanız bunun doküman başlığında meta-bilgi şeklinde belirtilmesinin gerektiğidir.

1.2.   HTML nedir ?

Tim Berners-Lee webi tasarlarken herkesin webde yayımcılık yapmasına olanak sağlayacak kadar genel ve kullanımı kolay bir arabirimi olacak şekilde tasarladı. Cern’deki çalışanlarla beraber HTML dilini geliştirdiler. HTML dili SGML’nin (Standart Genelleştirilmiş Anlamlandırma Dili) bir alt kümesi olarak tasarlanmıştır. HTML için SGML’nin temel alınması web için geliştirilen dilin platformlar arası bir çözüm olarak kendini kanıtlamış sağlam bir standartta kök salmasına sebep olmuştur.

 

HTML dili oluşturulurken SGML’den sadece gerekli olan alanlar alınmıştır. Bu şekilde HTML’in karışıklığı ve dokümanların network üzerinden transferi için harcanan kaynakların miktarı bir hayli azalmıştır. HTML için SGML’nin baz alınmasının bir diğer avantajı ise doküman tanım tiplerinin (DTD) HTML standartlarını genişletmek için kolaylık sağlamasıdır. Sonuçta HTML’I geliştirenlerin amacı zaman içinde geliştirilebilen basit bir dil yazmaktı.

 

HTML dilinin işletilme prensibi bir hayli basittir; Kullanıcı gözatıcısından (web browser) bir url girdiği zaman (URL hakkında daha fazla bilgi için
EK-1 : URL’ler Hakkında Ayrıntılı Bilgi 

İlerideki bölümler, sunucu taraflı programlama dillerinden ASP’yi (Active Server Pages) ayrıntılı olarak anlatmak üzere hazırlanmıştır. Fakat burada şu soru olabilir : Bir sunucu taraflı programlama dili tam olarak nedir ?

 

Sunucu taraflı programlamanın ne demek olduğunu anlamak için isterseniz ilk önce client taraflı (istemci taraflı) programlama dillerinden HTML dilinin çalışma prensibine bakalım.

 

HTTP (HyperText Transfer Protokol), web üstünde bilgi dağıtımı için kullanılan temel protokoldür. HTTP, dosyaların kolaylıkla transfer edilebilmesi için oldukça etkin ve hızlıdır. HTTP diğer web teknolojileri ile birlikte gelişmektedir. HTTP’nin temel özellikleri HTTP 0.9 da bulunmaktadır. HTTP’nin 0.9 sürümünde birçok eksikler bulunuyordu. Bunlardan başlıcaları içerik tiplemesine (content typing) izin vermemesi ile istek ve cevapların sağlanmasında meta-bilgilerin kullanılması için koşullar olmamasıdır.

 

HTTP/0.9 un eksikliklerini gidermek için HTTP’nin şu anda kullandığımız sürümü olan HTTP/1.0 geliştirilmiştir. Bu sayede Content-Type (içerik tipi) alanı bulunan başlıklara ve diğer tipte meta bilgilerine izin verilmiştir. Aktarılan verinin tipi Content-Type alanında tanımlanır. Ayrıca dil, verinin kodlanma tipi ve durum bilgisi gibi veri hakkında başka bilgiler de sağlayabilirsiniz.

 

Çoğu web kullanıcısı ve yayımcısının HTTP’de istediği özelliklerden biri de güvenliktir. Web yayımcıları ve kullanıcıları güvenli olarak işlemleri (transaction) iletebilmeyi istemektedir. Elektronik ticaretin yaygın olarak kullanımını sağlamak için güvenlikle ilgili anahtar nokta, işlemlerin güvenliğini sağlayabilme ve kodlayabilmektir. Şu anda HTTP’nin güvenlik özellikli sürümleri için çeşitli taslaklar bulunmaktadır. Bu özelliklerden birisi kabul gördüğünde HTTP kullanan güvenlikli işlemler bir hayal olmaktan çıkacaktır.

 

HTTP etkin bir protokoldür çünkü hızlı, rahat ve ayrıca yeteneklidir. Bu hız, yeteneklilik ve kuvvetliliği sağlayabilmek için HTTP, bağlantısız (connectionless) ve durumu olmayan (stateless) bir protokol olarak tanımlanmıştır.

 

HTTP bağlantısız bir protokoldür. Bağlantısız protokoller, bağlantı temelli protokollerden isteklere verilen cevap karşılıklar noktasında ayrılırlar. Bağlantısız bir protokolde istemci sunucuya bağlanır, bir istekte bulunur, cevap alır ve ardından diğer isteklere hizmet vermek için bağlantıyı keser.

 

Bağlantı temelli bir protokol örneği FTP’dir. Bir FTP sunucusuna bağlanıldığında dosya aktarımı bittikten sonra bile bağlantı devam eder. Bu bağlantının korunabilmesi için sistem kaynakları gerekir. Yani çok sayıda açık bağlantı tutmak sunucunun kolaylıkla çökmesine sebep olabilir. Sonuç olarak FTP sunucularının çoğu belirli bir anda en fazla 250 açık bağlantıya izin verecek şekilde ayarlanmaktadır. Bunun anlamı FTP sunucusuna aynı anda en fazla 250 kullanıcı bağlanarak işlem yapabileceğidir (bu özellik çeşitli FTP sunucularında değişiklik göstermektedir). Bu sorunla beraber doğru sonlandırılmayan bağlantılarda problemler yaratabilmektedir. Bu tip protokollerde işlemler kontrolden çıkarak sunucunun çökmesi gibi istenmeyen sonuçlar görülmektedir.

 

Tersine HTTP bağlantısız bir protokoldür. İstemciler sunucuya bağlanır bağlandıklarında istekte bulunur, cevabını alır ve ardında bağlantıyı keser. Bağlantı devamlı korunmadığı için işlemler tamamlanırken hiçbir sistem kaynağı meşgul edilmez. Sonuç olarak HTTP sunucuları sadece aktif bağlantılarla sınırlıdır ve az bir sistem yükü ile binlerce işleme olanak tanımaktadır. Bağlantısız protokollerin dezavantajı ise aynı istemci bir daha bilgi isteğinide bulunduğunda bağlantının yeniden kurulması gereğidir. İstemci browserlar bu yükü en aza indirebilmek için alınan verileri saklayarak yine aynı veri istendiğinde kullanan sistemler geliştirmişlerdir.

 

HTTP durumu olmayan (stateless) bir protokoldür. Durumu olamayan protokoller durumlu protokollerden isteklerle ilgili bilgilerin tutuluş şeklinde farklılık gösterirler. Durumu olmayan protokollerde işlem işlendikten sonra işlem hakkında bilgi saklanmaz. Durumlu protokollerde ise işlem işlendikten sonra durum bilgisi saklanır.

 

Durumlu protokol kullanan sunucular işlemlerle ilgili bağlantının durumu, çalışmakta olan işler, bu işlerin durumu vs. gibi bilgileri tutar. Genel olarak bu durum bilgisi bellekte kalır ve sistem kaynaklarını kullanır. İstemci durumlu bir protokol kullanan sunucu ile bağlantısını kestiğinde bu durum bilgisi silinmeli ve oturum sonlanmalıdır.

 

Durumu olamaya protokoller küçük hacimlidir. Bu protokolleri kullanan sunucular tamamlanmış işlemler ve işler hakkında hiçbir bilgi tutmazlar. Bir istemci durumu olmayan protokol kullanan sunucu ile olan bağlantısını kestiğinde hiçbir verinin silinmesine ya da oturumun sonlandırılmasına gerek kalmaz. Durum bilgisinin kaydının tutulmaması sayesinde sunucu üzerine daha az yük biner ve sunucular işlemleri hızlı bir şekilde işleyebilirler. Web yayımcıları için bu protokolün dezavantajı ise eğer web dokümanları için durum bilgisinin tutulmasını istiyorsanız bunun doküman başlığında meta-bilgi şeklinde belirtilmesinin gerektiğidir.

 

Tim Berners-Lee webi tasarlarken herkesin webde yayımcılık yapmasına olanak sağlayacak kadar genel ve kullanımı kolay bir arabirimi olacak şekilde tasarladı. Cern’deki çalışanlarla beraber HTML dilini geliştirdiler. HTML dili SGML’nin (Standart Genelleştirilmiş Anlamlandırma Dili) bir alt kümesi olarak tasarlanmıştır. HTML için SGML’nin temel alınması web için geliştirilen dilin platformlar arası bir çözüm olarak kendini kanıtlamış sağlam bir standartta kök salmasına sebep olmuştur.

 

HTML dili oluşturulurken SGML’den sadece gerekli olan alanlar alınmıştır. Bu şekilde HTML’in karışıklığı ve dokümanların network üzerinden transferi için harcanan kaynakların miktarı bir hayli azalmıştır. HTML için SGML’nin baz alınmasının bir diğer avantajı ise doküman tanım tiplerinin (DTD) HTML standartlarını genişletmek için kolaylık sağlamasıdır. Sonuçta HTML’I geliştirenlerin amacı zaman içinde geliştirilebilen basit bir dil yazmaktı.

 

HTML dilinin işletilme prensibi bir hayli basittir; Kullanıcı gözatıcısından (web browser) bir url girdiği zaman (URL hakkında daha fazla bilgi için  

1.1.   ASP’nin Doğuşu

HTML in gelişmesi ile birlikte kullanıcılara web sayfalarına bilgi girebilmelerine olanak tanında (<input> elementi yardımı ile). Bu şekilde bir çok uygulama geliştirildi çünkü artık kullanıcı da sunucuya bilgi gönderebiliyordu. Fakat çoğu uygulamada bu kullanıcıdan gelen bilgilerin anında işlenmesi ve yeniden bir text bazlı HTML dokümanı hanine getirilmesi gerekiyordu. Bu ise hiç hızlı bir yöntem değildi.

 

Bu zorluğu aşmak isteyen geliştiriciler kolları sıvayarak CGI (Common Gateway Interface) arabirimini geliştirmeye başladılar. Bu arabirimi standart haline getirdiler ve tamamen “C” dili üzerine kurdular. “Cgi-bin” dizini de bu şekilde doğmuştur (“bin” terimi derlenmiş “C” kodu olmasından dolayı “binary code” anlamında eklenmiştir). İlk uygulamalar derlenmiş ufak programcıklar halinde olmuştu.  Fakat bu haliyle bile kullanışlı değildi çünkü dosya içinde yapılacak en ufak değişiklikte bile yeniden derlenmesi gerekmekteydi. Buda CGI’ın kullanımını olumsu yönde etkiliyordu.

 

Bu kısıtlamaları kendine sınır olarak görmeyen geliştiriciler yeni bir script dili geliştirdiler. Bu dil “Practical Extraction and Reporting Language” yani PERL adını aldı. Bu dil sunucu ile iletişim halinde olan ilk dildi yani “C veya C++” dilleri ile yazılan scriptin her seferinde derlenmesi derdi ortandan kaldırılmış oldu.

 

Perl hala popüler bir dil olarak çoğu uygulamada  özellikle de Unix ve Linux tabanlı sistemlerde kullanılmaktadır.

1.1.1.      Server-Tabanlı Script Teknolojileri

 Şimdiye kadar anlattığım CGI dilleri web sunucusu üzerine bir yama yapmadan yada ekstra bir program yüklemeden çalışmamaktadır. Bu programlar kullanıcıdan gelen isteği algılar ve isteğe göre dosyayı okur daha sonra onu sunucu içinde işler ve bir çıkış dosyası oluşturarak kullanıcıya sunarlar.

 

Perl ilk popüler sunucu-tabanlı uygulama geliştirme dili olarak literatüre geçmiştir. Fakat bu dil çok fazla gelişim geçirmiştir. Özellikle de Unix ve Linux tabanlı sunucularda yeni nesil programlama dili olan PHP (Personal Home Page) ye yerini bırakmıştır.

 

Microsoft firması web sunucu sektöründeki en önemli atılımını “Windows NT 3.51” ve bu işletim sistemine entegre halde olan “Internet Information Server 1.0” (IIS)  sayesinde yapmıştır. Bu yazılım geçmişe dönük olarak CGI desteklemekle (her şekilde C ve C++ dili ile geliştirilmiş uygulamaları) birlikte yeni bir arabirim içeriyordu.

 

Bu arabirime “Internet Server Aplication Programing Interface” yani ISAPI adı verilmiştir. Bu arabirim sayesinde web sunucu perl dilinin tüm esnekliği standart hale getirilmiş oldu. Bu atılımla birlikte tüm yazılım geliştiriciler ISAPI ile uyumlu olan yazılımlar geliştirmeye başladılar.

 

Microsoft ISAPI ile beraber yeni teknoloji olan ASP’yi duyurdu. ASP teknolojisi IIS ile ISAPI sayesinde bağlanmış oldu. ASP den önce en çok  “Internet Database Connector” (IDC) kullanılmaktaydı.

 

Aşağıdaki diyagramda (Diyagram 1 : Microsoft Sunucu Yapısı.) Microsoft server yapısı ayrıntılı olarak anlatılmıştır.

 

 

 

Diyagram 1 : Microsoft Sunucu Yapısı.

1.1.2.      ASP ile IIS ilişkisi

ASP sadece kendisi için yazılmış olan DLL i kullanır (asp.dll). Bu dosya standart olarak web sunucu da yer almaktadır (sadece IIS 1.0 sonrası) (Winnt\System32\ inetsrv dizininde yer almaktadır). Bu DLL sadece ASP dosyalarını (genellikle .ASP uzantılıdırlar) okuyup içerisindeki script komutlarını işlemek ve sonuçlarını HTML ve metin içeriği ile birlikte Web gözatıcısına yollamak görevini üstlenir.

1.1.3.      IIS Uygulama Yapıları

IIS içerisindeki işlemleri daha iyi anlayabilmek için uygulama yapılarının Windows içinde nasıl çalıştığını anlamalıyız. Web sunucudaki (IIS) her web sitesinin sunucu üzerinde yer alan bir kök dizini vardır. Varsayılan (Default) web sitesi otomatik olarak “c:\inetpub\wwwroot” dizinini kendine kök dizini atar (değiştirilebilir). Her yeni açılacak web sitesi için bir kök dizini belirlenmesi zorunludur. Sunucu üzerindeki web sitelerini görmek için IIS yönetim arabirimi olan “Internet Service Manager” programı kullanılır.

 

 

Resim 1 : Microsoft Internet Service Manager.

 

IIS üzerinden default web sitesine sağ tıklayıp özellikler seçeneğini seçtiğimiz zaman, açılacak olan “default web site özellikleri” ekranından “home directory” tabına tıklanır. Gelecek olan sekmeden “configration” butonuna basarak uzantılar ile ilişkilendirilen arabirimler görülebilir (ISAPI yapısı “Diyagram 1 : Microsoft Sunucu Yapısı.” de görüldüğü gibidir).

 

 

Resim 2 : ISAPI Yapısı.

 

Resimden de (Resim 2 : ISAPI Yapısı.) görülebileceği gibi asp uzantılı dosyalar asp.dll dosyası ile derlenmektedir. HTM ve HTML uzantılı html sayfaları ve XML uzantılı xml sayfaları direkt olarak diskten okunup (web sunucu tarafından) istemciye gönderilmektedir ama asp uzantılı dosyalar ISAPI yardımı ile asp.dll tarafından okunup derlenip sonuç çıktıları istemciye göderilmektedir.

 

Not : İstemci sunucudan url yardımı ile bir dosya isteğinde bulunduğu zaman istek paketi şu şekilde olacaktır:

 

11/11/02 02:49:16 Sent  GET /deneme/ornek.asp HTTP/1.1

Accept: aplication/msword, application/vnd.ms-excel, application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-comet, */*

Accept-Language: en-us

Encoding: gzip, deflate

Referer: http://www.akkoyun.net/kitap.asp

Cookie: VisitCount=2&LastDate=6%2F4%2F99

User-Agent: Mozilla/4.0 (compatible; MSIR 6.0; Windows XP)

Host: 212.98.198.111

Connection: Keep-Alive

 

Ve bu isteği takiben sunucu istemciye dosyayı gönderirken şu başlık kısmı ile beraber gönderecektir :

 

11/11/02 02:49:16 Recived HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

Connection: Keep-Alive

Date: Thu, 11 Nov 2002 10:22:21 GMT

Content-Type: text/html

Accept-Ranges: bytes

Content-Lenght: 2946

Last-Modified: Thu, 11 Nov 2002 10:22:21 GMT

Cookie: VisitCount=2&LastDate=6%2F4%2F99

<HTML>

–Sayfanın geri kalanı

 

Bu bilgileri dikkatli olarak incelemenizi istiyorum çünkü ilerideki konularımızda bu sunucu ve istemci değişkenlerini okutmak ve değiştirmek üzerine konular göreceğiz.

1.1.4.      ASP dosyalarının işletilmesi

Asp uzantılı dosyaların “asp.dll” yardımı ile derlendiğini bilmekteyiz peki ya bu derlenme nasıl olmaktadır.

 

Birinci basamak olarak asp dosyası içerisinde server taraflı kod olup olmadığı denetlenir. Eğer dosya içerisinde sunucu taraflı işletilecek bir kod bulunmaz ise IIS tarafından direkt istemciye gönderilir. Bu “Windows 2000” de yeni bir özellik olarak eklenmiştir. Bu sayede “.asp” uzantılı dosyaları kullanmamıza olanak tanır (içerisinde sunucu taraflı çalışacak kod bulunmayan dosyalara bile “.asp” uzantısı verilebilmektedir).

 

Eğer DLL, içerisinde server taraflı çalışacak bir kod olan dosya ile karşılaşırsa; satır satır bu dosyayı işleterek script blokları içerisindeki komutları işletir ve çıktısını yine aynı yere gelecek şekilde bir çıkış dosyasına (hafızada bulunan bir tampon bölgeye) kaydeder. İçerisinde script komutu olmayan kısımlarda aynen değiştirilmeden tampona yazılır. Tüm bu işlemler tamamlandıktan sonra eğer herhangi bir hata oluşmamış ise bu dosya (tamponda tutulan) istemci bilgisayarına gönderilerek işlem tamamlanır. Bu gönderme işlemi sonucunda tampon bölge temizlenir.

 

 

Diyagram 2 : ASP Dosyalarının İşletilmesi ve İstemciye Gönderilmesi.

 

Bilgi : IIS in ilk versiyonlarında ASP komutlarımızı işletecek olan ASP.DLL , asp dosyalarını satır satır okuyup satır satır işleyip yine satır satır çıktı alırdı. Buda performansta ciddi bir düşme meydana getirirdi.

Dinamik sunucu sayfalarının oluşturulması sırasında kullanılacak olan sistem kaynakları aşağıdaki grafikte resmedilmiştir.

 

 

Resim 3 : Sistem Kaynakları Kullanımı.

 

Asp script motoru (asp.dll) dosya içerisinde sunucu taraflı çalışacak kod olup olmadığını iki şekilde anlar.

 

Bilgi : Bazılarınızın bildiği gibi ASP’de FSO (File System Object) kullanarak yazılmış ve sunucudaki diğer dosyalara erişebilen bir script piyasada dolaşmaktadır. Çoğu programcının düşüncesinin aksine bu bir açık (güvenlik deliği) değildir. Bu script sunucu yöneticilerinin yaptığı yanlış veya yetersiz yetkilendirme sonucu kendi yetkisi dışındaki dosyalara da erişebilmektedir. Bu yanlış yetkilendirmeyi isterseniz adım adım düzeltelim.

 

Öncelikle web sunucunuzun “root” klasörüne (tüm web sitesi dosyalarının bulunduğu sanal olarak en üst dizin anlamında), bir klasör oluşturunuz. Örneğin bu klasörün ismi “guvenli” olsun. Daha sonra “Computer Management” dan “Local Users and Groups” a tıklayınız. Gelen menüden “Users” seçeneğini seçtiğiniz zaman sağdaki pencerede bilgisayarda kayıtlı tüm kullanıcıların listesi gelecektir. Listenin boş bir yerine sağ tıklayarak “new user” seçeneği ile yeni bir kullanıcı oluşturalım. Daha sonra tekrar “Computer Management” penceresinden “Services and Application” kısmına buradan da “IIS” sekmesine tıklayalım. Buradan “Default Web Site” sekmesini işaretleyelim. Sağ tarafta web sayfanız içerisindeki tüm klasörler gözükecektir (tabi ki bizim oluşturduğumuz “guvenli” klasörü de gözükecek) buradan oluşturduğumuz “guvenli” klasörüne sağ tıklayarak “Properties” seçeneğini seçiyoruz. Açılan penceredeki “Directory > Application Settings” bölümündeki “create” düğmesine tıklayınız. Bu seçili olan klasör için ayrı bir uygulama yaratacaktır. Artık bu klasöre yetkili bir kullanıcı seçebiliriz ayrıca bu kullanıcının “IUSER” (İnternet user) olması da gerekmiyor. “Directory Security>Anonymous access and auth.. control” bölümündeki “Edit” düğmesine tıklayın. Buradan açılacak pencereden “Anonymous access” bölümündeki “Edit” düğmesine tıklayın. “Browse” düğmesine tıklayarak önceden yarattığınız user’ı seçiniz. “Allow IIS to control password” seçeneğini aktif hale getirip her şeye OK deyip çıkınız. Şimdi “c:\inetpub\……” yada her neyse. Yarattığınız “guvenli” klasörünü bulunuz. Klasöre sağ tıklayarak “properties” seçeneğini seçiniz. “Security” yi seçip buradaki tüm userları siliniz. Sadece Administrator ve yarattığınız user’ı ekleyin. Eğer bu klasörde dosya yaratma izni verecekseniz kendi user’ınıza “modify,write veya full control” verebilirsiniz. Ok deyip buradan da çıkınız.

 

Evet artık “http://127.0.0.1/guvenli” klasörünün içinden FSO ile değil c:\ ye bir üst klasöre bile çıkamazsınız. Bir üst klasördeki “txt” dosyalarını bile okuyamazsınız.

 

1.1.4.1.            <% ve %> kullanarak

En çok kullanılan yöntem olup script bloğu başlangıcına “<%” ve script bloğu bitişine “%>” yazılarak arasında kalan kısma sunucu taraflı kod yazılır (Örnek 1 : <% %> Kullanmak.).

 

<HTML>

   <Body>

   Bu bir HTML metinidir

     <%

       Rem burasi script bloğudur

     %>

   </Body>

</HTML>

Örnek 1 : <% %> Kullanmak.

1.1.4.2.            <script> elementini kullanarak

Nadir olarak kullanılan bu yöntem ile sunucu taraflı kodun yer aldığı script bloğunu <script> elementi ile açıp </script> elementi ile bitirilmesi baz alınmıştır. Bu şekilde ki kullanımda element içerisine yazılacak olan “Runat” özelliği sayesinde istemci veya sunucu taraflı çalışma özelliği eklenmiştir (Örnek 2 : <script> Elementi Kullanmak.).

 

<HTML>

   <Body>

   Bu bir HTML metinidir

     <script runat=”server”>

       Rem burasi script bloğudur

     </script>

   </Body>

</HTML>

Örnek 2 : <script> Elementi Kullanmak.

 

Bunun yanında “Script” elementi kullanılarak sunucu üzerinde yer alan bir dosya script bloğu içerisine dahil edilebilir. Bu şekilde tüm sayfalarda kullanılan ortak kodlar bir defaya mahsus olmak üzere yazılır ve bu kodlar gereken yerlere dahil ettirilir. Bunu şu şekilde yapabilmekteyiz (Örnek 3 : Harici Kod Kullanımı.).

 

<HTML>

   <Body>

      <script runat=”server” src=”/script.inc”></script>

   </Body>

</HTML>

Örnek 3 : Harici Kod Kullanımı.

 

Bilgi : Server Side Includes (SSI[i]) kullanarak harici dosyaları da asp dosyamız içerisine dahil edebiliriz. Böylece script blokları içerisinde yer alan kodları harici dosyalarda saklayabilmekteyiz. Bu konuyu ilerideki konularımızda ayrıntılı olarak ele alacağız.

 

Yukarıda anlatılan yöntemle yapılan bir uygulamada içeriği dahil edilen “script.inc” dosyasının içerisinde mutlaka geçerli bir script olmalıdır. Bu script metin (text) yada HTML olmamalıdır. Script elementinin içerisine (açılış ve kapanış tagları arasına) kesinlikle başka bir kod gelmemesi gerekmektedir.

1.1.5.      Özel ASP Komutları

1.1.5.1.            Script Dilini Belirlemek

IIS standart olarak iki script motoru (scripting engine) ile beraber gelir. Bunlar “VBScript” ve “Jscript” dir. Bu motorlar birlikte bulunurlar. Bunlar dışında TCL ve PerlScript gibi diğer script motorları da mevcuttur fakat bunlar IIS ile beraber gelmez sadece sonradan eklenir.

 

ASP ye biz hangi script motorunu kullanması gerektiğini söyleyebiliriz. Bu genelde standart olarak IIS de ayarlanmış haldedir (bu işlem için ilk kurulumda tanımlanmış bazı varsayılan değerler mevcuttur). Bu tanımı yapmanın en kolay yolu ASP sayfamızın ilk satırında özel içerik tanımı yapmaktır (Örnek 4 : Language Kullanımı.).

 

 

<%@Language = “dil”%>

 

Örnek 4 : Language Kullanımı.

 

Bu şekilde sayfanın VBScript mi yoksa Jscript mi kullanacağı tanımlanmış olur. VBScript için

 

 

<%@Language = “VBScript”%>

 

Örnek 5 : Varsayılan Dili VbScript Yapmak.

 

Yazabiliriz (Örnek 5 : Varsayılan Dili VbScript Yapmak.). Aynı Mantıkta Jscript için

 

 

<%@Language = “JScript”%>

 

Örnek 6 : Varsayılan Dili JScript Yapmak.

 

Şeklinde bir kod uygun olacaktır (Örnek 6 : Varsayılan Dili JScript Yapmak.).

 

Bu tanımlama yapılsın yada yapılmasın script bloğumuzu <script> elementi ile tanımlamışsak istediğimiz dili orada da tanımlayabiliriz (Örnek 7 : <script> Elementi İçerisinde Dil Belirlemek.).

 

<HTML>

   <Body>

   Bu bir HTML metinidir

 

   <script Runat = ”server” Language = “VBScript”>

     Rem burasi script bloğudur ve dil olarak VBScript Kullanılmıştır

   </script>

 

   <script Runat = ”server” Language = “JScript”>

     Rem burasi script bloğudur ve dil olarak JScript Kullanılmıştır

   </script>

 

   </Body>

</HTML>

Örnek 7 : <script> Elementi İçerisinde Dil Belirlemek.

1.1.5.1.1.      Varsayılan Script Dili

Script elementi içerisinde dil belirtilmemesi durumunda veya <% %> tagları arasında aksi bir ayar yoksa sunucunun varsayılan script dili geçerli olur. Bu varsayılan dil değerini IIS ayarları yardımıyla değiştirebiliriz bunun için, “Internet Service Manager” içerisinden web sitesi adı üzerine sağ tıklayınız, gelen menüden “Özellikler” (Properties) seçeneğine giriniz (Resim 4 : Sunucu Özellikleri.).

 

 

Resim 4 : Sunucu Özellikleri.

 

Özellikler öğesi seçildiği zaman gelecek olan pencerede yer alan “WWW Servis” seçeneğinin düzenle butonuna tıklayarak sistemin ana www servisi ayarlarına ulaşılır. “Home Directory” sekmesine tıklayınız. Gelen pencerede yer alan “Configration” butonuna tıklayınız. Gelen penceredeki “App Options” sekmesine yer alan “Default ASP Language” seçeneğini isteğimize göre düzenleyebiliriz. Bu alana ya “VbScript” yada “Jscript” değeri verilebilir. Aşağıda bu ayar ekranına ait ekran görüntüsü gösterilmektedir (Resim 5 : Varsayılan ASP Ayarları.).

 

 

Resim 5 : Varsayılan ASP Ayarları.

1.1.5.2.            CodePage

Okunabilir ve yazılabilir bir değişken olan codepage sayfa başında özel biçimi ile kullanıldığı zaman içinde olduğu sayfaya ait gösterim ayarları verilmesini sağlar. Örneğin Amerika için “1252” olan bu değer Türkiye için “1254” olacaktır. Bu komutun sayfaya yazılması halinde “scriptengine” e bu çalışan sayfanın gösterim ayarlarının Amerika’ya göre ayarlanacağını belirtir (Örnek 8 : CodePage Kullanımı.).

 

 

<%@CODEPAGE = “1254”%>

 

Örnek 8 : CodePage Kullanımı.

 

Bu komuttan sonra sayfamızda Türkçe karakterler sorunsuz olarak gösterilebilecektir. Bu kod aynı zamanda yukarıda anlatılan script dili belirleme ile beraber kullanılabilmektedir (Örnek 9 : CodePage ve Language Beraber Kullanımı.).

 

 

<%@CODEPAGE = “1254” LANGUAGE=”VbScript”%>

 

Örnek 9 : CodePage ve Language Beraber Kullanımı.

1.1.5.3.            LCID

Okunabilir ve yazılabilir bir değişken olan LCID (Local Identifier : Bölge Tanımlayıcı) sayfa başında özel biçimi ile kullanıldığı zaman içinde olduğu sayfaya ait özel bölgesel ayarların verilmesini sağlar. Örneğin LCID değeri “2057” şeklinde ayarlandığı zaman para birimi “₤” olarak ayarlanacaktır (Örnek 10 : LCID Kullanımı.). Türkiye için bu değer “1055” dir. Bu şekilde Türkiye’ye ait yerel saat ayarlanmış olacaktır.

 

 

<%@LCID = “2057”%>

 

Örnek 10 : LCID Kullanımı.

 

Bu komuttan sonra sayfamızda Türkçe bölgesel ayarlar yapılmış olacak ve tamamen Türkiye ayarları kullanılacaktır. Bu kod aynı zamanda yukarıda anlatılan script dili ve kod sayfası belirleme ile beraber kullanılabilmektedir. Aşağıda bu kullanımın örneği görülmektedir (Örnek 11 : Özel Komutların Beraber Kullanımı.).

 

 

<%@CODEPAGE=“1254” LANGUAGE=”VbScript” LCID=”2057”%>

 

Örnek 11 : Özel Komutların Beraber Kullanımı.

 

Aşağıda dünya çapında kullanılmakta olan bölgesel ayarları gösteren bir tablo bulunmaktadır. Bu tablodaki LCID değerini kullanarak o bölgeye ait ayarları aktif hale getirebilirsiniz.

 

Bölgesel Açiklama

Kısaltma

Hex Değeri

Onluk Değeri (LCID)

Afrikaans

af

0x0436

1078

Albanian

sq

0x041C

1052

Arabic – U.A.E.

ar-ae

0x3801

14337

Arabic – Bahrain

ar-bh

0x3C01

15361

Arabic – Algeria

ar-dz

0x1401

5121

Arabic – Egypt

ar-eg

0x0C01

3073

Arabic – Iraq

ar-iq

0x0801

2049

Arabic – Jordan

ar-jo

0x2C01

11265

Arabic – Kuwait

ar-kw

0x3401

13313

Arabic – Lebanon

ar-lb

0x3001

12289

Arabic – Libya

ar-ly

0x1001

4097

Arabic – Morocco

Ar-ma

0x1801

6145

Arabic – Oman

Ar-om

0x2001

8193

Arabic – Qatar

ar-qa

0x4001

16385

Arabic – Saudia Arabia

ar-sa

0x0401

1025

Arabic – Syria

ar-sy

0x2801

10241

Arabic – Tunisia

ar-tn

0x1C01

7169

Arabic – Yemen

ar-ye

0x2401

9217

Basque

eu

0x042D

1069

Belarusian

be

0x0423

1059

Bulgarian

bg

0x0402

1026

Catalan

ca

0x0403

1027

Chinese

zh

0x0004

4

Chinese – PRC

zh-cn

0x0804

2052

Chinese – Hong Kong

zh-hk

0x0C04

3076

Chinese – Singapore

zh-sg

0x1004

4100

Chinese – Taiwan

zh-tw

0x0404

1028

Croatian

hr

0x041A

1050

Czech

cs

0x0405

1029

Danish

da

0x0406

1030

Dutch

nl

0x0413

1043

Dutch – Belgium

nl-be

0x0813

2067

English

en

0x0009

9

English – Australia

en-au

0x0C09

3081

English – Belize

en-bz

0x2809

10249

English – Canada

en-ca

0x1009

4105

English – Ireland

en-ie

0x1809

6153

English – Jamaica

en-jm

0x2009

8201

English – New Zealand

en-nz

0x1409

5129

English – South Africa

en-za

0x1C09

7177

English – Trinidad

en-tt

0x2C09

11273

English – United Kingdom

en-gb

0x0809

2057

English – United States

en-us

0x0409

1033

Estonian

et

0x0425

1061

Farsi

fa

0x0429

1065

Finnish

fi

0x040B

1035

Faeroese

fo

0x0438

1080

French – Standard

fr

0x040C

1036

French – Belgium

fr-be

0x080C

2060

French – Canada

fr-ca

0x0C0C

3084

French – Luxembourg

fr-lu

0x140C

5132

French – Switzerland

fr-ch

0x100C

4108

Gaelic – Scotland

gd

0x043C

1084

German – Standard

de

0x0407

1031

German – Austrian

de-at

0x0C07

3079

German – Lichtenstein

de-li

0x1407

5127

German – Luxembourg

de-lu

0x1007

4103

German – Switzerland

de-ch

0x0807

2055

Greek

el

0x0408

1032

Hebrew

he

0x040D

1037

Hindi

hi

0x0439

1081

Hungarian

hu

0x040E

1038

Icelandic

is

0x040F

1039

Indonesian

in

0x0421

1057

Italian – Standard

it

0x0410

1040

Italian – Switzerland

it-ch

0x0810

2064

Japanese

ja

0x0411

1041

Korean

ko

0x0412

1042

Latvian

lv

0x0426

1062

Lithuanian

lt

0x0427

1063

Macedonian

mk

0x042F

1071

Malay – Malaysia

ms

0x043E

1086

Maltese

mt

0x043A

1082

Norwegian – Bokmål

no

0x0414

1044

Polish

pl

0x0415

1045

Portuguese – Standard

pt

0x0816

2070

Portuguese – Brazil

pt-br

0x0416

1046

Raeto-Romance

rm

0x0417

1047

Romanian

ro

0x0418

1048

Romanian – Moldova

ro-mo

0x0818

2072

Russian

ru

0x0419

1049

Russian – Moldova

ru-mo

0x0819

2073

Serbian – Cyrillic

sr

0x0C1A

3098

Setsuana

tn

0x0432

1074

Slovenian

sl

0x0424

1060

Slovak

sk

0x041B

1051

Sorbian

sb

0x042E

1070

Spanish – Standard

es

0x040A

1034

Spanish – Argentina

es-ar

0x2C0A

11274

Spanish – Bolivia

es-bo

0x400A

16394

Spanish – Chile

es-cl

0x340A

13322

Spanish – Columbia

es-co

0x240A

9226

Spanish – Costa Rica

es-cr

0x140A

5130

Spanish-Dominican Republic

es-do

0x1C0A

7178

Spanish – Ecuador

es-ec

0x300A

12298

Spanish – Guatemala

es-gt

0x100A

4106

Spanish – Honduras

es-hn

0x480A

18442

Spanish – Mexico

es-mx

0x080A

2058

Spanish – Nicaragua

es-ni

0x4C0A

19466

Spanish – Panama

es-pa

0x180A

6154

Spanish – Peru

es-pe

0x280A

10250

Spanish – Puerto Rico

es-pr

0x500A

20490

Spanish – Paraguay

es-py

0x3C0A

15370

Spanish – El Salvador

es-sv

0x440A

17418

Spanish – Uruguay

es-uy

0x380A

14346

Spanish – Venezuela

es-ve

0x200A

8202

Sutu

sx

0x0430

1072

Swedish

sv

0x041D

1053

Swedish – Finland

sv-fi

0x081D

2077

Thai

th

0x041E

1054

Turkish

tr

0x041F

1055

Tsonga

ts

0x0431

1073

Ukranian

uk

0x0422

1058

Urdu – Pakistan

ur

0x0420

1056

Vietnamese

vi

0x042A

1066

Xhosa

xh

0x0434

1076

Yiddish

ji

0x043D

1085

Zulu

zu

0x0435

1077

Tablo 1 : LCID Değerleri.


 

 

 

 

 

 

 

 

tuna

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir