90'ların başında HTML formları nasıl yorumlandı?


109

Modern web'de bir HTML <form>öğesi gönderilir ve ardından komut dosyası ile yorumlanır. Ya bir sunucu tarafı programlama dili (genellikle PHP) tarafından yorumlanır ya da bir istemci tarafı komut dosyası (neredeyse her zaman JavaScript) tarafından yorumlanır.

90'ların başında bile formlar vardı. O zamanlar nasıl yorumlandılar?

Bu Wikipedia makalesine göre, o zamanlar e-posta tabanlı bir HTML formu gönderimi vardı, ancak güvenilmezdi. Tüm olan bu muydu? Komut dosyası olmadan bu kadar işe yaramazlarsa HTML'nin neden formları vardı? Yoksa tavuk ve yumurta gibi bir durum muydu?


25
cgi ile perl kullandım

67
Her zaman sunucu tarafı komut dosyası vardı
OrangeDog

22
Resmi tamamlamak için, action="mailto:staff@example.com"bir web tarayıcısına bir e-posta istemcisi başlatmasını ve gönderilen alanları yeni bir e-postanın ham içeriği olarak aktarmasını söyleyen bazı erken formlar kullanıldı . Sıfır programlama, sadece e-postaları elle işlemek için birkaç personel.
kubanczyk

2
Formlardan önce bile, <ISINDEX>genellikle bir WAIS sunucusuna takılıydı .
zwol

Yanıtlar:


182

Sunucu tarafı kodlamadan (PHP, Ruby, node.js) önce sunucu tarafı programlama vardı.

Web sunucuları ile arka uç süreçleri arasındaki orijinal arabirimlerden biri, Ortak Ağ Geçidi Arabirimi (CGI) idi. 90'ların başında NCSA arka uç ekibi tarafından tanıtıldı, aynı zamanda formlar HTML'ye Tim Berners-Lee (o sırada NCSA'da da vardı) tarafından tanıtıldı. Böylece formlar aşağı yukarı CGI icat edildiğinde tanıtıldı.

Başlangıçta birçok kişi C'de CGI programları yazdı. Bunu bir ev ödevi olarak yapmak zorunda olanlardan biriydim. Her şeyi kapsayan dev bir çerçeve yerine, stdin'den okuyan ve stdout'a yazdıran küçük C programları yazdık (sadece CGI spesifikasyonuna göre HTML'yi değil, HTTP yanıtını yazdırdık). Bir web sitesinde, her biri küçük bir şey yapan ve bazı veritabanlarını güncelledi (bazen bu veritabanı yalnızca düz bir dosyaydı) bu küçük programların çoğu vardı.

Neredeyse tanıtıldığı anda insanlar Perl'de CGI komut dosyaları yazmaya da başladı. Dolayısıyla C programları ile betik dilleri arasında gerçekten bir geçiş dönemi olmadı. İnsanlar basitçe CGI komut dosyalarını yazmayı bıraktı çünkü kodlama dillerinde bunu yapmak daha hızlıydı.


4
Hem sizden hem de @Dekel'den harika yanıt. Bu cevaplar ve önerilen bağlantılar gerçekten boşluğu dolduruyor. Yardım edemem ama JS, Perl, PHP gibi teknolojiler web komut dosyası oluşturma için mevcut olmadan önce kaç web sitesinin bu şeylerden herhangi birini uygulamakla uğraştığını merak ediyorum. Ama bu başka bir gün için bir soru.
James Jones

15
@JamesJones, çok ve çoğumuz yaptık. Büyük ve yüksek performanslı web uygulamalarına ölçeklendirme araçları eksik olsa da, başlamak o kadar da zor değildi. 90'ların sonlarında World Wide Web'de CGI Programlama okudum ve gençken her türlü CGI kodunu yazmaya başladım.
Dan Lenski

12
Aslında, temel bir CGI programının yazılması çok kolaydır. Sadece bazı statik başlıklar ve verilerinizin arasına serpiştirilmiş bir miktar HTML yazdırın. Sadece teknoloji (kodla karıştırılmış başlıklarla karıştırılmış HTML ...) karmaşık uygulamalara iyi ölçeklenmiyor. Bu nedenle çerçeveler icat edildi ...
sleske

12
Yine de CGI'yi çalışırken görmek istiyorsanız, İsviçre demiryolu tarifesini deneyin: sbb.ch - bir kalkış ve varış konumu girin - kırmızı düğmeye basın - ardından tarayıcıdaki URL'ye, özellikle query.exe bölümüne bakın: -)
theDmi

8
"Ne kadar yaygındı": O zamanlar çok daha fazla web sitesi tamamen durağandı. Ancak yaygın olarak görülen iki aktif içerik parçası "ziyaretçi defteri" (bloglar / sosyal medya / spam tarafından kullanılmıyor) ve "isabet sayaçları" idi.
pjc50

70

Sunucu tarafı aslında her zaman resmin içindeydi.

Apache HTTP Sunucusu 1995 yılından beri mevcut olduğunu ve 1996 yılında da vardı Perl desteği (bir sunucu tarafı programlama dili olarak kullanılmıştır).

JavaScript 1996'da oluşturuldu ve Netscape, istemci tarafı dilini destekleyen ilk tarayıcıydı (diğer tarayıcı satıcılarının uygulamaları, Netscape'te yapılan çalışmaya dayanıyordu).

