Yorum Talebi: 607

Mark Krilanovich
George Gregg
NIC #21255
Referanslar: RFC #542 UCSB
Ocak 1974

Dosya Aktarım Protokolü Üzerine Yorumlar

Dosya Aktarım Protokolü’nün ciddi sakıncalar oluşturan çeşitli yönleri vardır. Bunların bazıları doğası gereği oldukça temeldir ve önemli tasarım değişikliklerini ima eder; bunlar daha sonraki bir RFC’de ele alınacaktır. Diğerleri ise çok az çabayla giderilebilir ve bunun mümkün olan en kısa sürede yapılması gerekir.

Aşağıda, kolayca çözülebilecek olan bu sorunların ve önerilen çözümlerinin bir listesi yer almaktadır:

1. Bir sunucuya veri bağlantılarının kurulması konusunda “pasif” olması söylendikten sonra, kullanıcının onu tekrar “aktif” hale getirmesinin bir yolu yoktur.

   ÇÖZÜM: Sunucunun veri soketi üzerinde LISTEN yerine CONNECT göndermesi gerektiğini ifade eden, komut fiili “ACTV” olan yeni bir komut tanımlansın. Sunucu zaten “aktif” durumdaysa, bu komut hiçbir işlem yapmaz. “ACTV”, “PASV” ile aynı yanıt kodlarına sahip olacaktır.

2. Tüm komut fiillerinin aynı uzunlukta olması durumunda bir FTP sunucusunun tasarımı daha basit olurdu; bir FTP kullanıcısının tasarımı ise ya tüm komut fiilleri aynı uzunlukta olsaydı ya da fiilden sonra birden fazla boşluğa izin verilseydi daha basit olurdu.

   ÇÖZÜM: Üç harfli tek fiil olan “BYE” yerine “QUIT” gibi dört harfli bir fiil kullanılsın ve gelecekteki komut fiillerinin dört harf uzunluğunda olması zorunlu kılınsın.

3. Bir dosya aktarım komutunu izleyen el sıkışma öğelerinin sırası belirtilmemiştir. Örneğin bir STOR komutu gönderildikten sonra, bir kullanıcı sürecinin önce hangisini beklemesi gerektiğini bilmesinin bir yolu yoktur: “250 FILE TRANSFER STARTED” yanıtı mı, yoksa veri bağlantısının kurulması mı.

   ÇÖZÜM: Sunucunun, veri bağlantısını kurmaya teşebbüs etmeden önce bir “250” yanıtı göndermesi belirtilecektir. Kullanıcının giriş yapıp yapmadığını, dosyanın mevcut olup olmadığını veya kullanıcının dosyaya erişimine izin verilip verilmeyeceğini denetlemek isteniyorsa, bu kontroller herhangi bir yanıt gönderilmeden önce yapılmalıdır. “250” yanıtının metni, gerçek veri aktarımı başlamadan önce geldiği için muhtemelen “250 OPENING DATA CONNECTION” olarak daha uygun olacaktır. Sunucu, veri bağlantısının açılamaması durumunda bir hata yanıtı göndermek isterse, bu yanıt “252 TRANSFER COMPLETE” yanıtı yerine gönderilecektir.

4. Bazı ana makineler, gerek duyulmadığı için uygulanmamış bir komut alındığında (örneğin “ACCT” veya “ALLO”) hata yanıtı göndermektedir. Yanıt metni komutun yok sayıldığını belirtse bile, bir kullanıcı sürecinin gerçek bir “hata” olmadığını bilmesi açıkça imkânsızdır.

   ÇÖZÜM: Bir sunucu, belirli bir komutu sisteminde gerekmediği için desteklemiyorsa, mutlaka bir başarı yanıtı döndürmelidir.

5. TELNET satırı, kullanıcı adı, parola, hesap, veya yol adı için belirtilmiş bir azami uzunluk yoktur. FTP sunucusu uygulayan her sistemin kendi parametreleri için farklı azami değerlere sahip olması muhtemeldir; ancak birçok FTP sunucusuyla iletişim kurmak zorunda olan bir FTP kullanıcısını yazan kişi için belirsiz uzunlukta bir arabellek oluşturmak neredeyse imkânsızdır. Genellikle keyfi bir azami değer seçilmek zorunda kalınır.

   ÇÖZÜM: TELNET satırları, kullanıcı adları, parolalar, hesap numaraları ve yol adları için bir azami uzunluk belirtilecektir. Bu, hizmet veren sitelerin kendi azami değerleri hakkında bir anket yapıldıktan sonra gerçekleştirilecektir.

6. Devam satırlarının keyfi metinle başlamasına izin verilmesi fikri, birkaç sunucu FTP uygulayıcısı için küçük bir sorunu çözerken, tüm kullanıcı FTP uygulayıcıları için büyük bir sorun meydana getirmektedir. Çok satırlı bir yanıtı çözümlemek için gereken mantık gereksiz yere karmaşıktır ve çok satırlı yanıtların iç içe olmasına izin verilmesi nedeniyle bu karmaşıklık bir büyüklük mertebesi daha artmaktadır.

   ÇÖZÜM: İlk satırdan sonra gelen çok satırlı bir yanıtın tüm satırlarında kullanılmak üzere “009” gibi benzersiz (sayısal) bir yanıt kodu atanacaktır.

7. Çok satırlı yanıtların iç içe olmasına izin verildiği göz önüne alındığında, izin verilen azami iç içe geçme düzeyinin belirtilmemiş olması, kullanıcı FTP’lerini uygulayanlar için bir zorluk oluşturmaktadır. Bu zorluk, donanımsal yığınlara sahip bir makinede nispeten kolayca çözülebilirken, diğer makineler için aynı durum geçerli değildir.

   ÇÖZÜM: Çok satırlı yanıtlar için bir azami iç içe geçme düzeyi belirtilecektir.

