¿Cómo se interpretaron los formularios HTML a principios de los 90?

109

En la web moderna, <form>se envía un elemento HTML y luego se interpreta mediante secuencias de comandos. O es interpretado por un lenguaje de programación del lado del servidor (generalmente PHP) o es interpretado por un script del lado del cliente (casi siempre JavaScript).

Las formas existían incluso a principios de los 90. ¿Cómo se interpretaron entonces?

Según este artículo de Wikipedia, en ese entonces había un envío de formulario HTML basado en correo electrónico, pero no era confiable. ¿Era esto todo lo que había? ¿Por qué HTML incluso tenía formularios si eran tan inútiles sin secuencias de comandos? ¿O fue una especie de situación del huevo y la gallina?

html forms James Jones
fuente
25
67
Siempre hubo secuencias de comandos del lado del servidor
OrangeDog
22
Para completar la imagen, se utilizaron algunos formularios iniciales action="mailto:[email protected]"que le indicaban a un navegador web que iniciara un cliente de correo electrónico y transfiriera los campos enviados como el contenido básico de un nuevo correo electrónico. Programación cero, solo algo de personal para procesar los correos electrónicos a mano.
kubanczyk
2
Antes de los formularios, incluso existía <ISINDEX>, que a menudo se conectaba a un servidor WAIS .
zwol

Respuestas:

182

Antes de las secuencias de comandos del lado del servidor (PHP, Ruby, node.js) existía la programación del lado del servidor.

Una de las interfaces originales entre los servidores web y los procesos de back-end fue la Common Gateway Interface (CGI). Fue introducido a principios de los 90 por el equipo de back-end de NCSA al mismo tiempo que los formularios fueron introducidos en HTML por Tim Berners-Lee (quien también estaba en NCSA en ese momento). Así que las formas se introdujeron aproximadamente al mismo tiempo que se inventó CGI.

Al principio, mucha gente escribía programas CGI en C. Yo era uno de los que tenía que hacerlo como tarea. En lugar de un marco gigante que lo abarca todo, escribimos pequeños programas en C que leen desde stdin e imprimen en stdout (imprimimos la respuesta HTTP, no solo el HTML según la especificación CGI). Un sitio web tenía muchos de estos pequeños programas, cada uno haciendo una pequeña cosa y actualizaba alguna base de datos (a veces esa base de datos era solo un archivo plano).

Casi tan pronto como se presentó, la gente también comenzó a escribir scripts CGI en Perl. Así que realmente no hubo un período de transición entre los programas C y los lenguajes de script. La gente simplemente dejó de escribir scripts CGI en C porque era más rápido hacerlo en lenguajes de script.

slebetman
fuente
4
Gran respuesta tanto de ti como de @Dekel. Estas respuestas y los enlaces sugeridos realmente llenan el vacío. No puedo evitar preguntarme cuántos sitios web realmente se molestaron en implementar cualquiera de estas cosas antes de que tecnologías como JS, Perl, PHP estuvieran disponibles para la creación de scripts web. Pero esa es una pregunta para otro día.
James Jones
15
@JamesJones, muchos , muchos de nosotros lo hicimos. No fue tan difícil comenzar, aunque faltaban las herramientas para escalar a aplicaciones web grandes y de alto rendimiento. Leí Programación CGI en la World Wide Web a finales de los 90 y comencé a escribir todo tipo de código CGI cuando era adolescente.
Dan Lenski
12
En realidad, un programa CGI básico es muy fácil de escribir. Simplemente imprima algunos encabezados estáticos y algo de HTML con sus datos intercalados. Es solo que la tecnología (HTML mezclado con encabezados mezclados con código ...) no se adapta bien a aplicaciones complejas. Por lo tanto, se inventaron los marcos ...
sleske
12
Si aún desea ver CGI en acción, pruebe el horario de trenes suizos: sbb.ch - ingrese una ubicación de salida y destino - presione el botón rojo - luego eche un vistazo a la URL en el navegador, especialmente la parte query.exe: -)
theDmi
8
En cuanto a "qué tan extendido estaba": bueno, muchos más sitios web eran completamente estáticos en ese entonces. Pero los dos fragmentos de contenido activo comúnmente vistos eran "libros de visitas" (obsoletos por blogs / redes sociales / spam) y "contadores de visitas".
pjc50
70

El lado del servidor siempre estuvo en la imagen.

El servidor HTTP Apache estuvo disponible desde 1995, y en 1996 también tenía soporte Perl (que se usaba como lenguaje de programación del lado del servidor).

JavaScript se creó en 1996 y Netscape fue el primer navegador compatible con el lenguaje del lado del cliente (las implementaciones de otros proveedores de navegadores se basaron en el trabajo que se realizó en Netscape).