1993'te Mozaik tarayıcısı, resimler, iç içe geçmiş listeler ve doldurma formları desteği ile piyasaya sürüldü.

Temel olarak - isteği işleyebilen ve onu bazı uygulamalara iletebilen (o uygulamanın hangi dilde yazıldığına bakılmaksızın) her HTTP sunucusu bir sunucu tarafı uygulamasıdır. Komut dosyası dilinde (Perl / Python / PHP / Ruby), yüksek seviyeli dilde (Java / C #) ve gerçekten istiyorsanız - hatta montajda yazılabilir. Yapmanız gereken tek şey "protokole uyduğunuzdan" emin olmaktır.


1
İyi tarih. Upvoted. Ancak, formlar 1995'ten önce uygulandı. Tam olarak ne zaman çalışamıyorum ama en.wikipedia.org/wiki/HTML'deDave Raggett's competing Internet-Draft, "HTML+ (Hypertext Markup Format)", from late 1993, suggested standardizing already-implemented features like tables and fill-out forms. 1995'ten önceki uygulamaları açıklayan son paragrafınız var mı?
James Jones

3
@JamesJones: Ortak Ağ Geçidi Arayüzündeki Wikipedia girişini kontrol edin
slebetman

2
@JamesJones, Mozaik Tarayıcı ile ilgili bazı bilgiler ekledi ve formları doldur. Ayrıca slebetman'dan CGI ile ilgili harika bir cevabınız var.
Dekel

1
@JamesJones Standartları kesin değildir ve web'deki çoğu şey için geçerlidir (bir bütün olarak internet olmasa da). HTML standardı (ve gerçekten, hala) korkunçtu ve herkes kendi uzantılarını yarattı. Mosaic, Netscape ve Internet Explorer en kötü şöhretli olanlardı - uzantılarının çoğu daha sonraki HTML standartlarına eklendi, Netscape ve IE bu konuda biraz işbirliği yaptı. HTML'nin o zamanlar gömülü görüntüleri ( img) bile yoktu - yazar, hiper metin fikrine uymadığını düşünüyordu; sadece Mosaic / Netscape'in başarısı standarttaki değişikliği zorladı.
Luaan

3
Bu cevabın mutlaka yanlış olması gerekmez, ancak tarayıcıda formlar kullanıldıktan en az 2-3 yıl sonra ortaya çıkan şeylerin, formlar için her zaman sunucu tarafı desteğinin var olduğunun kanıtı olduğundan emin değilim.
8bittree

1

JavaScript o kadar gelişmiş değildi (Ajax henüz çıkmamıştı). Yani tamamen sunucu tarafındaydı. Çoğunlukla CGI (Perl olmak üzere) ve PHP.

Coldfusion da vardı ama popüler bir favori değildi.

Sonunda, 1999'un sonunda ve 2000'lerin başında ASP.NET (aspx) ve JavaServer Pages (jsp) çıktı, ancak birçok ticari site açık nedenlerle aspx ve jsp kullanıyordu.

Java uygulamalarının da (çoğunlukla oluşturma için) mevcut olduğunu, ancak tarayıcı tarafından ayrı olarak indirilmesi ve desteklenmesi gerektiğini unutmayın.


3
Aslında, 1998'in başında ASP'leri programladım. Ondan önce, htxşablon adı verilen başka bir MS standardı vardı .
Little Santi

1
^ orijinallerden biriymişsiniz gibi görünüyor! Uzun zaman önce dostum! : D: D
tfont

1

Ek olarak, Wikipedia'da ilginç bir tarih parçasına rastladım. HTML formları mailto:, targetöznitelikte bir adres kullanılarak e-posta ile de gönderilebilir . Popüler görünmüyordu, ama yine de harika!

Wikipedia makalesinden alıntı yapmak :

E-posta tabanlı HTML form gönderimi için, form işlemi olarak bir 'mailto' URL'si kullanan kullanıcı aracısı desteği, HTML 3.2 döneminde RFC 1867 bölüm 5.6'da önerilmiştir. Çeşitli web tarayıcıları, ayrı bir e-posta programını çalıştırarak veya kendi temel SMTP yeteneklerini kullanarak bunu gerçekleştirdi. Bazen güvenilmez olsa da, bir web sunucusu veya CGI komut dosyaları olmadan form verilerini iletmenin basit bir yolu olarak kısaca popülerdi.

Ve RFC 1867 (Kasım 1995):

5.6 ACTION formunun "mailto:" olmasına izin ver

Bu tekliften bağımsız olarak, HTML
yorumlama kullanıcı aracılarının bir formdaki bir
ACTION'ın "mailto:" URL'si olmasına izin vermesi çok yararlı olacaktır . Bu
teklif olsun ya da olmasın bu iyi bir fikir gibi görünüyor . Benzer şekilde, postayla alınan bir HTML formu için ACTION, muhtemelen iletinin "yanıtla:" seçeneğini kullanmalıdır.
Bu iki teklif, HTML formlarının HTTP
sunucuları aracılığıyla sunulmasına ancak postayla geri gönderilmesine veya alternatif olarak HTML formlarının
postayla gönderilmesine, HTML'ye duyarlı posta alıcıları tarafından doldurulmasına ve sonuçların geri gönderilmesine izin verir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.