2. Noções básicas
Neste capítulo, apresentamos os fundamentos da programação web. Seu objetivo principal é apresentar os grandes princípios da programação web, que são independentes da tecnologia específica utilizada para implementá-los. Ele apresenta diversos exemplos que é recomendável testar para, aos poucos, “absorver” a filosofia do desenvolvimento web. As ferramentas gratuitas necessárias para esses testes são apresentadas no final do documento, no apêndice intitulado “As ferramentas da Web”.
2.1. Os componentes de uma aplicação web
Machine Serveur
15Cliente
Número | Função | Exemplos comuns |
OS Servidor | Linux, Windows | |
Servidor web | Apache (Linux, Windows) IIS (NT), PWS (Win9x), Cassini (Windows + plataforma .NET) | |
Scripts executados no lado do servidor. 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 o utiliza ou em outra máquina, via Internet. | Oracle (Linux, Windows) MySQL (Linux, Windows) Postgres (Linux, Windows) Access (Windows) SQL Server (Windows) | |
OS Cliente | Linux, Windows | |
Navegador da Web | Netscape, Internet Explorer, Mozilla, Opera | |
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. 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. Notations
A seguir, 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 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 IIS, PWS ou Cassini. É nessa raiz que as páginas da Web devem estar localizadas. Assim, o URL http://localhost/page1.htm corresponde ao arquivo <IIS-DocumentRoot>\page1.htm. | |
raiz da árvore de diretórios da linguagem 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, dentro de <tomcat>\webbapps\examples\jsp |
Para cada uma dessas ferramentas, consulte o apêndice, que fornece orientações para sua instalação.
2.4. 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, apresentamos diversos testes com diferentes servidores web e diferentes linguagens de programação, a fim de demonstrar a universalidade do conceito da web. Utilizaremos dois servidores web denominados Apache e IIS. Embora o IIS seja um produto comercial, ele está disponível em duas versões mais limitadas, porém gratuitas:
- PWS para máquinas com Win9x
- Cassini para máquinas Windows 2000 e XP
A pasta <IIS-DocumentRoot> é normalmente a pasta [lecteur:\inetpub\wwwroot], em que [lecteur] é a unidade (C, D, ...) na qual o IIS foi instalado. O mesmo se aplica ao PWS. Para o Cassini, a pasta <IIS-DocumentRoot> depende da forma como o servidor foi iniciado. No apêndice, é mostrado que o servidor Cassini pode ser iniciado em uma janela do DOS (ou por meio de um atalho) da seguinte maneira:
O aplicativo [WebServer], também conhecido como servidor web Cassini, aceita três parâmetros:
- /port: número da porta do serviço web. Pode ser qualquer valor. Por padrão, o valor é 80
- /path: caminho físico de uma pasta no disco
- /vpath: pasta virtual associada à pasta física anterior. É importante observar que a sintaxe não é /path=caminho, mas sim /vpath:caminho, ao contrário do que indica o painel de ajuda acima.
Se o Cassini for iniciado da seguinte maneira:
então a pasta P é a raiz da árvore de diretórios da web do servidor Cassini. Portanto, é essa pasta que é designada por <IIS-DocumentRoot>. Assim, no exemplo a seguir:
o servidor Cassini funcionará na porta 80 e a raiz de sua árvore de diretórios <IIS-DocumentRoot> é a pasta [d:\data\devel\webmatrix]. As páginas da Web a serem testadas deverão estar localizadas nessa raiz.
A seguir, cada aplicação web será representada por um único arquivo, que poderá ser criado com qualquer arquivo de texto. Não é necessário nenhum IDE.
2.4.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
Teste1
- inicie o servidor Apache
- colocar o script essai1.html em <apache-DocumentRoot>
- visualizar o URL http://localhost/essai1.html em um navegador
- Parar o servidor Apache
Teste 2
- iniciar o servidor IIS/PWS/Cassini
- colocar o script essai1.html no <IIS-DocumentRoot>
- visualizar o URL http://localhost/essai1.html com um navegador
2.4.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 IIS/PWS
- colocar o script essai2.asp em <IIS-DocumentRoot>
- Acesse o endereço http://localhost/essai2.asp com um navegador
2.4.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 mais 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.4.4. Um script PHP (Processador HyperText)
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
Teste 1
- consulte o arquivo de configuração srm.conf ou httpd.conf do Apache em <Apache>\confs
- A título informativo, verifique as linhas de configuração de php
- Inicie o servidor Apache
- colocar o essai4.php no <apache-DocumentRoot>
- acesse o URL em http://localhost/essai4.php
Teste2
- iniciar o servidor IIS/PWS
- A título informativo, verificar a configuração do PWS em relação ao PHP
- colocar o essai4.php no <IIS-DocumentRoot>\php
- solicitar o URL http://localhost/essai4.php
2.4.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 endereço http://localhost:8080/examples/jsp/heure.jsp
2.4.6. Uma página ASP.NET
O script heure1.aspx:
<html>
<head>
<title>Démo asp.net </title>
</head>
<body>
Il est <% =Date.Now.ToString("hh:mm:ss") %>
</body>
</html>
Uma vez executado pelo servidor web, este script gera a seguinte página:
Este teste requer um computador com Windows no qual a plataforma .NET tenha sido instalada (ver anexo).
- Coloque o script heure1.aspx em <IIS-DocumentRoot>
- Inicie o servidor IIS/CASSINI
- solicitar o URL http://localhost/heure1.aspx
2.4.7. 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).
2.5. 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.5.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 IIS/PWS
- script vbs1.html em <pws-DocumentRoot>
- acessar a URL http://localhost/vbs1.html com o navegador IE
Uma página da Web com um script JavaScript, no lado do navegador
La page : 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>
-
acesse a URL http://localhost/js1.html com o navegador IE ou Netscape
-
servidor IIS/PWS
- script js1.html no <pws-DocumentRoot>
- acesse a URL http://localhost/js1.html com o navegador IE ou Netscape
2.6. As interações cliente-servidor
Voltemos ao nosso esquema inicial, que ilustrava os participantes de uma aplicação web:
Máquina Servidor
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.6.1. O modelo OSI
O modelo de rede aberta denominado OSI (Open Systems Interconnection Reference Model), 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 os aplicativos geralmente próximos ao usuário, como o e-mail ou a transferência de arquivos. |
2.6.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 na camada Application e, portanto, se baseiam nos protocolos TCP-IP. As camadas Application das máquinas clientes e do servidor trocam mensagens que são encaminhadas às camadas 1 a 4 do modelo para serem encaminhadas ao destino. Para se comunicarem, as camadas de aplicação das duas máquinas devem “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 em branco
- 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.6.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.6.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:
com
protocolo | http para o serviço web. Um navegador também pode atuar como cliente de serviços como 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 abre uma comunicação TCP-IP com a máquina e a porta indicadas na seção 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 de dados entre um cliente e um servidor web, vamos usar uma ferramenta chamada curl. O curl é um aplicativo DOS que permite atuar como cliente de serviços da Internet que suportam diversos protocolos (HTTP, FTP, TELNET, GOPHER, ...). O curl está disponível no URL http://curl.haxx.se/. Aqui, é recomendável baixar a versão para Windows win32-nossl, já que a versão win32-ssl requer DLLs adicionais que não estão incluídas no pacote do curl. Esse pacote contém um conjunto de arquivos que basta descompactar em uma pasta que, a partir de agora, chamaremos de <curl>. Essa pasta contém um executável chamado [curl.exe]. Esse será nosso cliente para consultar servidores web. Abramos uma janela do DOS e acessemos a pasta <curl>:
dos>dir curl.exe
22/03/2004 13:29 299 008 curl.exe
E:\curl2>curl
curl: try 'curl --help' for more information
dos>curl --help | more
Usage: curl [options...] <url>
Options: (H) means HTTP/HTTPS only, (F) means FTP only
-a/--append Append to target file when uploading (F)
-A/--user-agent <string> User-Agent to send to server (H)
--anyauth Tell curl to choose authentication method (H)
-b/--cookie <name=string/file> Cookie string or file to read cookies from (H)
--basic Enable HTTP Basic Authentication (H)
-B/--use-ascii Use ASCII/text transfer
-c/--cookie-jar <file> Write cookies to this file after operation (H)
....
Vamos usar este aplicativo para consultar um servidor web e descobrir as trocas de dados entre o cliente e o servidor. Estaremos na seguinte situação:
O servidor web pode ser qualquer um. Nosso objetivo aqui é identificar as trocas de dados que ocorrerão entre o cliente web curl e o servidor web. Anteriormente, 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/aspnet/chap1/statique1.html. O servidor do serviço web é, portanto, localhost (=servidor local) e a porta 80. 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 CURL para solicitar o mesmo URL:
dos>curl http://localhost/aspnet/chap1/statique1.html
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
Vemos que o servidor web enviou a ele um conjunto de linhas de texto que representam o código HTML da página solicitada. Mencionamos anteriormente que a resposta de um servidor web assume a forma:
No entanto, aqui não vimos os cabeçalhos HTTP. Isso ocorre porque, por padrão, o [curl] não os exibe. A opção --include permite exibi-los:
E:\curl2>curl --include http://localhost/aspnet/cap1/statique1.html
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Mon, 22 Mar 2004 16:51:00 GMT
X-AspNet-Version: 1.1.4322
Cache-Control: public
ETag: "1C4102CEE8C6400:1C4102CFBBE2250"
Content-Type: text/html
Content-Length: 161
Connection: Close
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
O servidor enviou corretamente uma série de cabeçalhos HTTP, seguida por uma linha em branco:
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Mon, 22 Mar 2004 16:51:00 GMT
X-AspNet-Version: 1.1.4322
Cache-Control: public
ETag: "1C4102CEE8C6400:1C4102CFBBE2250"
Content-Type: text/html
Content-Length: 161
Connection: Close
o servidor informa
| |
o servidor se identifica. Neste caso, trata-se de um servidor Cassini | |
a data/hora da resposta | |
cabeçalho específico do servidor Cassini | |
fornece informações ao cliente sobre a possibilidade de armazenar em cache a resposta enviada a ele. O atributo [public] indica ao cliente que ele pode armazenar a página em cache. Um atributo [no-cache] teria indicado ao cliente que ele não deveria armazenar a página em cache. | |
... | |
o servidor informa que enviará texto (text) no formato HTML (html). | |
número de bytes do documento que será enviado após os cabeçalhos HTTP. Esse número é, na verdade, o tamanho em bytes do arquivo essai1.html: | |
o servidor informa que encerrará a conexão assim que o documento for enviado |
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 em branco 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 novamente nosso cliente [curl] para solicitar o mesmo recurso, mas, desta vez, solicitando apenas os cabeçalhos da resposta:
dos>curl --head http://localhost/aspnet/chap1/statique1.html
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:11:54 GMT
Cache-Control: public
ETag: "1C410A504D60680:1C410A58621AD3E"
Content-Type: text/html
Content-Length: 161
Connection: Close
Obtemos o mesmo resultado de antes, sem o documento HTML. 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 4.052 bytes:
Vamos agora usar o cliente [curl]:
dos>curl --head http://localhost/aspnet/chap1/univ01.gif
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:18:44 GMT
Cache-Control: public
ETag: "1C410A6795D7500:1C410A6868B1476"
Content-Type: image/gif
Content-Length: 4052
Connection: Close
Observe-se os seguintes pontos no ciclo de solicitação-resposta acima:
| |
| |
|
2.6.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, vimos o que o cliente recebia, mas não o que ele enviava. Vamos usar a opção [--verbose] do curl para ver também o que o cliente envia ao servidor. Comecemos solicitando a página estática:
dos>curl --verbose http://localhost/aspnet/chap1/statique1.html
* About to connect() to localhost:80
* Connected to portable1_tahe (127.0.0.1) port 80
> GET /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
< HTTP/1.1 200 OK
< Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
< Date: Tue, 23 Mar 2004 07:37:06 GMT
< Cache-Control: public
< ETag: "1C410A504D60680:1C410A58621AD3E"
< Content-Type: text/html
< Content-Length: 161
< Connection: Close
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
* Closing connection #0
Primeiramente, o cliente [curl] estabelece uma conexão TCP/IP com a porta 80 da máquina localhost (=127.0.0.1)
Assim que a conexão é estabelecida, ele envia sua solicitação HTTP. Trata-se de uma sequência de linhas de texto terminada por uma linha vazia:
GET /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
A solicitação HTTP de um cliente da Web tem duas funções:
- indicar o recurso desejado. Essa é a função da primeira linha, GET
- fornecer informações sobre o cliente que está fazendo a solicitação, para que o servidor possa, eventualmente, adaptar sua resposta a esse tipo específico de cliente.
O significado das linhas enviadas acima pelo cliente [curl] é o seguinte:
para solicitar um determinado recurso de acordo com uma determinada versão do protocolo HTTP. O servidor envia uma resposta no formato HTTP, seguida por uma linha vazia e, em seguida, pelo recurso solicitado | |
para indicar quem é o cliente | |
para especificar (protocolo HTTP 1.1) a máquina e a porta do servidor web consultado | |
aqui para especificar que o cliente não gerencia cache. | |
tipos MIME especificando os tipos de arquivos que o cliente sabe gerenciar |
Vamos repetir a operação com a opção --head do [curl]:
dos>curl --verbose --head --output reponse.txt http://localhost/aspnet/chap1/statique1.html
* About to connect() to localhost:80
* Connected to portable1_tahe (127.0.0.1) port 80
> HEAD /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
< HTTP/1.1 200 OK
< Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
< Date: Tue, 23 Mar 2004 07:54:22 GMT
< Cache-Control: public
< ETag: "1C410A504D60680:1C410A58621AD3E"
< Content-Type: text/html
< Content-Length: 161
< Connection: Close
Vamos nos concentrar apenas nos cabeçalhos HTTP enviados pelo cliente:
HEAD /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Apenas o comando que solicita o recurso foi alterado. Em vez de um comando GET, agora temos um comando HEAD. Esse comando solicita que a resposta do servidor se limite aos cabeçalhos HTTP e que ele não envie o recurso solicitado. A captura de tela acima não exibe os cabeçalhos HTTP recebidos. Estes foram armazenados em um arquivo devido à opção [--output reponse.txt] do comando [curl]:
dos>more reponse.txt
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:54:22 GMT
Cache-Control: public
ETag: "1C410A504D60680:1C410A58621AD3E"
Content-Type: text/html
Content-Length: 161
Connection: Close
2.6.4. Conclusão
Analisamos a estrutura da solicitação de um cliente web e da resposta enviada pelo servidor web por meio de alguns exemplos. A comunicação ocorre por meio do protocolo HTTP, um conjunto de comandos em formato de texto trocados entre os dois participantes. A solicitação do cliente e a resposta do servidor seguem a mesma estrutura abaixo:
No caso de uma solicitação (frequentemente chamada de requisição) do cliente, a parte [Document] geralmente está ausente. No entanto, é possível que um cliente envie um documento ao servidor. Ele faz isso por meio de um comando chamado PUT. Os dois comandos usuais para solicitar um recurso são GET e POST. Este último será apresentado um pouco mais adiante. O comando HEAD permite solicitar apenas os cabeçalhos HTTP. Os comandos GET e POST são os mais utilizados por clientes da web do tipo navegador.
A pedido de um cliente, o servidor envia uma resposta com a mesma estrutura. O recurso solicitado é transmitido na parte [Document], a menos que o comando do cliente tenha sido HEAD; nesse caso, apenas os cabeçalhos HTTP são enviados.
2.7. 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 na 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.7.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");
}//excluir
</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.7.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.7.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 entre si. | |
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.7.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.7.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.7.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.7.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.7.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.7.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.7.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.7.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.7.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.7.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.7.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. A página analisada anteriormente é uma página estática. Para ter acesso aos cabeçalhos HTTP enviados pelo navegador que solicitará esse documento, vamos transformá-la em uma página dinâmica para um servidor web .NET (IIS ou Cassini). Não se trata aqui de abordar a tecnologia .NET, que será discutida no próximo capítulo, mas sim das interações cliente-servidor. O código da página ASP.NET é o seguinte:
<%@ Page Language="vb" CodeBehind="params.aspx.vb" AutoEventWireup="false" Inherits="ConsoleApplication1.params" %>
<script runat="server">
Private Sub Page_Init(Byval Sender as Object, Byval e as System.EventArgs)
' salva a consulta
saveRequest
end sub
Private Sub saveRequest
' salva a solicitação atual em request.txt na pasta da página
dim requestFileName as String=Me.MapPath(Me.TemplateSourceDirectory)+"\request.txt"
Me.Request.SaveAs(requestFileName,true)
end sub
</script>
<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">
....
</body>
</html>
Ao conteúdo HTML da página em análise, adicionamos uma seção de código em VB.NET. Não faremos comentários sobre esse código, exceto para dizer que, a cada chamada do documento acima, o servidor web salvará a solicitação do cliente web no arquivo [request.txt], localizado na pasta do documento chamado.
2.7.2.1. Método GET
Vamos fazer um primeiro teste, no qual, no código HTML do documento, a tag FORM é definida da seguinte forma:
<form method="get">
O documento anterior (HTML + código VB) é chamado de [params.aspx]. Ele é colocado na estrutura de diretórios de um servidor web .NET (IIS/Cassini) e acessado pela URL http://localhost/aspnet/chap1/params.aspx:
O navegador acabou de fazer uma solicitação e sabemos que ela foi registrada no arquivo [request.txt]. Vamos examinar o conteúdo desse arquivo:
GET /aspnet/chap1/params.aspx HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0,1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Encontramos elementos já vistos com o cliente [curl]. Outros aparecem pela primeira vez:
o cliente solicita ao servidor que não feche a conexão após sua resposta. Isso permitirá que ele utilize a mesma conexão para uma solicitação posterior. A conexão não permanece aberta indefinidamente. O servidor a fechará após um período prolongado de inatividade. | |
tempo, em segundos, durante o qual a conexão [Keep-Alive] permanecerá aberta | |
Categoria de caracteres que o cliente sabe processar | |
Lista de idiomas preferidos pelo cliente. |
Preenchemos o formulário da seguinte maneira:
Utilizamos o botão [Envoyer] acima. Seu código HTML é o seguinte:
Ao clicar em um botão do tipo [Submit], o navegador envia os parâmetros do formulário (tag <form>) para o URL indicado no atributo [action] da tag <form action="URL">, caso exista. Se esse atributo não existir, os parâmetros do formulário são enviados para o URL que gerou o formulário. É o que ocorre neste caso. O botão [Envoyer] deve, portanto, gerar uma solicitação do navegador para o URL [http://localhost/aspnet/chap1/params.aspx] com o envio dos parâmetros do formulário. Como a página [params.aspx] armazena a solicitação recebida, deveríamos saber como o cliente enviou esses parâmetros. Vamos tentar. Clicamos no botão [Envoyer]. Recebemos a seguinte resposta do navegador:
Essa é a página inicial, mas podemos observar que o valor URL mudou no campo [Adresse] do navegador. Ele ficou assim:
http://localhost/aspnet/chap1/params.aspx?R1=Sim&C1=um&C2=dois&txtSaisie=programação+web&txtMdp=issoésegredo&areaSaisie=os+fundamentos+da%0D%0Aprogramação+web&cmbValeurs=opção3&lst1=lista3&lst2=lista1&lst2=lista3&cmdRenvoyer=Enviar&secret=uneValeur
Percebe-se que as opções selecionadas no formulário aparecem no URL. Vejamos o conteúdo do arquivo [request.txt], que armazenou a solicitação do cliente:
GET /aspnet/chap1/params.aspx?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 HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0,1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
Referer: http://localhost/aspnet/chap1/params.aspx
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Encontramos uma solicitação HTTP bastante semelhante à que havia sido feita inicialmente pelo navegador quando ele solicitou o documento sem enviar parâmetros. Há duas diferenças:
Os parâmetros do formulário foram adicionados após o URL do documento na forma ?param1=val1¶m2=val2&... | |
o cliente indica, por meio desse cabeçalho HTTP, o URL do documento que estava exibindo quando fez a solicitação |
Vamos examinar mais de perto como os parâmetros foram passados no comando GET URL?param1=valor1¶m2=valor2&... HTTP/1.1, em que parami são os nomes dos controles do formulário da web e “valor” os valores a eles associados. 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: mostra 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 |
Podemos nos perguntar o que o servidor fez com os parâmetros que lhe foram passados. Na verdade, nada. Ao receber o comando
GET /aspnet/chap1/params.aspx?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 HTTP/1.1
o servidor web transmitiu os parâmetros para o URL no documento http://localhost/aspnet/chap1/params.aspx, e para o c.a.d no documento que criamos inicialmente. Não escrevemos nenhum código para recuperar e processar os parâmetros que o cliente nos envia. Portanto, tudo ocorre como se a solicitação do cliente fosse simplesmente:
É por esse motivo que, em resposta ao nosso botão [Envoyer], obtivemos a mesma página que a obtida inicialmente ao solicitar o URL [http://localhost/aspnet/chap1/params.aspx] sem parâmetros.
2.7.2.2. Método POST
O documento HTML está agora configurado para que o navegador utilize o método POST para enviar os valores do formulário ao servidor web:
Solicitamos o novo documento por meio do URL [http://localhost/aspnet/chap1/params.aspx], preenchemos o formulário da mesma forma que no método GET e enviamos os parâmetros ao servidor com o botão [Envoyer]. Recebemos do servidor a seguinte página de resposta:
Assim, obtemos o mesmo resultado que com os métodos GET e c.a.d: a página inicial. Notamos uma diferença: no campo [Adresse] do navegador, os parâmetros transmitidos não aparecem. Agora, vamos examinar a solicitação enviada pelo cliente e que foi armazenada no arquivo [request.txt]:
POST /aspnet/chap1/params.aspx HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Content-Length: 210
Content-Type: application/x-www-form-urlencoded
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0,1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
Referer: http://localhost/aspnet/chap1/params.aspx
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecrey&areaSaisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&cmdRenvoyer=Envoyer&secret=uneValeur
Novidades na consulta HTTP do cliente:
a consulta GET foi substituída pela consulta POST. Os parâmetros não estão mais presentes nesta primeira linha da consulta. É possível observar que agora eles estão posicionados após a consulta HTTP, após uma linha em branco. Sua codificação é idêntica à que tinham na consulta GET. | |
número de caracteres “enviados”, c.a.d. O número de caracteres que o servidor web deverá ler após receber os cabeçalhos HTTP para recuperar o documento enviado pelo cliente. O documento em questão é, neste caso, a lista de valores do formulário. | |
especifica o tipo de documento que o cliente enviará após os cabeçalhos HTTP. O tipo [application/x-www-form-urlencoded] indica que se trata de um documento contendo valores de formulário. |
Existem dois métodos para transmitir dados a um servidor web: GET e POST. 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. Conclusion
Este capítulo apresentou diversos conceitos básicos do desenvolvimento web:
- as diversas ferramentas e tecnologias disponíveis (Java, ASP, asp.net, PHP, Perl, VBScript, JavaScript)
- as interações cliente-servidor por meio do protocolo HTTP
- a criação de um documento utilizando a linguagem HTML
- a criação de formulários de preenchimento
Vimos, por meio de um exemplo, como um cliente pode enviar informações ao servidor web. Não abordamos como o servidor pode
- recuperar essas informações
- processá-las
- enviar ao cliente uma resposta dinâmica dependendo do resultado do processamento
Esse é o campo da programação web, tema que abordaremos no próximo capítulo com a apresentação da tecnologia ASP.NET.