Como os formulários HTML eram interpretados no início dos anos 90?

109

Na web moderna, um <form>elemento HTML é enviado e então interpretado por script. Ou é interpretado por uma linguagem de programação do lado do servidor (geralmente PHP) ou é interpretado por um script do lado do cliente (quase sempre JavaScript).

Os formulários existiam mesmo no início dos anos 90. Como eles foram interpretados naquela época?

De acordo com este artigo da Wikipedia, havia um envio de formulário HTML baseado em e-mail naquela época, mas não era confiável. Isso era tudo que existia? Por que o HTML ainda tinha formulários se eles eram tão inúteis sem scripts? Ou era uma situação do tipo ovo e galinha?

html forms

— James Jones
fonte

25

usei perl com cgi

67

Sempre havia scripts do lado do servidor

— OrangeDog

22

Para completar o quadro, alguns dos primeiros formulários usados action="mailto:staff@example.com"diziam a um navegador da web para iniciar um cliente de e-mail e transferir os campos enviados como o conteúdo bruto de um novo e-mail. Programação zero, apenas alguns funcionários para processar os e-mails manualmente.

— kubanczyk

2

Antes mesmo dos formulários havia <ISINDEX>, que muitas vezes era conectado a um servidor WAIS .

— zwol

182

Antes dos scripts do lado do servidor (PHP, Ruby, node.js), havia a programação do lado do servidor.

Uma das interfaces originais entre servidores web e processos de back-end era a Common Gateway Interface (CGI). Ele foi introduzido no início dos anos 90 pela equipe de back-end do NCSA ao mesmo tempo em que os formulários foram introduzidos no HTML por Tim Berners-Lee (que também estava no NCSA na época). Portanto, os formulários foram introduzidos aproximadamente na mesma época em que o CGI foi inventado.

Inicialmente, muitas pessoas escreveram programas CGI em C. Eu fui um dos que tiveram que fazer isso como dever de casa. Em vez de uma estrutura abrangente e gigante, escrevemos pequenos programas C que lêem de stdin e imprimem em stdout (imprimimos uma resposta HTTP, não apenas o HTML de acordo com as especificações CGI). Um site tinha muitos desses pequenos programas, cada um fazendo uma pequena coisa e atualizando algum banco de dados (às vezes esse banco de dados era apenas um arquivo simples).

Quase assim que foi apresentado, as pessoas também começaram a escrever scripts CGI em Perl. Portanto, não houve realmente nenhum período de transição entre os programas C e as linguagens de script. As pessoas simplesmente pararam de escrever scripts CGI em C porque era mais rápido fazê-lo em linguagens de script.

— slebetman
fonte

4

Ótima resposta de você e de @Dekel. Essas respostas e os links sugeridos realmente preenchem a lacuna. Não posso deixar de me perguntar quantos sites realmente se preocuparam em implementar qualquer uma dessas coisas antes que tecnologias como JS, Perl, PHP estivessem disponíveis para scripts da web. Mas essa é uma pergunta para outro dia.

— James Jones

15

@JamesJones, muitos e muitos de nós . Não foi tão difícil começar, embora faltem as ferramentas para aumentar a escala para aplicativos da web grandes e de alto desempenho. Eu li Programação CGI na World Wide Web no final dos anos 90 e comecei a escrever todos os tipos de código CGI quando adolescente.

— Dan Lenski

12

Na verdade, um programa CGI básico é muito fácil de escrever. Basta imprimir alguns cabeçalhos estáticos e algum HTML com seus dados intercalados. Só que a tecnologia (HTML misturado com cabeçalhos misturados com código ...) não se adapta bem a aplicativos complexos. Conseqüentemente, os frameworks foram inventados ...

— sleske,

12

Se você ainda deseja ver o CGI em ação, experimente a tabela de horários da ferrovia suíça: sbb.ch - insira um local de partida e de destino - pressione o botão vermelho - então dê uma olhada no URL no navegador, especialmente a parte query.exe: -)

— theDmi

8

Em relação a "quão difundido era": bem, muitos outros sites eram completamente estáticos naquela época. Mas os dois bits comumente vistos de conteúdo ativo eram "livros de visitas" (obsoletos por blogs / mídias sociais / spam) e "contadores de visitas".

— pjc50

70

O lado do servidor estava sempre presente.

O Apache HTTP Server estava disponível desde 1995 e, em 1996, também tinha suporte a Perl (que era usado como uma linguagem de programação do lado do servidor).