8. Bloklu kipte, protokol “tüm kayıt sonu işaretleyicilerinin (EOR) açık olduğu, sonuncu da dâhil” olduğunu belirtir. Bu, son kayıt sonu ile dosya sonu arasına veri gönderilmesini yasaklar; ancak bu kuralın ihlal edilmesi durumunda veri alıcısının ne yapması gerektiğini belirtmez. Yani, aradaki veriler atılmalı mıdır yoksa yeni (son) bir kayıt olarak mı ele alınmalıdır?

   ÇÖZÜM: Eğer bir dosya sonu işaretleyicisi hemen öncesinde bir kayıt sonu işaretleyicisi yoksa, aradaki verilerin atılması belirtilecektir.

Protokolle ilgili önemli bir şikâyet, bir FTP kullanıcı süreci yazan kişinin, yalnızca gönderilen son komutun başarılı olup olmadığını belirlemek için bile çok sayıda özel durumu ele almak zorunda kalmasıdır. Protokolün aşağıdaki alanların tümünde iyi tanımlanmış olduğu kabul edilmektedir; ancak “iyi tanımlanmış” olma niteliğinin gerekli olmakla birlikte yeterli olmadığını fark etmek önemlidir. Birçok nedenle, tüm gereksinimleri karşılayan en basit mekanizmanın kullanılması son derece arzu edilir. Aşağıda, bir FTP kullanıcı sürecinin akış şemasını gereksiz yere karmaşıklaştıran bu sakıncaların bir listesi yer almaktadır:

9. Farklı komutların farklı başarı yanıt kodları vardır. Örneğin başarılı bir “USER” komutu “230” döndürürken, başarılı bir “BYTE” komutu “200” döndürür. Başarı yanıtlarının ilk basamağının çift, başarısızlık yanıtlarının ise tek olması gerektiği düşüncesi geçerli değildir; çünkü “100”, “STAT” için başarı anlamına gelirken, “402” “BYTE” için başarısızlık anlamına gelir.

   ÇÖZÜM: Herhangi bir komutun başarılı olması durumunda, benzersiz bir basamakla (örneğin “2”) başlayan bir yanıt kodu döndürmesi, başarılı olmaması durumunda ise bu basamak dışında bir değer döndürmesi belirtilecektir.

10. Bazı komutların birden fazla olası başarı yanıt kodu vardır; örneğin “USER”, “REIN” ve “BYE”. Bir FTP kullanıcısının, her biri “komut kabul edildi, devam et” anlamına gelen yanıt kodlarının her komut için ayrı ayrı bir listesini tutmak zorunda bırakılması istenmeyen bir durumdur.

    ÇÖZÜM: Yukarıdaki (9.) maddesi ile aynıdır. Yalnızca “evet” veya “hayır”dan daha özel bilgiler iletme isteği —örneğin bazı sitelerin giriş prosedüründe tüm parametrelere ihtiyaç duymaması gibi— şu şekilde çözülebilir: Örneğin “238”, “PASSWORD ACCEPTED, YOU ARE NOW LOGGED IN” anlamına gelebilirken, “237”, “PASSWORD ACCEPTED, ACCOUNT NOW NEEDED” anlamına gelebilir. Önemli nokta, “komut kabul edildi” fikrinin baştaki “2” ile iletilmesi ve daha ince anlam ayrımlarının istenirse kullanıcı süreci tarafından çıkarılabilmesidir.

11. Bir kullanıcı FTP süreci açısından gereksiz olan çeşitli yanıt türleri vardır ve bunların yanıt kodlarında kolayca ayırt edilmelerini sağlayan bir özellik bulunmamaktadır. Örneğin “010 message from operator” ve “050 FTP commentary” bir kullanıcı süreci için gereksizdir; buna karşılık “300” selamlaması yerine kullanılan “000 announcing FTP” gereksiz değildir.

    ÇÖZÜM: Yalnızca bir insan kullanıcı için anlam taşıyan ve bir kullanıcı süreci için anlam taşımayan her yanıtın, “0” gibi benzersiz bir basamakla başlayan bir yanıt koduna sahip olması belirtilecektir. Yukarıda (8.) maddesinde önerilen devam satırı yanıt kodu da bu kategoriye girer ve dolayısıyla aynı benzersiz basamakla başlamalıdır.

12. Girdi hemen kabul edilemiyorsa, ICP’nin tamamlanmasından hemen sonra sunucunun “000 announcing FTP” veya “020 expected delay” göndermesi düşüncesi, bir kullanıcı süreci için aynı anlama gelen birden fazla yanıt kodu bulunmasına dair başka bir örnektir.

    ÇÖZÜM: Belirtilen durumda sunucunun “020” yanıt koduna sahip bir yanıt göndermesi zorunlu kılınacaktır. Daha ayrıntılı bilgi iletilmek istenirse, yanıtın metni bu amaçla kullanılabilir.

Yukarıda belirtilen protokol zayıflıklarına ek olarak, aşağıdakinin bir dizgi hatası olduğu düşünülmektedir:

13. “331” yanıt kodu, “BYTE”, “SOCK”, “PASV”, “TYPE”, “STRU”, “MODE”, “ALLO”, “REST”, “SITE” ve “STAT” komutları için olası bir başarı yanıt kodu olarak gösterilmektedir. Bu yanıt kodu “ENTER ACCOUNT” (giriş dizisinin bir parçası olarak gerekliyse) anlamına gelir ve belki de “332 LOGIN FIRST, PLEASE” olmalıdır. Bu durum özellikle, “332”nin komut-yanıt eşleştirme tablosunda hiçbir yerde listelenmemiş olmasıyla gösterilmektedir.