2. Noções básicas
Neste capítulo, apresentamos os fundamentos da programação web. Seu objetivo principal é apresentar os princípios básicos da programação web antes de colocá-los em prática com uma linguagem e um ambiente específicos. Ele traz diversos exemplos que recomendamos testar para, aos poucos, “absorver” a filosofia do desenvolvimento web.
2.1. Os componentes de uma aplicação web
Número | Função | Exemplos comuns |
OS Servidor | Linux, Windows | |
Servidor web | Apache (Linux, Windows) IIS (NT), PWS (Win9x) | |
Scripts executados no lado do servidor. Eles podem ser executados por módulos do servidor ou por programas externos ao servidor (CGI). | PERL (Apache, IIS, PWS) VBSCRIPT (IIS, PWS) JAVASCRIPT (IIS, PWS) PHP (Apache, IIS, PWS) JAVA (Apache, IIS, PWS) C#, VB.NET (IIS) | |
Banco de dados — Ele pode estar na mesma máquina que o programa que a utiliza ou em outra, via Internet. | Oracle (Linux, Windows) MySQL (Linux, Windows) Access (Windows) SQL Server (Windows) | |
OS Cliente | Linux, Windows | |
Navegador da Web | Netscape, Internet Explorer | |
Scripts executados no lado do cliente, dentro do navegador. Esses scripts não têm acesso aos discos do computador do usuário. | VBscript (IE) JavaScript (IE, Netscape) PerlScript (IE) Applets JAVA |
2.2. A troca de dados em um aplicativo web com formulário
Máquina cliente Máquina servidor
Número | Função |
O navegador solicita um URL pela primeira vez (http://machine/url). Nenhum parâmetro foi passado. | |
O servidor web envia a ele a página da web correspondente a esse URL. Ela pode ser estática ou gerada dinamicamente por um script de servidor (SA) que pode ter utilizado o conteúdo de bancos de dados (SB, SC). Nesse caso, o script detectará que o URL foi solicitado sem a passagem de parâmetros e gerará a página inicial WEB. O navegador recebe a página e a exibe (CA). Scripts do lado do navegador (CB) podem ter modificado a página inicial enviada pelo servidor. Em seguida, por meio de interações entre o usuário (CD) e os scripts (CB), a página da Web será modificada. Os formulários, em particular, serão preenchidos. | |
O usuário confirma os dados do formulário, que devem então ser enviados ao servidor web. O navegador solicita novamente o URL inicial ou outro, conforme o caso, e transmite ao mesmo tempo ao servidor os valores do formulário. Para isso, ele pode utilizar dois métodos chamados GET e POST. Ao receber a solicitação do cliente, o servidor aciona o script (SA) associado ao URL solicitado, script esse que detectará os parâmetros e os processará. | |
O servidor entrega a página WEB gerada pelo programa (SA, SB, SC). Esta etapa é idêntica à etapa 2 anterior. As trocas de dados ocorrem agora de acordo com as etapas 2 e 3. |
2.3. Alguns recursos
Abaixo, você encontrará uma lista de recursos que permitem instalar e utilizar certas ferramentas para o desenvolvimento web. No anexo, há um guia de instalação dessas ferramentas.
http://www.apache.org - Apache, Instalação e Implementação, O'Reilly | |
http://www.microsoft.com | |
http://www.activestate.com - Programação em Perl, Larry Wall, O'Reilly - Aplicações em Perl: CGI, Neuss e Vromans, O'Reilly - a documentação HTML fornecida com o Active Perl | |
http://www.php.net - Programação Web com PHP, Lacroix, Eyrolles - Manual do usuário do PHP, disponível no site do PHP | |
http://msdn.microsoft.com/scripting/vbscript/download/vbsdoc.exe http://msdn.microsoft.com/scripting/default.htm?/scripting/vbscript - Interface entre WEB e o banco de dados em WinNT, Alex Homer, Eyrolles | |
http://msdn.microsoft.com/scripting/jscript/download/jsdoc.exe http://developer.netscape.com/docs/manuals/index.html | |
http://developer.netscape.com/docs/manuals/index.html | |
http://www.sun.com - JAVA Servlets, Jason Hunter, O'Reilly - Programação de rede com Java, Elliotte Rusty Harold, O’Reilly - JDBC e Java, George Reese, O’Reilly | |
http://www.mysql.com http://www.oracle.com - O manual do MySQL está disponível no site do MySQL - Oracle 8i no Linux, Gilles Briard, Eyrolles - Oracle 8i no NT, Gilles Briard, Eyrolles |
2.4. Notações
Daqui em diante, vamos supor que algumas ferramentas já tenham sido instaladas e adotaremos as seguintes notações:
notação | significado |
raiz da árvore de diretórios do servidor Apache | |
raiz das páginas da Web servidas pelo Apache. É nessa raiz que as páginas da Web devem estar localizadas. Assim, o endereço URL http://localhost/page1.htm corresponde ao arquivo <apache-DocumentRoot>\page1.htm. | |
raiz da árvore de diretórios associada ao alias cgi-bin, onde é possível colocar scripts CGI para o Apache. Assim, o URL http://localhost/cgi-bin/test1.pl corresponde ao arquivo <apache-cgi-bin>\test1.pl. | |
raiz das páginas da Web geradas pelo PWS. É nessa raiz que as páginas da Web devem estar localizadas. Assim, o URL http://localhost/page1.htm corresponde ao arquivo <pws-DocumentRoot>\page1.htm. | |
raiz da árvore de diretórios do Perl. O executável perl.exe geralmente se encontra em <perl>\bin. | |
raiz da árvore da linguagem PHP. O executável php.exe geralmente se encontra em <php>. | |
raiz da árvore de diretórios do Java. Os executáveis relacionados ao Java estão localizados em <java>\bin. | |
raiz do servidor Tomcat. Exemplos de servlets podem ser encontrados em <tomcat>\webapps\examples\servlets e exemplos de páginas em JSP, em <tomcat>\webbapps\examples\jsp |
Para cada uma dessas ferramentas, consulte o apêndice, que fornece orientações para sua instalação.
2.5. Páginas da Web estáticas, páginas da Web dinâmicas
Uma página estática é representada por um arquivo HTML. Já uma página dinâmica é gerada “na hora” pelo servidor web. Neste parágrafo, propomos diversos testes com diferentes servidores web e diferentes linguagens de programação, a fim de demonstrar a universalidade do conceito da web.
2.5.1. Página estática HTML (Linguagem de Marcação HyperText)
Consideremos o seguinte código HTML:
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
que gera a seguinte página da web:
Os testes
-
iniciar o servidor Apache
-
colocar o script essai1.html em <apache-DocumentRoot>
-
visualizar o URL http://localhost/essai1.html em um navegador
-
desligar o servidor Apache
-
iniciar o servidor PWS
-
inserir o script essai1.html no <pws-DocumentRoot>
-
visualizar o URL http://localhost/essai1.html com um navegador
2.5.2. Uma página ASP (Active Server Pages)
O script essai2.asp:
<html>
<head>
<title>essai 1 : une page asp</title>
</head>
<body>
<center>
<h1>Une page asp générée dynamiquement par le serveur PWS</h1>
<h2>Il est <% =time %></h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
gera a seguinte página da web:
O teste
-
inicie o servidor PWS
-
inserir o script essai2.asp no <pws-DocumentRoot>
-
acessar o URL http://localhost/essai2.asp com um navegador
2.5.3. Um script PERL (Practical Extracting and Reporting Language)
O script essai3.pl:
#!d:\perl\bin\perl.exe
($secondes,$minutes,$heure)=localtime(time);
print <<HTML
Content-type: text/html
<html>
<head>
<title>essai 1 : un script Perl</title>
</head>
<body>
<center>
<h1>Une page générée dynamiquement par un script Perl</h1>
<h2>Il est $heure:$minutes:$secondes</h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
HTML
;
A primeira linha é o caminho do executável perl.exe. É preciso ajustá-lo, se necessário. Uma vez executado por um servidor web, o script gera a seguinte página:
O teste
-
servidor web: Apache
-
para informações, consulte o arquivo de configuração srm.conf ou httpd.conf, dependendo da versão do Apache, em <apache>\confs e procure a linha que menciona cgi-bin para identificar o diretório <apache-cgi-bin> no qual deve ser colocado o arquivo essai3.pl.
-
coloque o script essai3.pl no diretório <apache-cgi-bin>
-
acesse a URL http://localhost/cgi-bin/essai3.pl
Observe que leva mais tempo para carregar a página perl do que a página asp. Isso ocorre porque o script Perl é executado por um interpretador de Perl que precisa ser carregado antes que o script possa ser executado. Ele não permanece permanentemente na memória.
2.5.4. Um script PHP (Página Pessoal)
O script essai4.php
<html>
<head>
<title>essai 4 : une page php</title>
</head>
<body>
<center>
<h1>Une page PHP générée dynamiquement</h1>
<h2>
<?
$maintenant=time();
echo date("j/m/y, h:i:s",$maintenant);
?>
</h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
O script anterior gera a seguinte página da web:
Os testes
-
consulte o arquivo de configuração srm.conf ou httpd.conf do Apache em <Apache>\confs
-
para informação, verifique as linhas de configuração de php
-
inicie o servidor Apache
-
inserir essai4.php em <apache-DocumentRoot>
-
solicitar o URL http://localhost/essai4.php
-
iniciar o servidor PWS
-
para informação, verificar a configuração do PWS em relação ao PHP
-
inserir o essai4.php no <pws-DocumentRoot>\php
-
solicitar o URL http://localhost/essai4.php
2.5.5. Um script JSP (Java Server Pages)
O script heure.jsp
<% //programa em Java que exibe a hora %>
<%@ page import="java.util.*" %>
<%
// código JAVA para calcular a hora
Calendar calendrier=Calendar.getInstance();
int heures=calendrier.get(Calendar.HOUR_OF_DAY);
int minutes=calendrier.get(Calendar.MINUTE);
int secondes=calendrier.get(Calendar.SECOND);
// horas, minutos e segundos são variáveis globais
// que poderão ser utilizadas no código HTML
%>
<% // código HTML %>
<html>
<head>
<title>Page JSP affichant l'heure</title>
</head>
<body>
<center>
<h1>Une page JSP générée dynamiquement</h1>
<h2>Il est <%=heures%>:<%=minutes%>:<%=secondes%></h2>
<br>
<h3>A chaque fois que vous rechargez la page, l'heure change</h3>
</body>
</html>
Uma vez executado pelo servidor web, este script gera a seguinte página:
Os testes
- coloque o script heure.jsp em <tomcat>\jakarta-tomcat\webapps\examples\jsp (Tomcat 3.x) ou em <tomcat>\webapps\examples\jsp (Tomcat 4.x)
- Inicie o servidor Tomcat
- acesse o URL em http://localhost:8080/examples/jsp/heure.jsp
2.5.6. Conclusão
Os exemplos anteriores mostraram que:
- uma página HTML pode ser gerada dinamicamente por um programa. Esse é o próprio sentido da programação web.
- as linguagens e os servidores web utilizados podem ser diversos. Atualmente, observam-se as seguintes grandes tendências:
- as combinações Apache/PHP (Windows, Linux) e IIS/PHP (Windows)
- a tecnologia ASP.NET em plataformas Windows, que associam o servidor IIS a uma linguagem .NET (C#, VB.NET, ...)
- a tecnologia de servlets Java e páginas JSP que funcionam com diferentes servidores (Tomcat, Apache, IIS) e em diferentes plataformas (Windows, Linux). É essa última tecnologia que será abordada mais detalhadamente neste documento.
2.6. Scripts do lado do navegador
Uma página HTML pode conter scripts que serão executados pelo navegador. Existem diversas linguagens de script do lado do navegador. Aqui estão algumas delas:
Linguagem | Navegadores compatíveis |
VBScript | IE |
JavaScript | IE, Netscape |
PerlScript | IE |
Java | IE, Netscape |
Vejamos alguns exemplos.
2.6.1. Uma página da Web com um script VBScript, executado no navegador
A página vbs1.html
<html>
<head>
<title>essai : une page web avec un script vb</title>
<script language="vbscript">
function reagir
alert "Vous avez cliqué sur le bouton OK"
end function
</script>
</head>
<body>
<center>
<h1>Une page Web avec un script VB</h1>
<table>
<tr>
<td>Cliquez sur le bouton</td>
<td><input type="button" value="OK" name="cmdOK" onclick="reagir"></td>
</tr>
</table>
</body>
</html>
A página HTML acima não contém apenas o código HTML, mas também um programa destinado a ser executado pelo navegador que carregar essa página. O código é o seguinte:
<script language="vbscript">
function reagir
alert "Vous avez cliqué sur le bouton OK"
end function
</script>
As tags <script></script> servem para delimitar os scripts na página HTML. Esses scripts podem ser escritos em diferentes linguagens, e é a opção language da tag <script> que indica a linguagem utilizada. Neste caso, é VBScript. Não entraremos em detalhes sobre essa linguagem. O script acima define uma função chamada réagir que exibe uma mensagem. Quando essa função é chamada? É a seguinte linha de código HTML que nos indica isso:
O atributo onclick indica o nome da função a ser chamada quando o usuário clicar no botão OK. Quando o navegador carregar essa página e o usuário clicar no botão OK, teremos a seguinte página:
Os testes
Apenas o navegador IE é capaz de executar scripts VBScript. O Netscape requer complementos de software para fazer isso. É possível realizar os seguintes testes:
-
servidor Apache
-
script vbs1.html no <apache-DocumentRoot>
-
acessar a URL http://localhost/vbs1.html com o navegador IE
-
servidor PWS
-
script vbs1.html no <pws-DocumentRoot>
-
acessar a URL http://localhost/vbs1.html com o navegador IE
2.6.2. Uma página da Web com um script JavaScript, no lado do navegador
A página: js1.html
<html>
<head>
<title>essai 4 : une page web avec un script Javascript</title>
<script language="javascript">
function reagir(){
alert ("Vous avez cliqué sur le bouton OK");
}
</script>
</head>
<body>
<center>
<h1>Une page Web avec un script Javascript</h1>
<table>
<tr>
<td>Cliquez sur le bouton</td>
<td><input type="button" value="OK" name="cmdOK" onclick="reagir()"></td>
</tr>
</table>
</body>
</html>
Temos aqui algo idêntico à página anterior, com a diferença de que substituímos a linguagem VBScript pela linguagem JavaScript. Esta tem a vantagem de ser aceita pelos dois navegadores, IE e Netscape. Sua execução produz os mesmos resultados:
Os testes
-
servidor Apache
-
script js1.html no <apache-DocumentRoot>
-
acessar a URL http://localhost/js1.html com o navegador IE ou Netscape
-
servidor PWS
-
script js1.html no <pws-DocumentRoot>
-
acesse a URL http://localhost/js1.html usando o navegador IE ou o Netscape
2.7. As interações cliente-servidor
Voltemos ao nosso esquema inicial, que ilustrava os participantes de uma aplicação web:
 |
Aqui, estamos interessados nas trocas entre a máquina cliente e a máquina servidor. Essas trocas ocorrem por meio de uma rede, e é importante relembrar a estrutura geral das trocas entre duas máquinas distantes.
2.7.1. O modelo OSI
O modelo de rede aberta denominado OSI (Modelo de Referência para Interconexão de Sistemas Abertos), definido pela ISO (Organização Internacional de Padronização), descreve uma rede ideal na qual a comunicação entre máquinas pode ser representada por um modelo de sete camadas:
 |
Cada camada recebe serviços da camada inferior e oferece os seus próprios serviços à camada superior. Suponhamos que duas aplicações localizadas em máquinas A e B diferentes desejem se comunicar: elas o fazem no nível da camada Application. Elas não precisam conhecer todos os detalhes do funcionamento da rede: cada aplicação entrega a informação que deseja transmitir à camada inferior: a camada Présentation. A aplicação precisa, portanto, conhecer apenas as regras de interface com a camada Présentation. Uma vez que a informação está na camada Présentation, ela é encaminhada, de acordo com outras regras, para a camada Session e assim por diante, até que a informação chegue ao suporte físico e seja transmitida fisicamente para a máquina de destino. Lá, ela passará pelo processo inverso ao que ocorreu na máquina remetente.
Em cada camada, o processo remetente encarregado de enviar a informação a transmite a um processo receptor na outra máquina, pertencente à mesma camada que ele. Isso ocorre de acordo com certas regras, conhecidas como protocolo da camada. Assim, temos o seguinte esquema final de comunicação:
 |
A função das diferentes camadas é a seguinte:
Assegura a transmissão de bits por meio de um suporte físico. Nesta camada, encontram-se equipamentos terminais de processamento de dados (E.T.T.D.), tais como terminais ou computadores, bem como equipamentos de terminação de circuitos de dados (E.T.C.D.), tais como moduladores/demoduladores, multiplexadores e concentradores. Os pontos de interesse neste nível são: . a escolha da codificação da informação (analógica ou digital) . a escolha do modo de transmissão (síncrono ou assíncrono). | |
Oculta as características físicas da camada Física. Detecta e corrige erros de transmissão. | |
Gerencia o caminho que as informações enviadas pela rede devem seguir. Isso é chamado de routage: determinar a rota que uma informação deve seguir para chegar ao seu destinatário. | |
Permite a comunicação entre duas aplicações, enquanto as camadas anteriores permitiam apenas a comunicação entre máquinas. Um serviço fornecido por essa camada pode ser o multiplexamento: a camada de transporte poderá utilizar uma mesma conexão de rede (de máquina para máquina) para transmitir informações pertencentes a várias aplicações. | |
Nesta camada, encontramos serviços que permitem que uma aplicação abra e mantenha uma sessão de trabalho em uma máquina remota. | |
Ela visa uniformizar a representação dos dados nas diferentes máquinas. Assim, os dados provenientes de uma máquina A serão “formatados” pela camada Présentation da máquina A, de acordo com um formato padrão, antes de serem enviados pela rede. Ao chegarem à camada Présentation da máquina destinatária B, que as reconhecerá graças ao seu formato padrão, elas serão formatadas de outra maneira para que o aplicativo da máquina B as reconheça. | |
Nesse nível, encontram-se as aplicações geralmente próximas ao usuário, como o e-mail ou a transferência de arquivos. |
2.7.2. O modelo TCP/IP
O modelo OSI é um modelo ideal. O conjunto de protocolos TCP/IP se aproxima dele da seguinte forma:
 |
- a interface de rede (a placa de rede do computador) desempenha as funções das camadas 1 e 2 do modelo OSI
- a camada IP (Protocolo de Internet) desempenha as funções da camada 3 (rede)
- a camada TCP (Protocolo de Controle de Transferência) ou UDP (Protocolo de Datagrama do Usuário) desempenha as funções da camada 4 (transporte). O protocolo TCP garante que os pacotes de dados trocados entre os computadores cheguem corretamente ao destino. Caso contrário, ele reenvia os pacotes que se perderam. O protocolo UDP não realiza essa tarefa, cabendo, portanto, ao desenvolvedor de aplicativos fazê-lo. É por isso que, na internet — que não é uma rede 100% confiável —, o protocolo TCP é o mais utilizado. Fala-se, então, de rede TCP-IP.
- A camada de Aplicação abrange as funções dos níveis 5 a 7 do modelo OSI.
As aplicações web estão localizadas na camada Application e, portanto, utilizam os protocolos TCP-IP. As camadas Application das máquinas clientes e do servidor trocam mensagens que são encaminhadas pelas camadas 1 a 4 do modelo para serem entregues ao destino. Para se comunicarem, as camadas de aplicação das duas máquinas precisam “falar” a mesma linguagem ou protocolo. O protocolo das aplicações web é chamado de HTTP (HyperText Transfer Protocol). Trata-se de um protocolo do tipo texto, c.a.d, no qual as máquinas trocam linhas de texto pela rede para se comunicarem. Essas trocas são padronizadas, de modo que o cliente dispõe de um determinado conjunto de mensagens para indicar exatamente o que deseja ao servidor, e este último também dispõe de um determinado conjunto de mensagens para fornecer sua resposta ao cliente. Essa troca de mensagens tem o seguinte formato:
 |
Cliente --> Servidor
Quando o cliente faz sua solicitação ao servidor web, ele envia
- linhas de texto no formato HTTP para indicar o que deseja
- uma linha em branco
- opcionalmente, um documento
Servidor --> Cliente
Quando o servidor responde ao cliente, ele envia
- linhas de texto no formato HTTP para indicar o que está enviando
- uma linha vazia
- opcionalmente, um documento
As trocas têm, portanto, o mesmo formato nos dois sentidos. Em ambos os casos, pode haver o envio de um documento, embora seja raro que um cliente envie um documento ao servidor. Mas o protocolo HTTP prevê isso. É isso que permite, por exemplo, que os assinantes de um provedor de acesso baixem diversos documentos para seu site pessoal hospedado nesse provedor. Os documentos trocados podem ser quaisquer. Tomemos como exemplo um navegador solicitando uma página da web que contenha imagens:
- o navegador se conecta ao servidor web e solicita a página desejada. Os recursos solicitados são identificados de forma única por meio de URL (Uniform Resource Locator). O navegador envia apenas cabeçalhos HTTP e nenhum documento.
- O servidor responde. Primeiro, ele envia cabeçalhos HTTP indicando o tipo de resposta que está enviando. Pode ser um erro se a página solicitada não existir. Se a página existir, o servidor indicará nos cabeçalhos HTTP de sua resposta que, após esses cabeçalhos, enviará um documento HTML (HyperText Markup Language). Esse documento é uma sequência de linhas de texto no formato HTML. Um texto HTML contém tags (marcadores) que fornecem ao navegador instruções sobre como exibir o texto.
- O cliente sabe, com base nos cabeçalhos HTTP do servidor, que receberá um documento HTML. Ele analisará esse documento e talvez perceba que ele contém referências a imagens. Essas imagens não estão no documento HTML. Portanto, ele faz uma nova solicitação ao mesmo servidor web para pedir a primeira imagem de que precisa. Essa solicitação é idêntica à feita no passo 1, exceto que o recurso solicitado é diferente. O servidor processará essa solicitação enviando ao cliente a imagem solicitada. Desta vez, na resposta, os cabeçalhos HTTP especificarão que o documento enviado é uma imagem e não um documento HTML.
- O cliente recebe a imagem enviada. As etapas 3 e 4 serão repetidas até que o cliente (geralmente um navegador) tenha todos os documentos necessários para exibir a página na íntegra.
2.7.3. O protocolo HTTP
Vamos conhecer o protocolo HTTP por meio de exemplos. O que um navegador e um servidor web trocam entre si?
2.7.3.1. A resposta de um servidor HTTP
Vamos descobrir aqui como um servidor web responde às solicitações de seus clientes. O serviço web ou serviço HTTP é um serviço TCP-IP que normalmente opera na porta 80. Ele poderia operar em outra porta. Nesse caso, o navegador do cliente seria obrigado a especificar essa porta no URL que ele solicita. Um URL tem o seguinte formato geral:
protocolo://máquina[:port]/caminho/informações
com
protocolo | http para o serviço web. Um navegador também pode atuar como cliente de serviços ftp, news, telnet, etc. |
máquina | nome da máquina onde o serviço web está em operação |
porta | porta do serviço web. Se for 80, pode-se omitir o número da porta. Esse é o caso mais comum |
caminho | caminho que indica o recurso solicitado |
informações | informações complementares fornecidas ao servidor para especificar a solicitação do cliente |
O que um navegador faz quando um usuário solicita o carregamento de um URL?
- ele estabelece uma comunicação TCP-IP com a máquina e a porta indicadas na parte machine[:port] do URL. Estabelecer uma comunicação TCP-IP significa criar um “canal” de comunicação entre duas máquinas. Uma vez criado esse canal, todas as informações trocadas entre as duas máquinas passarão por ele. A criação desse canal TCP-IP ainda não envolve o protocolo HTTP da Web.
- Com o canal TCP-IP criado, o cliente enviará sua solicitação ao servidor da Web, enviando-lhe linhas de texto (comandos) no formato HTTP. Ele enviará ao servidor a parte “caminho/informações” do URL
- o servidor responderá da mesma forma e pelo mesmo canal
- um dos dois participantes decidirá fechar o canal. Isso depende do protocolo HTTP utilizado. Com o protocolo HTTP 1.0, o servidor encerra a conexão após cada uma de suas respostas. Isso obriga um cliente que precise fazer várias solicitações para obter os diferentes documentos que compõem uma página da web a abrir uma nova conexão a cada solicitação, o que acarreta um custo. Com o protocolo HTTP/1.1, o cliente pode instruir o servidor a manter a conexão aberta até que ele mesmo solicite o encerramento. Assim, ele pode recuperar todos os documentos de uma página da web com uma única conexão e encerrar a conexão por conta própria assim que o último documento for obtido. O servidor detectará esse encerramento e também encerrará a conexão.
Para explorar as trocas entre um cliente e um servidor web, vamos utilizar um cliente TCP genérico. Trata-se de um programa que pode atuar como cliente de qualquer serviço que possua um protocolo de comunicação baseado em linhas de texto, como é o caso do protocolo HTTP. Essas linhas de texto serão digitadas pelo usuário no teclado. Para isso, é necessário que ele conheça o protocolo de comunicação do serviço ao qual deseja acessar. A resposta do servidor é então exibida na tela. O programa foi escrito em Java e pode ser encontrado no anexo. Aqui, ele é utilizado em uma janela do DOS no Windows e é chamado da seguinte maneira:
java clientTCPgenerique máquina porta
com
machine | nome da máquina onde o serviço a ser contatado está em operação |
port | porta na qual o serviço é fornecido |
Com essas duas informações, o programa abrirá uma conexão TCP-IP com a máquina e a porta indicadas. Essa conexão servirá para a troca de linhas de texto entre o cliente e o servidor web. As linhas do cliente são digitadas pelo usuário no teclado e enviadas ao servidor. As linhas de texto devolvidas pelo servidor como resposta são exibidas na tela. Assim, é possível estabelecer um diálogo diretamente entre o usuário no teclado e o servidor web. Vamos testar com os exemplos já apresentados. Criamos a seguinte página estática HTML:
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
que visualizamos em um navegador:
Vemos que o URL solicitado é: http://localhost:81/essais/essai1.html. O servidor do serviço web é, portanto, localhost (=servidor local) e a porta 81. Se solicitarmos a exibição do texto HTML dessa página da web (Exibir/Fonte), encontraremos o texto HTML criado inicialmente:
Agora, vamos usar nosso cliente genérico TCP para solicitar o mesmo URL:
Dos>java clientTCPgenerique localhost 81
Commandes :
GET /essais/essai1.html HTTP/1.0
<-- HTTP/1.1 200 OK
<-- Date: Mon, 08 Jul 2002 08:07:46 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Mon, 08 Jul 2002 08:00:30 GMT
<-- ETag: "0-a1-3d29469e"
<-- Accept-Ranges: bytes
<-- Content-Length: 161
<-- Connection: close
<-- Content-Type: text/html
<--
<-- <html>
<-- <head>
<-- <title>essai 1 : une page statique</title>
<-- </head>
<-- <body>
<-- <center>
<-- <h1>Une page statique...</h1>
<-- </body>
<-- </html>
Ao iniciar o cliente por meio do comando java clientTCPgenerique localhost 81, foi criado um canal entre o programa e o servidor web operando na mesma máquina (localhost) e na porta 81. As trocas cliente-servidor no formato HTTP podem começar. Vale lembrar que elas têm três componentes:
- cabeçalhos HTTP
- linha vazia
- dados opcionais
No nosso exemplo, o cliente envia apenas uma solicitação:
GET /testes/essai1.html HTTP/1.0
Essa linha possui três componentes:
comando HTTP para solicitar um recurso. Existem outros: HEAD solicita um recurso, mas limitando-se aos cabeçalhos HTTP da resposta do servidor. O recurso em si não é enviado. PUT permite que o cliente envie um documento ao servidor | |
recurso solicitado | |
nível do protocolo HTTP utilizado. Aqui, o 1.0. Isso significa que o servidor encerrará a conexão assim que enviar sua resposta |
Os cabeçalhos HTTP devem sempre ser seguidos por uma linha em branco. Foi isso que o cliente fez aqui. É assim que o cliente ou o servidor sabe que a parte HTTP da troca de dados está concluída. Aqui, para o cliente, o processo está concluído. Ele não tem nenhum documento a enviar. Começa então a resposta do servidor, composta, em nosso exemplo, por todas as linhas que começam com o sinal <--. Ele envia primeiro uma série de cabeçalhos HTTP, seguida por uma linha em branco:
<-- HTTP/1.1 200 OK
<-- Date: Mon, 08 Jul 2002 08:07:46 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Mon, 08 Jul 2002 08:00:30 GMT
<-- ETag: "0-a1-3d29469e"
<-- Accept-Ranges: bytes
<-- Content-Length: 161
<-- Connection: close
<-- Content-Type: text/html
<--
o servidor informa
| |
a data/hora da resposta | |
o servidor se identifica. Neste caso, trata-se de um servidor Apache | |
data da última modificação do recurso solicitado pelo cliente | |
... | |
unidade de medida dos dados enviados. Neste caso, o byte | |
número de bytes do documento que será enviado após os cabeçalhos HTTP. Esse número corresponde, na verdade, ao tamanho em bytes do arquivo essai1.html: | |
O servidor informa que encerrará a conexão assim que o documento for enviado | |
o servidor informa que enviará texto (text) no formato HTML (html). |
O cliente recebe esses cabeçalhos HTTP e agora sabe que receberá 161 bytes representando um documento HTML. O servidor envia esses 161 bytes imediatamente após a linha vazia que sinalizava o fim dos cabeçalhos HTTP:
<-- <html>
<-- <head>
<-- <title>essai 1 : une page statique</title>
<-- </head>
<-- <body>
<-- <center>
<-- <h1>Une page statique...</h1>
<-- </body>
<-- </html>
Reconhecemos aqui o arquivo HTML criado inicialmente. Se nosso cliente fosse um navegador, após receber essas linhas de texto, ele as interpretaria para apresentar ao usuário, por meio do teclado, a seguinte página:
Vamos usar mais uma vez nosso cliente genérico TCP para solicitar o mesmo recurso, mas desta vez com o comando HEAD, que solicita apenas os cabeçalhos da resposta:
Dos>java.bat clientTCPgenerique localhost 81
Commandes :
HEAD /essais/essai1.html HTTP/1.1
Host: localhost:81
<-- HTTP/1.1 200 OK
<-- Date: Mon, 08 Jul 2002 09:07:25 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Mon, 08 Jul 2002 08:00:30 GMT
<-- ETag: "0-a1-3d29469e"
<-- Accept-Ranges: bytes
<-- Content-Length: 161
<-- Content-Type: text/html
<--
Obtemos o mesmo resultado de antes, sem o documento HTML. Observe que, em sua solicitação HEAD, o cliente indicou que estava utilizando o protocolo HTTP versão 1.1. Isso o obriga a enviar um segundo cabeçalho HTTP especificando o par machine:port que o cliente deseja consultar: Host: localhost:81.
Agora, vamos solicitar uma imagem tanto com um navegador quanto com o cliente genérico TCP. Primeiro, com um navegador:
O arquivo univ01.gif tem 3167 bytes:
Vamos agora usar o cliente genérico TCP:
E:\data\serge\JAVA\SOCKETS\client générique>java clientTCPgenerique localhost 81
Commandes :
HEAD /images/univ01.gif HTTP/1.1
host: localhost:81
<-- HTTP/1.1 200 OK
<-- Date: Tue, 09 Jul 2002 13:53:24 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Fri, 14 Apr 2000 11:37:42 GMT
<-- ETag: "0-c5f-38f70306"
<-- Accept-Ranges: bytes
<-- Content-Length: 3167
<-- Content-Type: image/gif
<--
Observe os seguintes pontos na resposta do servidor:
| |
| |
|
2.7.3.2. A solicitação de um cliente HTTP
Agora, vamos nos perguntar o seguinte: se quisermos escrever um programa que “se comunique” com um servidor web, quais comandos ele deve enviar ao servidor web para obter um determinado recurso? Nos exemplos anteriores, obtivemos um início de resposta. Encontramos três comandos:
| |
| |
|
Existem outros comandos. Para descobri-los, vamos agora utilizar um servidor TCP genérico. Trata-se de um programa escrito em Java, que você também encontrará no anexo. Ele é executado com o comando: java serveurTCPgenerique portEcoute, onde portEcoute é a porta à qual os clientes devem se conectar. O programa serveurTCPgenerique
- exibe na tela os comandos enviados pelos clientes
- envia a eles, como resposta, as linhas de texto digitadas no teclado por um usuário. Portanto, é o usuário que atua como servidor. No nosso exemplo, o usuário no teclado desempenhará o papel de um serviço web.
Vamos agora simular um servidor web, iniciando nosso servidor genérico na porta 88:
Dos> java serveurTCPgenerique 88
Serveur générique lancé sur le port 88
Agora, vamos abrir um navegador e acessar a página http://localhost:88/exemple.html. O navegador se conectará à porta 88 da máquina localhost e, em seguida, solicitará a página /exemple.html:
Vamos agora observar a janela do nosso servidor, que exibe o que o cliente enviou a ele (algumas linhas específicas ao funcionamento do programa serveurTCPgenerique foram omitidas por uma questão de simplificação):
Dos>java serveurTCPgenerique 88
Serveur générique lancé sur le port 88
...
<-- GET /exemple.html HTTP/1.1
<-- Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, */*
<-- Accept-Language: fr
<-- Accept-Encoding: gzip, deflate
<-- User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.0.2 914)
<-- Host: localhost:88
<-- Connection: Keep-Alive
<--
As linhas precedidas pelo sinal <-- são aquelas enviadas pelo cliente. Assim, encontramos cabeçalhos HTTP que ainda não tínhamos visto:
| |
| |
| |
| |
|
Os cabeçalhos HTTP enviados pelo navegador terminam com uma linha vazia, conforme esperado.
Vamos elaborar uma resposta para nosso cliente. O usuário que digita no teclado é, neste caso, o verdadeiro servidor e pode elaborar uma resposta manualmente. Lembremo-nos da resposta fornecida por um servidor web em um exemplo anterior:
<-- HTTP/1.1 200 OK
<-- Date: Mon, 08 Jul 2002 08:07:46 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Mon, 08 Jul 2002 08:00:30 GMT
<-- ETag: "0-a1-3d29469e"
<-- Accept-Ranges: bytes
<-- Content-Length: 161
<-- Connection: close
<-- Content-Type: text/html
<--
<-- <html>
<-- <head>
<-- <title>essai 1 : une page statique</title>
<-- </head>
<-- <body>
<-- <center>
<-- <h1>Une page statique...</h1>
<-- </body>
<-- </html>
Vamos tentar elaborar manualmente (no teclado) uma resposta semelhante. As linhas que começam com --> : são enviadas ao cliente:
...
<-- Host: localhost:88
<-- Connection: Keep-Alive
<--
--> : HTTP/1.1 200 OK
--> : Server: serveur tcp generique
--> : Connection: close
--> : Content-Type: text/html
--> :
--> : <html>
--> : <head><title>Serveur generique</title></head>
--> : <body>
--> : <center>
--> : <h2>Reponse du serveur generique</h2>
--> : </center>
--> : </body>
--> : </html>
fin
O comando fin é específico para o funcionamento do programa serveurTCPgenerique. Ele interrompe a execução do programa e encerra a conexão entre o servidor e o cliente. Limitamos nossa resposta aos seguintes cabeçalhos HTTP:
HTTP/1.1 200 OK
--> : Server: serveur tcp generique
--> : Connection: close
--> : Content-Type: text/html
--> :
Não informamos o tamanho do arquivo que vamos enviar (Content-Length), mas nos limitamos a indicar que vamos encerrar a conexão (Connection: close) após o envio do mesmo. Isso é suficiente para o navegador. Ao perceber que a conexão foi encerrada, ele saberá que a resposta do servidor foi concluída e exibirá a página HTML que lhe foi enviada. Esta página é a seguinte:
--> : <html>
--> : <head><title>Serveur generique</title></head>
--> : <body>
--> : <center>
--> : <h2>Reponse du serveur generique</h2>
--> : </center>
--> : </body>
--> : </html>
O navegador exibe então a seguinte página:
Se, no exemplo acima, executarmos o comando View/Source para verificar o que o navegador recebeu, obtemos:
ou seja, exatamente o que foi enviado a partir do servidor genérico.
2.8. A linguagem HTML
Um navegador da Web pode exibir diversos documentos, sendo o mais comum o documento HTML (Linguagem de Marcação HyperText). Trata-se de um texto formatado com tags do tipo <balise>texte</balise>. Assim, o texto <B>important</B> exibirá o texto importante em negrito. Existem tags isoladas, como a tag <hr>, que exibe uma linha horizontal. Não abordaremos as tags que podem ser encontradas em um texto HTML. Existem diversos softwares WYSIWYG que permitem criar uma página da web sem escrever uma única linha de código HTML. Essas ferramentas geram automaticamente o código HTML a partir de um layout criado com o mouse e controles predefinidos. Assim, é possível inserir (com o mouse) uma tabela na página e, em seguida, consultar o código HTML gerado pelo software para descobrir as tags a serem utilizadas para definir uma tabela em uma página da Web. Não é mais complicado do que isso. Além disso, o conhecimento da linguagem HTML é indispensável, uma vez que as aplicações web dinâmicas devem gerar elas mesmas o código HTML a ser enviado aos clientes web. Esse código é gerado por programa e, obviamente, é preciso saber o que deve ser gerado para que o cliente tenha a página web que deseja.
Resumindo, não é necessário conhecer toda a linguagem HTML para começar a programar para a web. No entanto, esse conhecimento é necessário e pode ser adquirido por meio do uso de softwares de criação de páginas da Web, como o Word, o FrontPage, o DreamWeaver e dezenas de outros. Outra maneira de descobrir as sutilezas da linguagem HTML é navegar pela web e visualizar o código-fonte das páginas que apresentam características interessantes e ainda desconhecidas para você.
2.8.1. Um exemplo
Consideremos o exemplo a seguir, criado com o FrontPage Express, uma ferramenta gratuita que vem junto com o Internet Explorer. O código gerado pelo FrontPage foi simplificado aqui. Este exemplo apresenta alguns elementos que podem ser encontrados em um documento da web, tais como:
- uma tabela
- uma imagem
- um link
Um documento HTML tem a seguinte estrutura geral:
Todo o documento é delimitado pelas tags <html>...</html>. Ele é composto por duas partes:
- <head>...</head>: essa é a parte não exibível do documento. Ela fornece informações ao navegador que irá exibir o documento. Nela, costuma-se encontrar a tag <title>...</title>, que define o texto a ser exibido na barra de título do navegador. Também podem ser encontradas outras tags, notadamente aquelas que definem as palavras-chave do documento, palavras-chave posteriormente utilizadas pelos mecanismos de busca. Também é possível encontrar nessa parte scripts, geralmente escritos em JavaScript ou VBScript, que serão executados pelo navegador.
- <body atributos>...</body>: esta é a parte que será exibida pelo navegador. As tags HTML contidas nesta parte indicam ao navegador a forma visual “desejada” para o documento. Cada navegador interpretará essas tags à sua maneira. Dois navegadores podem, portanto, exibir um mesmo documento da web de maneiras diferentes. Isso costuma ser um dos desafios dos web designers.
O código HTML do nosso documento de exemplo é o seguinte:
<html>
<head>
<title>balises</title>
</head>
<body background="/images/standard.jpg">
<center>
<h1>Les balises HTML</h1>
<hr>
</center>
<table border="1">
<tr>
<td>cellule(1,1)</td>
<td valign="middle" align="center" width="150">cellule(1,2)</td>
<td>cellule(1,3)</td>
</tr>
<tr>
<td>cellule(2,1)</td>
<td>cellule(2,2)</td>
<td>cellule(2,3</td>
</tr>
</table>
<table border="0">
<tr>
<td>Une image</td>
<td><img border="0" src="/images/univ01.gif" width="80" height="95"></td>
</tr>
<tr>
<td>le site de l'ISTIA</td>
<td><a href="http://istia.univ-angers.fr">ici</a></td>
</tr>
</table>
</body>
</html>
Foram destacados no código apenas os pontos que nos interessam:
Elemento | tags e exemplos HTML |
<title>balises</title> balises aparecerá na barra de título do navegador que exibirá o documento | |
<hr>: exibe uma linha horizontal | |
<atributos da tabela>....</table>: para definir a tabela <tr atributos>...</tr>: para definir uma linha <td atributos>...</td>: para definir uma célula exemplos: <table border="1">...</table>: o atributo border define a espessura da borda da tabela <td valign="middle" align="center" width="150">célula(1,2)</td>: define uma célula cujo conteúdo será célula(1,2). Esse conteúdo será centralizado verticalmente (valign="middle") e horizontalmente (align="center"). A célula terá uma largura de 150 pixels (width="150") | |
<img border="0" src="/images/univ01.gif" width="80" height="95">: define uma imagem sem borda (border="0"), com altura de 95 pixels (height="95"), largura de 80 pixels (width="80") e cujo arquivo de origem é /images/univ01.gif no servidor web (src="/images/univ01.gif"). Esse link está em um documento da web que foi gerado com o URL http://localhost:81/html/balises.htm. Assim, o navegador solicitará o URL http://localhost:81/images/univ01.gif para obter a imagem referenciada aqui. | |
<a href="http://istia.univ-angers.fr">aqui</a>: faz com que o texto ici funcione como um link para o URL http://istia.univ-angers.fr. | |
<body background="/images/standard.jpg">: indica que a imagem que deve servir como plano de fundo da página está localizada em URL /images/standard.jpg no servidor web. No contexto do nosso exemplo, o navegador solicitará o arquivo URL http://localhost:81/images/standard.jpg para obter essa imagem de fundo. |
Vemos neste exemplo simples que, para construir o documento na íntegra, o navegador precisa fazer três solicitações ao servidor:
- http://localhost:81/html/balises.htm para obter o código-fonte HTML do documento
- http://localhost:81/images/univ01.gif para obter a imagem univ01.gif
- http://localhost:81/images/standard.jpg para obter a imagem de fundo standard.jpg
O exemplo a seguir apresenta um formulário da Web também criado com FrontPage.
O código HTML gerado pelo FrontPage e ligeiramente simplificado é o seguinte:
<html>
<head>
<title>balises</title>
<script language="JavaScript">
function effacer(){
alert("Vous avez cliqué sur le bouton Effacer");
}//apagar
</script>
</head>
<body background="/images/standard.jpg">
<form method="POST" >
<table border="0">
<tr>
<td>Etes-vous marié(e)</td>
<td>
<input type="radio" value="Oui" name="R1">Oui
<input type="radio" name="R1" value="non" checked>Non
</td>
</tr>
<tr>
<td>Cases à cocher</td>
<td>
<input type="checkbox" name="C1" value="un">1
<input type="checkbox" name="C2" value="deux" checked>2
<input type="checkbox" name="C3" value="trois">3
</td>
</tr>
<tr>
<td>Champ de saisie</td>
<td>
<input type="text" name="txtSaisie" size="20" value="qqs mots">
</td>
</tr>
<tr>
<td>Mot de passe</td>
<td>
<input type="password" name="txtMdp" size="20" value="unMotDePasse">
</td>
</tr>
<tr>
<td>Boîte de saisie</td>
<td>
<textarea rows="2" name="areaSaisie" cols="20">
ligne1
ligne2
ligne3
</textarea>
</td>
</tr>
<tr>
<td>combo</td>
<td>
<select size="1" name="cmbValeurs">
<option>choix1</option>
<option selected>choix2</option>
<option>choix3</option>
</select>
</td>
</tr>
<tr>
<td>liste à choix simple</td>
<td>
<select size="3" name="lst1">
<option selected>liste1</option>
<option>liste2</option>
<option>liste3</option>
<option>liste4</option>
<option>liste5</option>
</select>
</td>
</tr>
<tr>
<td>liste à choix multiple</td>
<td>
<select size="3" name="lst2" multiple>
<option>liste1</option>
<option>liste2</option>
<option selected>liste3</option>
<option>liste4</option>
<option>liste5</option>
</select>
</td>
</tr>
<tr>
<td>bouton</td>
<td>
<input type="button" value="Effacer" name="cmdEffacer" onclick="effacer()">
</td>
</tr>
<tr>
<td>envoyer</td>
<td>
<input type="submit" value="Envoyer" name="cmdRenvoyer">
</td>
</tr>
<tr>
<td>rétablir</td>
<td>
<input type="reset" value="Rétablir" name="cmdRétablir">
</td>
</tr>
</table>
<input type="hidden" name="secret" value="uneValeur">
</form>
</body>
</html>
A correspondência entre a verificação visual <--> a tag HTML é a seguinte:
Controle | tag HTML |
<form method="POST" > | |
<input type="text" name="txtSaisie" size="20" value="algumas palavras"> | |
<input type="password" name="txtMdp" size="20" value="unMotDePasse"> | |
<textarea rows="2" name="areaSaisie" cols="20"> linha1 linha2 linha3 </textarea> | |
<input type="radio" value="Sim" name="R1">Sim <input type="radio" name="R1" value="não" checked>Não | |
<input type="checkbox" name="C1" value="um">1 <input type="checkbox" name="C2" value="dois" checked>2 <input type="checkbox" name="C3" value="três">3 | |
<select size="1" name="cmbValeurs"> <option>opção1</option> <option selected>opção 2</option> <option>opção 3</option> </select> | |
<select size="3" name="lst1"> <option selected>lista1</option> <option>lista2</option> <option>lista3</option> <option>lista4</option> <option>lista5</option> </select> | |
<select size="3" name="lst2" multiple> <option>lista1</option> <option>lista2</option> <option selected>lista3</option> <option>lista4</option> <option>lista5</option> </select> | |
<input type="submit" value="Enviar" name="cmdRenvoyer"> | |
<input type="reset" value="Redefinir" name="cmdRétablir"> | |
<input type="button" value="Apagar" name="cmdEffacer" onclick="effacer()"> |
Vamos examinar esses diferentes controles.
2.8.1.1. O formulário
<form method="POST" > |
<form name="..." method="..." action="...">...</form> | |
name="frmexemple": nome do formulário method="..." : método utilizado pelo navegador para enviar ao servidor web os valores coletados no formulário action="..." : URL para onde serão enviados os valores coletados no formulário. Um formulário da web é delimitado pelas tags <form>...</form>. O formulário pode ter um nome (name="xx"). Isso se aplica a todos os controles que podem ser encontrados em um formulário. Esse nome é útil se o documento da web contiver scripts que precisem referenciar elementos do formulário. O objetivo de um formulário é coletar informações fornecidas pelo usuário por meio do teclado/mouse e enviá-las para uma URL do servidor web. Qual? Aquela referenciada no atributo action="URL". Se esse atributo estiver ausente, as informações serão enviadas para o servidor do documento no qual o formulário está localizado. Esse seria o caso no exemplo acima. Até agora, sempre vimos o cliente da web como alguém que “solicita” informações a um servidor da web, nunca como alguém que “fornece” informações a ele. Como um cliente web faz para fornecer informações (aquelas contidas no formulário) a um servidor web? Voltaremos a esse assunto em detalhes um pouco mais adiante. Ele pode utilizar dois métodos diferentes, chamados POST e GET. O atributo method="méthode", com o método igual a GET ou POST, da tag <form> indica ao navegador o método a ser utilizado para enviar as informações coletadas no formulário para o URL especificado pelo atributo action="URL". Quando o atributo method não é especificado, o método GET é utilizado por padrão. |
2.8.1.2. Campo de entrada
<input type="text" name="txtSaisie" size="20" value="algumas palavras"> <input type="password" name="txtMdp" size="20" value="unMotDePasse"> |
<input type="..." name="..." size=".." value=".."> A tag `input` existe para diversos controles. É o atributo type que permite diferenciar esses controles uns dos outros. | |
type="text": especifica que se trata de um campo de entrada type="password": os caracteres presentes no campo de entrada são substituídos por asteriscos (*). Essa é a única diferença em relação ao campo de entrada normal. Esse tipo de controle é adequado para a digitação de senhas. size="20": número de caracteres visíveis no campo — não impede a digitação de mais caracteres name="txtSaisie": nome do controle value="algumas palavras": texto que será exibido no campo de entrada. |
2.8.1.3. Campo de digitação multilinha
<textarea rows="2" name="areaSaisie" cols="20"> ligne1 ligne2 ligne3 </textarea> |
<textarea ...>texto</textarea> exibe uma área de entrada de várias linhas com o texto já inserido inicialmente | |
rows="2": número de linhas cols="'20" : número de colunas name="areaSaisie": nome do controle |
2.8.1.4. Botões de opção
<input type="radio" value="Sim" name="R1">Sim <input type="radio" name="R1" value="não" checked>Não |
<input type="radio" atributo2="valor2" ....>texto exibe um botão de opção com texto ao lado. | |
name="radio": nome do controle. Os botões de opção com o mesmo nome formam um grupo de botões mutuamente exclusivos: só é possível selecionar um deles. value="valor": valor atribuído ao botão de opção. Não se deve confundir esse valor com o texto exibido ao lado do botão de opção. Este último destina-se apenas à exibição. checked: se essa palavra-chave estiver presente, o botão de opção estará marcado; caso contrário, não estará. |
2.8.1.5. Caixas de seleção
<input type="checkbox" name="C1" value="um">1 <input type="checkbox" name="C2" value="dois" checked>2 <input type="checkbox" name="C3" value="três">3 |
<input type="checkbox" atributo2="valor2" ....>texto exibe uma caixa de seleção com texto ao lado. | |
name="C1": nome do controle. As caixas de seleção podem ou não ter o mesmo nome. As caixas com o mesmo nome formam um grupo de caixas associadas. value="valor": valor atribuído à caixa de seleção. Não se deve confundir esse valor com o texto exibido ao lado do botão de opção. Este último destina-se apenas à exibição. checked: se essa palavra-chave estiver presente, o botão de opção estará marcado; caso contrário, não estará. |
2.8.1.6. Lista suspensa (combo)
<select size="1" name="cmbValeurs"> <option>choix1</option> <option selected>opção2</option> <option>choix3</option> </select> |
<select size=".." name=".."> <option [selected]>...</option> ... </select> exibe em uma lista os textos contidos entre as tags <option>...</option> | |
name="cmbValeurs": nome do controle. size="1": número de itens visíveis na lista. size="1" transforma a lista no equivalente a uma caixa de combinação. selected: se essa palavra-chave estiver presente para um item da lista, este aparecerá selecionado na lista. No nosso exemplo acima, o item da lista choix2 aparece como o item selecionado da caixa de combinação quando esta é exibida pela primeira vez. |
2.8.1.7. Lista de seleção única
<select size="3" name="lst1"> <option selected>lista1</option> <option>liste2</option> <option>liste3</option> <option>liste4</option> <option>liste5</option> </select> |
<select size=".." name=".."> <option [selected]>...</option> ... </select> exibe em uma lista os textos entre as tags <option>...</option> | |
os mesmos da lista suspensa que exibe apenas um item. Esse controle difere da lista suspensa anterior apenas pelo atributo size>1. |
2.8.1.8. Lista de seleção múltipla
<select size="3" name="lst2" multiple> <option selected>lista1</option> <option>liste2</option> <option selected>lista3</option> <option>liste4</option> <option>liste5</option> </select> |
<select size=".." name=".." multiple> <option [selected]>...</option> ... </select> exibe em uma lista os textos entre as tags <option>...</option> | |
múltiplo: permite a seleção de vários elementos na lista. No exemplo acima, os elementos liste1 e liste3 estão ambos selecionados. |
2.8.1.9. Botão do tipo button
<input type="button" value="Apagar" name="cmdEffacer" onclick="effacer()"> |
<input type="button" value="..." name="..." onclick="effacer()" ....> | |
type="button": define um controle de botão. Existem outros dois tipos de botão: os tipos submit e reset. value="Apagar": o texto exibido no botão onclick="função()": permite definir uma função a ser executada quando o usuário clica no botão. Essa função faz parte dos scripts definidos no documento da web exibido. A sintaxe anterior segue a sintaxe javascript. Se os scripts forem escritos em VBScript, deve-se escrever onclick="função" sem os parênteses. A sintaxe permanece a mesma caso seja necessário passar parâmetros para a função: onclick="função(val1, val2,...)" No nosso exemplo, um clique no botão Effacer chama a seguinte função JavaScript effacer: A função effacer exibe a seguinte mensagem:  |
2.8.1.10. Botão do tipo “submit”
<input type="submit" value="Enviar" name="cmdRenvoyer"> |
<input type="submit" value="Enviar" name="cmdRenvoyer"> | |
type="submit": define o botão como um botão para enviar os dados do formulário ao servidor web. Quando o usuário clicar nesse botão, o navegador enviará os dados do formulário para o URL definido no atributo action da tag <form>, de acordo com o método definido pelo atributo method dessa mesma tag. value="Enviar": o texto exibido no botão |
2.8.1.11. Botão do tipo reset
<input type="reset" value="Restaurar" name="cmdRétablir"> |
<input type="reset" value="Restaurar" name="cmdRétablir"> | |
type="reset": define o botão como um botão de reinicialização do formulário. Quando o usuário clicar nesse botão, o navegador restaurará o formulário ao estado em que o recebeu. value="Restaurar": o texto exibido no botão |
2.8.1.12. Campo oculto
<input type="hidden" name="secret" value="uneValeur"> |
<input type="hidden" name="..." value="..."> | |
type="hidden": indica que se trata de um campo oculto. Um campo oculto faz parte do formulário, mas não é exibido ao usuário. No entanto, se o usuário solicitar ao navegador que exiba o código-fonte, ele verá a presença da tag <input type="hidden" value="..."> e, portanto, o valor do campo oculto. value="umValor": valor do campo oculto. Qual é a utilidade do campo oculto? Ele permite que o servidor web armazene informações ao longo das solicitações de um cliente. Consideremos um aplicativo de compras na web. O cliente compra um primeiro item art1 na quantidade q1 na primeira página de um catálogo e, em seguida, passa para uma nova página do catálogo. Para lembrar que o cliente comprou q1 itens art1, o servidor pode inserir essas duas informações em um campo oculto do formulário da nova página. Nessa nova página, o cliente compra os itens q2 e art2. Quando os dados desse segundo formulário forem enviados ao servidor (submit), este receberá não apenas a informação (q2, art2), mas também (q1, art1), que também fazem parte do formulário como campos ocultos não modificáveis pelo usuário. O servidor web, então, colocará em um novo campo oculto as informações (q1,art1) e (q2,art2) e enviará uma nova página do catálogo. E assim por diante. |
2.8.2. Envio dos valores de um formulário de um cliente web para um servidor web
Mencionamos no estudo anterior que o cliente web dispõe de dois métodos para enviar a um servidor web os valores de um formulário que ele exibiu: os métodos GET e POST. Vejamos, por meio de um exemplo, a diferença entre os dois métodos. Retomamos o exemplo anterior e o tratamos da seguinte maneira:
- um navegador solicita o URL do exemplo a um servidor web
- assim que o formulário for obtido, nós o preenchemos
- antes de enviar os valores do formulário ao servidor web clicando no botão Envoyer do tipo submit, desativamos o servidor web e o substituímos pelo servidor genérico TCP já utilizado anteriormente. Vale lembrar que este servidor exibe na tela as linhas de texto que o cliente web lhe envia. Assim, poderemos ver exatamente o que o navegador está enviando.
O formulário é preenchido da seguinte maneira:
O URL utilizado para este documento é o seguinte:
2.8.2.1. Método GET
O documento HTML está configurado para que o navegador utilize o método GET para enviar os valores do formulário ao servidor web. Portanto, escrevemos:
Desligamos o servidor web e iniciamos nosso servidor genérico TCP na porta 81:
E:\data\serge\JAVA\SOCKETS\serveur générique>java serveurTCPgenerique 81
Serveur générique lancé sur le port 81
Agora, voltamos ao nosso navegador para enviar os dados do formulário ao servidor web usando o botão Envoyer:
Eis o que o servidor genérico TCP recebe:
<-- GET /html/balises.htm?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&area
Saisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&
cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
<-- Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/vnd
.ms-powerpoint, application/vnd.ms-excel, */*
<-- Referer: http://localhost:81/html/balises.htm
<-- Accept-Language: fr
<-- Accept-Encoding: gzip, deflate
<-- User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)
<-- Host: localhost:81
<-- Connection: Keep-Alive
<--
Tudo está no primeiro cabeçalho HTTP enviado pelo navegador:
<-- GET /html/balises.htm?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&area
Saisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&
cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
Percebe-se que é muito mais complexo do que o que havíamos encontrado até agora. Encontramos nele a sintaxe GET URL HTTP/1.1, mas em um formato específico: GET URL?param1=valor1¶m2=valor2&... HTTP/1.1, em que parami são os nomes dos controles do formulário da web e “valores” são os valores a eles associados. Vamos examiná-los mais de perto. Apresentamos abaixo uma tabela com três colunas:
- coluna 1: apresenta a definição de um controle HTML do exemplo
- coluna 2: mostra como esse controle é exibido em um navegador
- coluna 3: apresenta o valor enviado ao servidor pelo navegador para o controle da coluna 1, na forma em que aparece na solicitação GET do exemplo
controle HTML | visual | valor(es) retornado(s) |
<input type="radio" value="Sim" name="R1">Sim <input type="radio" name="R1" value="não" checked>Não |  | R1=Sim - o valor do atributo value do botão de opção marcado pelo usuário. |
<input type="checkbox" name="C1" value="um">1 <input type="checkbox" name="C2" value="dois" checked>2 <input type="checkbox" name="C3" value="três">3 |  | C1=um C2=dois - valores dos atributos value das caixas de seleção marcadas pelo usuário |
<input type="text" name="txtSaisie" size="20" value="algumas palavras"> |  | txtSaisida=programação+web - texto digitado pelo usuário no campo de entrada. Os espaços foram substituídos pelo sinal + |
<input type="password" name="txtMdp" size="20" value="unMotDePasse"> |  | txtMdp=issoésegredo - texto digitado pelo usuário no campo de entrada |
<textarea rows="2" name="areaSaisie" cols="20"> linha1 linha 2 linha3 </textarea> |  | areaSaisie=os+fundamentos+da%0D%0A programação+web - texto digitado pelo usuário no campo de entrada. %OD%OA é o marcador de fim de linha. Os espaços foram substituídos pelo sinal + |
<select size="1" name="cmbValeurs"> <option>opção1</option> <option selected>opção2</option> <option>opção3</option> </select> |  | cmbValores=opção3 - valor escolhido pelo usuário na lista de seleção única |
<select size="3" name="lst1"> <option selected>lista1</option> <option>lista2</option> <option>lista3</option> <option>lista4</option> <option>lista5</option> </select> |  | lst1=lista3 - valor escolhido pelo usuário na lista de seleção única |
<select size="3" name="lst2" multiple> <option selected>lista1</option> <option>lista2</option> <option selected>lista3</option> <option>lista4</option> <option>lista5</option> </select> |  | lst2=lista1 lst2=lista3 - valores selecionados pelo usuário na lista de seleção múltipla |
<input type="submit" value="Enviar" name="cmdRenvoyer"> | cmdRenvoyer=Enviar - nome e atributo value do botão utilizado para enviar os dados do formulário ao servidor | |
<input type="hidden" name="secret" value="uneValeur"> | secret=umValor - atributo value do campo oculto |
Vamos repetir o mesmo procedimento, mas desta vez deixando que o servidor web elabore a resposta, para ver qual será o resultado. A página retornada pelo servidor web é a seguinte:
É exatamente a mesma que foi recebida inicialmente, antes do preenchimento do formulário. Para entender o motivo, é preciso examinar novamente a solicitação URL feita pelo navegador quando o usuário clica no botão Envoyer:
<-- GET /html/balises.htm?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&area
Saisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&
cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
A URL solicitada é /html/balises.htm. Além disso, passamos para essa URL os valores do formulário. Por enquanto, o URL /html/balises.htm, que é uma página estática, não utiliza esses valores. Portanto, o GET anterior é equivalente a
e é por isso que o servidor nos reenviou a página inicial novamente. Observe-se que o navegador exibe corretamente a página URL completa que foi solicitada:
2.8.2.2. Método POST
O documento HTML está configurado para que o navegador utilize agora o método POST para enviar os valores do formulário ao servidor web:
Desligamos o servidor web e iniciamos o servidor genérico TCP (já mencionado, mas ligeiramente modificado para a ocasião) na porta 81:
E:\data\serge\JAVA\SOCKETS\serveur générique>java serveurTCPgenerique2 81
Serveur générique lancé sur le port 81
Agora, voltamos ao nosso navegador para enviar os dados do formulário ao servidor web usando o botão “Enviar”:
Eis o que o servidor genérico TCP recebe:
<-- POST /html/balises.htm HTTP/1.1
<-- Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/vnd
.ms-powerpoint, application/vnd.ms-excel, */*
<-- Referer: http://localhost:81/html/balises.htm
<-- Accept-Language: fr
<-- Content-Type: application/x-www-form-urlencoded
<-- Accept-Encoding: gzip, deflate
<-- User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)
<-- Host: localhost:81
<-- Content-Length: 210
<-- Connection: Keep-Alive
<-- Cache-Control: no-cache
<--
<-- R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&areaSaisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&cmdRenvoyer=Envoyer&secret=uneValeur
Em comparação com o que já conhecemos, observamos as seguintes alterações na solicitação do navegador:
- O cabeçalho inicial HTTP não é mais GET, mas sim POST. A sintaxe é POST URL HTTP/1.1, em que URL é o URL solicitado pelo navegador. Ao mesmo tempo, POST significa que o navegador tem dados a serem transmitidos ao servidor.
- A linha Content-Type: application/x-www-form-urlencoded indica que tipo de dados o navegador enviará. Trata-se de dados de formulário (x-www-form) codificados (urlencoded). Essa codificação faz com que alguns caracteres dos dados transmitidos sejam transformados, a fim de evitar erros de interpretação por parte do servidor. Assim, o espaço é substituído por +, o caractere de fim de linha por %OD%OA,... De modo geral, todos os caracteres contidos nos dados e suscetíveis de interpretação incorreta pelo servidor (&, +, %, ...) são transformados em %XX, onde XX é seu código hexadecimal.
- A linha Content-Length: 210 indica ao servidor quantos caracteres o cliente enviará a ele após o término dos cabeçalhos HTTP, c.a.d, após a linha vazia que sinaliza o fim dos cabeçalhos.
- Os dados (210 caracteres): R1=Sim&C1=um&C2=dois&txtSaisie=programação+web&txtMdp=issoésegredo&areaSaisie=os+fundamentos+da%0D%0Aprogramação+web&cmbValeurs=escolha3&lst1=lista3&lst2=lista1&lst2=lista3&cmdRenvoyer=Enviar&secret=uneValeur
Percebe-se que os dados transmitidos por POST têm o mesmo formato daqueles transmitidos por GET.
Existe um método melhor do que o outro? Vimos que, se os valores de um formulário fossem enviados pelo navegador com o método GET, o navegador exibia em seu campo Adresse o URL solicitado na forma URL?param1=val1¶m2=val2&.... Isso pode ser visto como uma vantagem ou uma desvantagem:
- uma vantagem se quisermos permitir que o usuário salve esse URL configurado em seus favoritos
- uma desvantagem se não quisermos que o usuário tenha acesso a certas informações do formulário, como, por exemplo, os campos ocultos
Daqui em diante, utilizaremos quase exclusivamente o método POST em nossos formulários.
2.8.2.3. Recuperação dos valores de um formulário da Web
Uma página estática solicitada por um cliente que, além disso, envia parâmetros por meio de POST ou GET não pode, de forma alguma, recuperar esses parâmetros. Somente um programa pode fazer isso, e é ele que se encarregará de gerar uma resposta para o cliente — uma resposta que será dinâmica e, geralmente, dependente dos parâmetros recebidos. Esse é o campo da programação web, tema que abordaremos com mais detalhes no próximo capítulo, com a apresentação das tecnologias Java de programação web: os servlets e as páginas JSP.