Как интерпретировались HTML-формы в начале 90-х?

109

В современном Интернете <form>элемент HTML передается, а затем интерпретируется с помощью сценариев. Либо он интерпретируется серверным языком программирования (обычно PHP), либо интерпретируется клиентским скриптом (почти всегда JavaScript).

Формы существовали еще в начале 90-х. Как их тогда интерпретировали?

Согласно этой статье в Википедии, тогда была отправка HTML-формы по электронной почте, но она была ненадежной. Это все, что было? Почему в HTML были формы, если они были бесполезны без сценариев? Или это была ситуация с курицей и яйцом?

html forms

— Джеймс Джонс
источник

25

Я использовал Perl с cgi

67

Всегда был сценарий на стороне сервера

— OrangeDog

22

Чтобы завершить картину, использовались некоторые ранние формы, action="mailto:staff@example.com"которые сообщали веб-браузеру, что нужно запустить почтовый клиент и передать отправленные поля как грубое содержимое нового электронного письма. Никакого программирования, только несколько сотрудников для обработки электронных писем вручную.

— kubanczyk

2

Даже до форм существовал <ISINDEX>, который часто был подключен к серверу WAIS .

— zwol

182

До создания сценариев на стороне сервера (PHP, Ruby, node.js) программирование на стороне сервера существовало.

Одним из первоначальных интерфейсов между веб-серверами и внутренними процессами был Common Gateway Interface (CGI). Он был введен в начале 90-х бэкэнд-командой NCSA одновременно с тем, что формы были введены в HTML Тимом Бернерсом-Ли (который в то время также работал в NCSA). Таким образом, формы были введены примерно в то же время, когда была изобретена CGI.

Изначально многие люди писали программы CGI на C. Я был одним из тех, кому приходилось делать это в качестве домашнего задания. Вместо гигантского всеобъемлющего фреймворка мы написали небольшие программы на C, которые читают из стандартного ввода и выводят на стандартный вывод (мы печатали HTTP-ответ, а не только HTML согласно спецификации CGI). На веб-сайте было множество этих небольших программ, каждая из которых выполняла одну мелочь и обновляла некоторую базу данных (иногда эта база данных была просто плоским файлом).

Почти сразу после его появления люди также начали писать сценарии CGI на Perl. Так что переходного периода между программами на C и языками сценариев действительно не было. Люди просто перестали писать сценарии CGI на C, потому что это было быстрее на языках сценариев.

— slebetman
источник

4

Отличный ответ от вас и от @Dekel. Эти ответы и предлагаемые ссылки действительно восполняют пробел. Я не могу не задаться вопросом, сколько веб-сайтов действительно беспокоились о реализации чего-либо из этого, прежде чем такие технологии, как JS, Perl, PHP, были доступны для веб-сценариев. Но это вопрос другого дня.

— Джеймс Джонс

15

@JamesJones, многие из нас это сделали. Начать работу было не так уж и сложно, хотя инструментов для масштабирования до крупных и высокопроизводительных веб-приложений не хватало. Я прочитал " Программирование CGI" во всемирной паутине в конце 90-х и начал писать все виды кода CGI еще подростком.

— Дэн Ленски,

12

На самом деле, простую программу CGI очень легко написать. Просто распечатайте несколько статических заголовков и немного HTML с вкраплениями ваших данных. Просто технология (HTML, смешанный с заголовками, смешанный с кодом ...) плохо масштабируется для сложных приложений. Отсюда и были придуманы рамки ...

— sleske

12

Если вы все еще хотите увидеть CGI в действии, попробуйте расписание швейцарских железных дорог: sbb.ch - введите место отправления и назначения - нажмите красную кнопку - затем взгляните на URL-адрес в браузере, особенно на часть query.exe: -)

— theDmi

8

Что касается того, «насколько это было распространено»: что ж, тогда гораздо больше веб-сайтов были полностью статичными. Но двумя часто встречающимися частями активного контента были «гостевые книги» (устаревшие из-за блогов / социальных сетей / спама) и «счетчики посещений».

— pjc50

70

Серверная сторона всегда была на виду.

Apache HTTP Server был доступен с 1995 года, а в 1996 году он также имел поддержку Perl (который был использован в качестве серверного языка программирования).

JavaScript был создан в 1996 году, и Netscape был первым браузером, поддерживающим клиентский язык (реализации других поставщиков браузеров основывались на работе, проделанной в Netscape).