O JavaScript foi criado em 1996 e o Netscape foi o primeiro navegador com suporte para a linguagem do lado do cliente (as implementações de outros fornecedores de navegadores foram baseadas no trabalho feito no Netscape).

Em 1993, o navegador Mosaic é lançado com suporte para imagens, listas aninhadas e formulários de preenchimento.

Basicamente - todo servidor HTTP que pode manipular a solicitação e passá-la para algum aplicativo (não importa em que idioma o aplicativo foi escrito) é um aplicativo do lado do servidor. Pode ser escrito em linguagem de script (Perl / Python / PHP / Ruby), linguagem de alto nível (Java / C #) e se você realmente quiser - até mesmo assembly. Tudo que você precisa fazer é certificar-se de "seguir o protocolo".

— Dekel
fonte

1

Boa história. Votado. No entanto, os formulários foram implementados antes de 1995. Não consigo descobrir exatamente quando, mas em en.wikipedia.org/wiki/HTML há

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

Seu último parágrafo descrevendo práticas antes de 1995?

— James Jones

3

@JamesJones: Verifique a entrada da Wikipédia em Common Gateway Interface

— slebetman

2

@JamesJones, adicionou algumas informações sobre o Mosaic Browser e formulários de preenchimento. Você também tem uma ótima resposta do slebetman sobre CGI.

— Dekel

1

Os padrões da @JamesJones não são claros e se aplicam totalmente à maioria das coisas na web (embora não à Internet como um todo). O padrão HTML era (e realmente ainda é) horrível, e todos criaram suas próprias extensões. Mosaic, Netscape e Internet Explorer foram os mais notórios - a maioria de suas extensões foram adicionadas aos padrões HTML posteriores, com Netscape e IE colaborando bastante nisso. Na imgépoca, o HTML nem tinha imagens embutidas ( ) - o autor considerou-o inadequado à ideia de hipertexto; apenas o sucesso do Mosaic / Netscape forçou a mudança no padrão.

— Luaan

3

Essa resposta não está necessariamente errada, mas não tenho certeza de como as coisas foram introduzidas pelo menos 2 a 3 anos após os formulários estarem disponíveis no navegador é uma evidência de que sempre houve suporte do lado do servidor para formulários.

— 8bittree

1

JavaScript não era tão avançado (o Ajax ainda nem tinha sido lançado). Portanto, era apenas do lado do servidor. Principalmente CGI (sendo Perl) e PHP.

Também havia Coldfusion, mas não era um favorito popular.

Eventualmente, no final de 1999 e no início dos anos 2000, ASP.NET (aspx) e JavaServer Pages (jsp) foram lançados, embora muitos sites comerciais usassem aspx e jsp por razões óbvias.

Observe que os miniaplicativos Java também existiam (principalmente para renderização), mas tinham que ser baixados separadamente e suportados pelo navegador.

— tfont
fonte

3

Na verdade, eu programava ASPs no início de 1998. Antes disso, havia outro padrão MS chamado htxmodelos.

— Little Santi

1

^ parece que você foi um dos originais! Há muito tempo, companheiro! : D: D

— tfont

1

Além disso, descobri um pedaço interessante da história na Wikipedia. Os formulários HTML também podem ser enviados por e-mail, usando um mailto:endereço no targetatributo. Não parecia ser popular, mas ainda assim legal!

Citando o artigo da Wikipedia :

O suporte de agente de usuário para envio de formulário HTML baseado em e-mail, usando um URL 'mailto' como ação do formulário, foi proposto na RFC 1867, seção 5.6, durante a era HTML 3.2. Vários navegadores da web o implementaram invocando um programa de e-mail separado ou usando seus próprios recursos rudimentares de SMTP. Embora às vezes não seja confiável, foi brevemente popular como uma maneira simples de transmitir dados de formulário sem envolver um servidor da web ou scripts CGI.

E RFC 1867 (novembro de 1995):

5.6 Permitir que o formulário ACTION seja "mailto:"

Independentemente desta proposta, seria muito útil para
agentes de usuário interpretadores de HTML permitir que uma AÇÃO em um formulário fosse um
URL "mailto:". Parece uma boa ideia, com ou sem esta
proposta. Da mesma forma, a AÇÃO para um formulário HTML que é recebido por correio provavelmente deve ser padronizado como "responder para:" da mensagem.
Essas duas propostas permitiriam que formulários HTML fossem servidos por
servidores HTTP , mas devolvidos por correio, ou, alternativamente, permitiriam que formulários HTML
fossem enviados por correio, preenchidos por destinatários de correio que entendiam de HTML e os resultados devolvidos.

— Baptiste Candellier
fonte