Jak interpretowano formularze HTML we wczesnych latach 90-tych?

109

We współczesnej sieci WWW <form>element HTML jest przesyłany, a następnie interpretowany przez skrypty. Albo jest interpretowany przez język programowania po stronie serwera (zwykle PHP), albo jest interpretowany przez skrypt po stronie klienta (prawie zawsze JavaScript).

Formy istniały jeszcze na początku lat 90. Jak były wtedy interpretowane?

Zgodnie z tym artykułem w Wikipedii w tamtym czasie przesłano formularz HTML przez e-mail, ale było to zawodne. Czy to wszystko, co było? Dlaczego HTML miał w ogóle formularze, skoro były tak bezużyteczne bez użycia skryptów? A może była to sytuacja w rodzaju kurczaka i jajka?

html forms

— James Jones
źródło

25

Użyłem Perla z cgi

67

Zawsze

— istniały

22

Aby uzupełnić obraz, wykorzystano kilka wczesnych formularzy, action="mailto:staff@example.com"które nakazały przeglądarce internetowej uruchomienie klienta poczty e-mail i przesłanie przesłanych pól jako surowej zawartości nowej wiadomości e-mail. Zero programowania, tylko część personelu do ręcznego przetwarzania wiadomości e-mail.

— kubańczyk

2

Nawet przed formularzami istniał <ISINDEX>, który często był podłączony do serwera WAIS .

— zwol

182

Przed skryptami po stronie serwera (PHP, Ruby, node.js) istniało programowanie po stronie serwera.

Jednym z oryginalnych interfejsów między serwerami WWW a procesami zaplecza był Common Gateway Interface (CGI). Został wprowadzony na początku lat 90. przez zespół zaplecza NCSA w tym samym czasie, gdy formularze zostały wprowadzone do HTML przez Tima Berners-Lee (który również był w tym czasie w NCSA). Tak więc formularze zostały wprowadzone mniej więcej w tym samym czasie, gdy wynaleziono CGI.

Początkowo wiele osób pisało programy CGI w języku C. Byłem jednym z tych, którzy musieli to robić jako zadanie domowe. Zamiast gigantycznego, wszechstronnego frameworka napisaliśmy małe programy w C, które czytają ze stdin i drukują na stdout (wydrukowaliśmy odpowiedź HTTP, a nie tylko HTML, zgodnie ze specyfikacją CGI). Witryna internetowa zawierała wiele takich małych programów, z których każdy wykonywał jedną małą rzecz i aktualizował pewną bazę danych (czasami ta baza danych była po prostu zwykłym plikiem).

Niemal natychmiast po jej wprowadzeniu ludzie zaczęli pisać skrypty CGI w Perlu. Tak więc naprawdę nie było okresu przejściowego między programami C i językami skryptowymi. Ludzie po prostu przestali pisać skrypty CGI w C, ponieważ było to szybsze w językach skryptowych.

— slebetman
źródło

4

Świetna odpowiedź od Ciebie i @Dekel. Te odpowiedzi i sugerowane linki naprawdę wypełniają lukę. Nie mogę się powstrzymać od zastanawiania się, ile witryn faktycznie przeszkadzało we wdrażaniu któregokolwiek z tych elementów, zanim technologie takie jak JS, Perl, PHP były dostępne do tworzenia skryptów internetowych. Ale to pytanie na inny dzień.

— James Jones

15

@JamesJones, wielu z nas to zrobiło. Rozpoczęcie pracy nie było takie trudne, chociaż brakowało narzędzi do skalowania do dużych i wydajnych aplikacji internetowych. Czytałem programowanie CGI w sieci WWW pod koniec lat 90. i jako nastolatek zacząłem pisać wszelkiego rodzaju kod CGI.

— Dan Lenski

12

W rzeczywistości podstawowy program CGI jest bardzo łatwy do napisania. Po prostu wydrukuj kilka statycznych nagłówków i trochę HTML z przeplatanymi danymi. Chodzi tylko o to, że technologia (HTML zmieszany z nagłówkami zmieszanymi z kodem ...) nie daje się dobrze skalować do złożonych aplikacji. Stąd wymyślono ramy ...

— sleske

12

Jeśli nadal chcesz zobaczyć CGI w akcji, wypróbuj szwajcarski rozkład jazdy kolejowej: sbb.ch - wprowadź miejsce odjazdu i celu podróży - naciśnij czerwony przycisk - następnie spójrz na adres URL w przeglądarce, a zwłaszcza na część query.exe: -)

— theDmi

8

Jeśli chodzi o to, „jak rozpowszechnione było to”: cóż, znacznie więcej witryn internetowych było wtedy całkowicie statycznych. Ale dwoma powszechnie spotykanymi fragmentami aktywnej zawartości były „księgi gości” (przestarzałe przez blogi / media społecznościowe / spam) i „liczniki odwiedzin”.

— pjc50

70

Na zdjęciu zawsze była strona serwera.

Serwer Apache HTTP był dostępny od 1995 r., Aw 1996 r. Miał również obsługę Perla (który był używany jako język programowania po stronie serwera).

JavaScript powstał w 1996 roku, a Netscape był pierwszą przeglądarką obsługującą język po stronie klienta (implementacje innych producentów przeglądarek były oparte na pracy wykonanej w Netscape).