В 1993 году был выпущен браузер Mosaic с поддержкой изображений, вложенных списков и форм для заполнения.

По сути, каждый HTTP-сервер, который может обрабатывать запрос и передавать его какому-либо приложению (независимо от того, на каком языке написано это приложение) является серверным приложением. Он может быть написан на языке сценариев (Perl / Python / PHP / Ruby), языке высокого уровня (Java / C #) и, если хотите, даже на ассемблере. Все, что вам нужно сделать, это убедиться, что вы «следуете протоколу».

— Декель
источник

1

Хорошая история. Upvoted. Однако формы были реализованы до 1995 года. Я не могу понять, когда именно, но в en.wikipedia.org/wiki/HTML есть

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

ваш последний абзац, описывающий практики до 1995 года?

— Джеймс Джонс

3

@JamesJones: Проверьте запись в Википедии на Common Gateway Interface

— slebetman

2

@JamesJones, добавил некоторую информацию о браузере мозаики и формах для заполнения. У вас также есть отличный ответ от Slebetman по поводу CGI.

— Dekel

1

Стандарты @JamesJones не являются четкими, и они полностью применимы ко многим вещам в Интернете (но не в Интернете в целом). Стандарт HTML был (и действительно остается) ужасным, и каждый создавал свои собственные расширения. Самыми известными были Mosaic, Netscape и Internet Explorer - большинство их расширений были добавлены к более поздним стандартам HTML, при этом Netscape и IE в значительной степени сотрудничали в этом. imgТогда в HTML даже не было встроенных изображений ( ) - автор посчитал это неподходящим для идеи гипертекста; только успех Mosaic / Netscape заставил изменить стандарт.

— Луаан

3

Этот ответ не обязательно ошибочен, но я не совсем уверен, как вещи, представленные по крайней мере через 2-3 года после того, как формы были доступны в браузере, свидетельствует о том, что всегда была поддержка форм на стороне сервера.

— 8bittree

1

JavaScript не был таким продвинутым (черт возьми, Ajax еще даже не вышел). Так что это была чисто серверная часть. В основном CGI (являющийся Perl) и PHP.

Был еще Coldfusion, но он не пользовался популярностью.

В конце концов, в конце 1999 и начале 2000-х годов появились ASP.NET (aspx) и JavaServer Pages (jsp), хотя многие коммерческие сайты использовали aspx и jsp по очевидным причинам.

Обратите внимание, что Java-апплеты также существовали (в основном для визуализации), но их нужно было отдельно загружать и поддерживать браузером.

— TFont
источник

3

Собственно, я программировал ASP к началу 1998 года. До этого существовал другой стандарт MS, называемый htxшаблонами.

— Little Santi

1

^ звучит так, будто вы были одним из первых! Давным-давно дружище! : D: D

— tfont 02

1

Вдобавок я наткнулся на интересную историю в Википедии. HTML-формы также можно отправлять по электронной почте, используя mailto:адрес в targetатрибуте. Не показалось популярным, но все равно круто!

Цитата из статьи в Википедии :

Поддержка пользовательского агента для отправки HTML-форм на основе электронной почты с использованием URL-адреса mailto в качестве действия формы была предложена в разделе 5.6 RFC 1867 в эпоху HTML 3.2. Различные веб-браузеры реализовали это, вызывая отдельную программу электронной почты или используя свои собственные элементарные возможности SMTP. Хотя иногда он был ненадежным, он некоторое время пользовался популярностью как простой способ передачи данных формы без использования веб-сервера или сценариев CGI.

И RFC 1867 (ноябрь 1995 г.):

5.6 Разрешить форме ACTION быть "mailto:"

Независимо от этого предложения для
пользовательских агентов, интерпретирующих HTML, было бы очень полезно разрешить ACTION в форме быть
URL-адресом mailto :. Это кажется хорошей идеей, с этим
предложением или без него . Точно так же ДЕЙСТВИЕ для HTML-формы, полученной по почте, вероятно, по умолчанию должно быть «reply-to:» сообщения.
Эти два предложения позволили бы HTML-формам обслуживаться через HTTP-
серверы, но отправлять их обратно по почте, или, в качестве альтернативы, позволяли бы HTML-формы
отправляться по почте, заполнять их получателями почты, поддерживающими HTML, и отправлять результаты по почте.

— Батист Канделье
источник