En 1993 se lanza el navegador Mosaic con soporte para imágenes, listas anidadas y formularios para completar.

Básicamente, cada servidor HTTP que pueda manejar solicitudes y pasarlas a alguna aplicación (sin importar en qué idioma esté escrita esa aplicación) es una aplicación del lado del servidor. Se puede escribir en lenguaje de scripting (Perl / Python / PHP / Ruby), lenguaje de alto nivel (Java / C #) y si realmente lo desea, incluso en ensamblaje. Todo lo que necesita hacer es asegurarse de "seguir el protocolo".

Dekel
fuente
1
Buena historia. Voto a favor. Sin embargo, los formularios se implementaron antes de 1995. No puedo averiguar cuándo, pero en en.wikipedia.org/wiki/HTML hay Dave Raggett's competing Internet-Draft, "HTML+ (Hypertext Markup Format)", from late 1993, suggested standardizing already-implemented features like tables and fill-out forms.¿Su último párrafo describe prácticas anteriores a 1995?
James Jones
3
@JamesJones: verifique la entrada de wikipedia en la interfaz de puerta de enlace común
slebetman
2
@JamesJones, agregó información sobre el navegador Mosaic y los formularios para completar. También tiene una gran respuesta de slebetman con respecto a CGI.
Dekel
1
Los estándares de @JamesJones no son claros y se aplican en su totalidad a la mayoría de las cosas en la web (aunque no a Internet en su conjunto). El estándar HTML era (y realmente sigue siendo) horrible, y todos crearon sus propias extensiones. Mosaic, Netscape e Internet Explorer fueron los más notorios: la mayoría de sus extensiones se agregaron a estándares HTML posteriores, con Netscape e IE cooperando bastante en eso. HTML ni siquiera tenía imágenes incrustadas ( img) en ese entonces; el autor lo consideró inadecuado para la idea de hipertexto; solo el éxito de Mosaic / Netscape forzó el cambio en el estándar.
Luaan
3
Esta respuesta no es necesariamente incorrecta, pero no estoy muy seguro de cómo las cosas introducidas al menos 2-3 años después de que los formularios estaban disponibles en el navegador es evidencia de que siempre ha habido soporte del lado del servidor para los formularios.
8bittree
1

JavaScript no era tan avanzado (demonios, Ajax ni siquiera había salido todavía). Así que fue puramente del lado del servidor. Mayormente CGI (siendo Perl) y PHP.

También estaba Coldfusion, pero no era un favorito popular.

Finalmente, a fines de 1999 y principios de la década de 2000, aparecieron ASP.NET (aspx) y JavaServer Pages (jsp), aunque muchos sitios comerciales usaban aspx y jsp por razones obvias.

Tenga en cuenta que los subprogramas de Java también existían (aunque principalmente para renderizar), pero el navegador tenía que descargarlos por separado y admitirlos.

tfont
fuente
3
De hecho, programé ASP a principios de 1998. Antes de eso, había otro estándar de MS llamado htxtemplates.
Little Santi
1
^ suena como si fueras uno de los originales! ¡Hace mucho tiempo amigo! : D: D
tfont
1

Además, me encontré con una interesante pieza de historia en Wikipedia. Los formularios HTML también se pueden enviar por correo electrónico, utilizando una mailto:dirección en el targetatributo. No parecía ser popular, ¡pero aún así es genial!

Citando el artículo de Wikipedia :

El soporte de agente de usuario para el envío de formularios HTML basados ​​en correo electrónico, utilizando una URL 'mailto' como la acción del formulario, se propuso en la sección 5.6 de RFC 1867, durante la era HTML 3.2. Varios navegadores web lo implementaron invocando un programa de correo electrónico separado o utilizando sus propias capacidades SMTP rudimentarias. Aunque a veces no es confiable, fue brevemente popular como una forma simple de transmitir datos de formularios sin involucrar un servidor web o scripts CGI.

Y RFC 1867 (noviembre de 1995):

5.6 Permitir que el formulario ACTION sea "mailto:"

Independientemente de esta propuesta, sería muy útil para
los agentes de usuario de interpretación HTML permitir que una ACCIÓN en un formulario sea una
URL "mailto:". Parece una buena idea, con o sin esta
propuesta. De manera similar, la ACCIÓN para un formulario HTML que se recibe por correo probablemente debería ser el predeterminado "responder a:" del mensaje.
Estas dos propuestas permitirían que los formularios HTML se sirvan a través de
servidores HTTP pero se envíen por correo, o, alternativamente, permitirían que los formularios HTML
se envíen por correo, que los llenen los destinatarios de correo con conocimiento de HTML y que los resultados se envíen por correo.

Baptiste Candellier
fuente