Um formulário HTML é um trecho de fonte HTML que contém uma série de “campos” (variáveis do formulário), com indicações sobre o tipo de dados do campo e de como ele pode ser apresentado (uma janela de edição, uma série de “botões de rádio”, uma série de “chaves liga/desliga”, etc.).
A responsabilidade por apresentar e permitir a edição é da aplicação cliente HTTP (Netscape ou Internet Explorer por exemplo). Quando o usuário termina de alterar os dados do formulário, estes dados são passados para o servidor remoto através de uma técnica que codifica os dados do formulário numa URL.
7.1. Métodos Aplicáveis
A técnica de codificação na URL, está definida na seção 8.2.1 da RFC 1866 que especifica a HTML 2.0. Dois métodos do HTTP podem ser usados para passar as informações de formulários: GET e POST. O método GET é usado quando o formulário está sendo preenchido para consultar informações numa base de dados, ou seja, quando as informações contidas neste formulário não serão armazenadas no servidor, elas somente servirão para encontrar, localizar ou obter outras informações.
Por outro lado quando as informações contidas no formulário deverão ser armazenadas no servidor remoto, então deve-se usar o método POST. Neste caso as informações continuarão codificadas numa URL, porém esta URL não será usada como parte da URI da requisição, mas será enviada separadamente como corpo da entidade da requisição.
No caso do GET a URI deve ter o seguinte formato:
<script-cgi-a-ser-executado-no-servidor> ‘?’ <informações-do-formulários-codificadas-em-URL> No caso do POST á URI é mais simples contendo apenas o:
<script-cgi-a-ser-executado-no-servidor> Porém o corpo da entidade deve conter as:
<informações-do-formulários-codificadas-em-URL>
7.2. Algoritmo de Codificação
A codificação é feita de forma há não haver nenhum caracter de espaço na URL. Isto é feito em dois passos:
1. Primeiro todos os nomes de campos do formulário com seus respectivos valores são alterados de forma a que todos os caracteres problemáticos sejam substituidos por sequências de escape:
(1.a) Todos os caracteres espaço em branco (‘ ’) são substituidos pelo caracter ‘+’; (1.b) Todos os caracteres que não são letras nem dígitos são substituidos pela sequência
‘%HH’, formada por um caracter de percento (‘%’) seguido por dois dígitos
hexadecimais representando o código ASCII do caracter. Mesmo linhas em branco que estejam, por exemplo, dentro de valores de campos de formulários são substituidos por sequências de escape, no caso por ‘%0D%0A’.
2. Depois os campos são listadas na ordem em que aparecem no formulário HTML, primeiro o nome do campo e depois o valor do campo. O caracter de igualdade (‘=’) separa o nome do valor do campo. Os campos são separados por um caracter ‘&’. Os campos que tem valores nulos no formulário podem ser omitidos.
7.3. Exemplo
Por exemplo, supondo um formulário que possua os seguintes campos com seus respectivos valores
default: Campo Valor Nome “” sexo “masculino” familiares “” cidade “” apelido “”
Após este formulário ter sido apropriadamente apresentado e editado pelo usuário, os valores deste campo são modificados para:
Campo Valor
nome “Jose da Silva”
sexo “masculino” familiares “5”
cidade “Porto Alegre”
apelido “Seu Ze”
A URL codificando estes dados de formulário fica assim:
nome=Jose+da+Silva&sexo=masculino&familiares=5&cidade=Porto+Alegre&apelido=Seu+Ze
7.4. Sugestões de Trabalhos
7.4.1. Implementação do Tratamento de Formulários e CGI no WebServ
O servidor WebServ não suporta o tratamento de formulários. De acordo com a RFC 1866, os formulários são tratados, no lado do servidor, através de um processo composto de três grandes etapas:
(a) Decodificação dos campos do formulário, que estão codificados dentro da URL da requisição numa lista de nomes de variáveis do formulário com seus respectivos valores.
(b) Ativação de uma aplicação externa que irá tratar esta requisição de formulário. O nome da aplicação a ser executada já vem codificada na URL e os parâmetros são passados para esta aplicação por meio de um protocolo especial para isto. Geralmente se usa o protocolo CGI (sigla para Common Gateway
Interface), que opera através de variáveis de ambiente de execução, para passar estes parâmetros nos
servidores comerciais.
(c) Execução da aplicação externa. Esta aplicação busca as varíaveis, juntamente com seus valores, através de um protocolo padrão para troca de informações com o servidor HTTP (normalmente o CGI como já comentado antes). Todos os dados gerados por esta aplicação e colocados no arquivo de saída padrão (arquivo stdout da linguagem C) são automaticamente enviados para o cliente remoto, isto é, os dados gerados pela aplicação externa são a resposta da requisição. É por isto que, normalmente, deve-se formatar a saída de um programa CGI de acordo com a linguagem HTML. Na implementação do WebServ não se está solicitando que seja usado o protocolo CGI, nem que a saída padrão (stdout) seja redirecionada para o socket conectado ao cliente remoto. A implementação de formulários e aplicações externas deve atender as seguintes especificações:
Quando um requisição HTTP conter uma submissão de formulário codificada em URL, a lista das variáveis com seus valores deve ser decodificada e colocada num arquivo de texto. Cada linha deste arquivo deve ter o seguinte formato:
<nome-da-variável> ‘=’ <valor-da-variável> CRLF
Cada linha indicará, então, o nome e o valor da variável para aquela consulta (requisição). A primeira linha em branco (que contém apenas um CRLF ou uma combinação de brancos, TABs e o CRLF, indicará o fim da lista de variáveis.
Após esta decodificação ter sido feita com sucesso, o servidor WebServ irá executar a aplicação externa. Todas as aplicações externas usam apenas dois parâmetros na linha de comando:
• o primeiro parâmetro <arq-lista-var> contém o nome do arquivo com a lista de variáveis,
• o segundo parâmetro <arq-resp-html> contém o nome do arquivo que irá conter a página HTML resultante da consulta.
A aplicação externa deverá consultar o arquivo <arq-lista-var> quando precisar saber o valor de alguma variável. Tudo o que deve ser enviado para o cliente remoto deve ser armazenado no arquivo <arq-resp- html>.
Quando o servidor WebServ detectar que a aplicação externa terminou de executar, ele abre o arquivo <arq-resp-html> e o envia para o cliente remoto (durante todo o tempo da execução da aplicação externa o socket com o cliente remoto foi mantido aberto, mas sem nenhum dado sendo enviado).
A aplicação externa tanto pode ser um programa executável previamente compilado, quanto pode ser um programa em batch no caso do DOS/Windows ou um programa shell no caso do Unix / Linux.
7.4.2. Implementação de páginas ativas no WebServ
O conceito de páginas ativas no lado do servidor é extremamente importante para se flexibilizar a operação deste servidor de forma a poder atender o maior tipo de aplicações e usos possíveis. Existem diversos tipos de linguagens e técnicas sendo atualmente disponibilizadas para implementar este tipo de página nos servidores HTTP comerciais. Por exemplo o servidor Apache, que detém aproximadamente 60 % do mercado, usa a linguagem PHP implantada diretamente dentro das páginas HTML para implementar este conceito, já a Microsoft dá prioridade a linguagem ASP (uma versão de Basic Microsoft) para este mesmo fim e por último, existe um movimento que está tomando força de se usar um derivado da linguagem Java, a JSP como padrão para páginas ativas.
O WebServ obviamente não implementa nenhum tipo de página ativa. A sugestão de trabalho aqui é incorporar a ele uma linguagem bem simplificada mas que demonstra claramente os conceitos mais importantes de programação de páginas ativas.
Para tanto serão usadas algumas extensões do HTML, que somente terão sentido quando interpretadas diretamente pelo servidor WebServ e que, conversamente, não deverão ter nenhum efeito quando recuperadas por algum outro tipo de servidor HTTP.
Para garantir isto as extensões serão definidas apenas como comentários HTML que somente o WebServ conhecerá e conseguirá interpretar e tratar, quanto aos demais servidore se espera que estes tipos de comentários sejam efetivamente inócuos.
Sendo assim todos os comandos da “linguagem” WSAP (WebServ Active Pages) estarão dentro de comentário HTML (que estão dentro de “<!-- “ e “ -->”) no seguinte formato:
<!-- WSAP: <comando> -->
Os comandos WSAP serão os seguintes:
<!-- WSAP: INCLUDE <nome-de-arquivo> -->
Este comando inclui o arquivo <nome-de-arquivo> a partir da linha seguinte do arquivo HTML/WSAP sendo processado. Somente apos todo o arquivo <nome-de-arquivo> ter sido inserido é que a próxima linha poderá ser continuar sendo processada. O arquivo inserido, mesmo que for HTML não deverá ser tratado como contendo extensões WSAP.
<!-- WSAP: IF <nome-de-arquivo> --> <!-- WSAP: ELSE -->
<!-- WSAP: ENDIF -->
Se o arquivo denominado por <nome-de-arquivo> existir então todas as linha que existirem logo após a linha do IF e até a linha do comando ENDIF ou do comando ELSE deverão ser processadas. Caso o arquivo não exista então estas linhas deverão ser ignoradas e somente as linhas após o ELSE ou o ENDIF
(o que vier primeiro) é que deverão ser tratadas. Na WSAP não é permitido o aninhamento de IFs, isto é, não existem IFs dentro de IFs.
<!-- WSAP: EXECUTE <nome-de-programa> <argumento-1> ... <argumento-n> -->
Executa o programa externo indicado por <nome-de-programa> com os parâmetros (que são opcionais) indicados por <argumento-1> ... <argumento-n>. O processamento da próxima linha do arquivo HTML/WSAP somente pode continuar após o fim da execução do programa externo.
<!-- WSAP: DELETE <nome-de-arquivo>