W 1993 roku została wydana przeglądarka Mosaic obsługująca obrazy, listy zagnieżdżone i formularze do wypełniania.

Zasadniczo - każdy serwer HTTP, który mógłby obsłużyć żądanie i przekazać je do jakiejś aplikacji (bez względu na język, w którym ta aplikacja jest napisana) jest aplikacją po stronie serwera. Można go napisać w języku skryptowym (Perl / Python / PHP / Ruby), języku wysokiego poziomu (Java / C #) i jeśli naprawdę chcesz - nawet w asemblerze. Wszystko, co musisz zrobić, to upewnić się, że „przestrzegasz protokołu”.

— Dekel
źródło

1

Dobra historia. Głosowano za. Jednak formularze zostały wdrożone przed 1995 rokiem. Nie wiem, kiedy, ale w en.wikipedia.org/wiki/HTML znajduje się

Dave Raggett's competing Internet-Draft, "HTML+ (Hypertext Markup Format)", from late 1993, suggested standardizing already-implemented features like tables and fill-out forms.

Twój ostatni akapit opisujący praktyki sprzed 1995 roku?

— James Jones

3

@JamesJones: Sprawdź wpis Wikipedii na temat Common Gateway Interface

— slebetman

2

@JamesJones, dodał kilka informacji dotyczących przeglądarki Mosaic Browser i wypełniania formularzy. Masz również świetną odpowiedź od slebetmana dotyczącą CGI.

— Dekel

1

Standardy @JamesJones nie są jednoznaczne i mają pełne zastosowanie do większości rzeczy w sieci (choć nie jako całości). Standard HTML był (i nadal jest) okropny i każdy stworzył własne rozszerzenia. Najsłynniejsze były Mosaic, Netscape i Internet Explorer - większość ich rozszerzeń została dodana do późniejszych standardów HTML, przy czym Netscape i IE współpracowały dość często. HTML nie miał wtedy nawet osadzonych obrazów ( img) - autor uznał, że jest to niezgodne z ideą hiper-tekstu; dopiero sukces Mosaic / Netscape wymusił zmianę standardu.

— Luaan

3

Ta odpowiedź niekoniecznie jest błędna, ale nie jestem do końca pewien, w jaki sposób rzeczy wprowadzone co najmniej 2-3 lata po udostępnieniu formularzy w przeglądarce są dowodem na to, że zawsze istniała obsługa formularzy po stronie serwera.

— 8bittree

1

JavaScript nie był tak zaawansowany (do diabła, Ajax jeszcze nie wyszedł). Więc to było po stronie serwera. Głównie CGI (Perl) i PHP.

Był też Coldfusion, ale nie był to popularny faworyt.

Ostatecznie pod koniec 1999 i na początku 2000 roku pojawiły się ASP.NET (aspx) i JavaServer Pages (jsp), chociaż wiele komercyjnych witryn używało aspx i jsp z oczywistych powodów.

Uwaga, aplety Java również istniały (choć głównie do renderowania), ale musiały być oddzielnie pobierane i obsługiwane przez przeglądarkę.

— tfont
źródło

3

Właściwie programowałem ASP na początku 1998 roku. Wcześniej istniał inny standard MS zwany htxszablonami.

— Little Santi

1

^ brzmi, jakbyś był jednym z oryginałów! Dawno temu kolego! : D: D

— tfont

1

Dodatkowo natknąłem się na ciekawy kawałek historii na Wikipedii. Formularze HTML można również wysyłać pocztą elektroniczną, używając mailto:adresu w targetatrybucie. Nie wydawał się popularny, ale wciąż fajny!

Cytując artykuł z Wikipedii :

Obsługa klienta użytkownika do przesyłania formularzy HTML opartych na wiadomościach e-mail, przy użyciu adresu URL „mailto” jako akcji formularza, została zaproponowana w RFC 1867 sekcja 5.6 w erze HTML 3.2. Różne przeglądarki internetowe zaimplementowały go, wywołując oddzielny program pocztowy lub używając własnych podstawowych funkcji SMTP. Chociaż czasami zawodny, był przez krótki czas popularny jako prosty sposób przesyłania danych formularza bez angażowania serwera WWW lub skryptów CGI.

I RFC 1867 (listopad 1995):

5.6 Zezwól formularzowi ACTION na „mailto:”

Niezależnie od tej propozycji byłoby bardzo przydatne dla klientów
interpretujących HTML , aby zezwolić AKCJI w formularzu na
adres URL „mailto:”. Wydaje się, że to dobry pomysł, z tą
propozycją lub bez niej . Podobnie, DZIAŁANIE dla formularza HTML, który jest odbierany pocztą, powinno być prawdopodobnie domyślnie ustawione jako „odpowiedź do:” wiadomości.
Te dwie propozycje pozwoliłyby na
przesyłanie formularzy HTML przez serwery HTTP , ale odsyłanie ich pocztą lub, alternatywnie,
na wysyłanie formularzy HTML pocztą, wypełnianie ich przez odbiorców poczty znających język HTML, a wyniki byłyby przesyłane z powrotem.

— Baptiste Candellier
źródło