Ao desenvolver aplicativos ISAPI ou CGI, é necessário compreender claramente os mecanismos de funcionamento dessas interfaces de programação. Todos os problemas encontrados na utilização da OPUSWEB se relacionam, direta ou indiretamente, com o desconhecimento dos padrões e mecanismos CGI e/ou ISAPI.
Por isso, a compreensão destes assuntos constitui requisito básico para desenvolver scripts, programas, extensões ou filtros para servidores Web.
Abordamos, inicialmente, alguma idéias básicas a respeito dos seguintes assuntos:
Os serviços da plataforma Web estão baseados no modelo cliente/servidor, que permite distribuir e compartilhar os seus componentes básicos, ou seja, a interface com o usuário, a lógica dos programas e os dados.
No modelo cliente/servidor, o cliente:
No modelo cliente/servidor, o servidor:
Nos modelos tradicionais, os clientes e os servidores são classificados de "magros" ou "gordos". Estes termos indicam mais uma relação funcional do que características físicas. Trata-se de uma divisão do trabalho ditada pelo perfil do próprio aplicativo. Por exemplo, é bastante freqüente que o servidor seja otimizado para fornecer dados a múltiplos clientes e, usualmente, a aplicação cliente é otimizada para, apenas, interagir com o usuário final.
O servidor é "gordo" quando toda a lógica funcional reside nele. Este é, ainda, o modelo mais comum na Web. O cliente "magro" é, usualmente, um Browser, que fornece apenas a interface com o usuário. Ou seja, as aplicações CGI ou ISAPI fornecem a lógica funcional dentro do servidor HTTP e o cliente apenas exibe os dados. Existem outros modelos cliente / servidor, com serviços distribuídos. Neste caso, as atividades são compartilhadas entre cliente e servidor.
Os clientes Web são também chamados "User agents" ou, simplesmente, Browsers. No passado, por serem os Browsers meras interfaces com o usuário, o modelo era "servidor gordo, cliente magro". Contudo, atualmente, existem tecnologias (por exemplo, Applets, Client-side Scripts, Style Sheets, plug-ins ...) que permitem maior grau de programação e processamento do lado do cliente.
A expressão cliente, ou "User Agent" se refere, usualmente, ao parceiro de uma sessão HTTP que inicia o pedido ("request") a ser atendido ("response") pelo servidor Web.
Na medida que a grande rede mundial (World Wide Web) cresce, em recursos e complexidade, novos tipos de "User Agents" são inventados para prover novas funcionalidades junto aos usuários.
Servidores Web são processos que aceitam conexões (ou seja, sessões HTTP) solicitadas por clientes Web (Browsers) e, em resposta, fornecem informações na forma de mensagens e documentos de variados tipos, por exemplo, textos, imagens, som, vídeo ... etc ...
O desenvolvimento de servidores Web começou em 1990 e, atualmente, existem centenas de milhares de servidores Web na Internet, além de um número desconhecido de servidores utilizados nas Intranets corporativas.
Inicialmente, e durante algum tempo, apenas havia opções de servidores Web para plataformas UNIX. Atualmente, existem bons Servidores Web para plataformas Win32 e Mac.
Os servidores Web utilizam o protocolo HTTP (Hypertext Transfer Protocol) que foi implementado para permitir uma transferência rápida e eficiente de documentos na Internet".
HTTP é um protocolo fácil de entender, pois é baseado no paradigma pedido e resposta (request e response). Uma transação HTTP, independente da sua complexidade, possui a seguinte estrutura elementar:
O protocolo HTTP é "stateless" por natureza. Isto quer dizer que cada transação (pedido e resposta) é completada de forma independente, não sendo preservadas as informações de status referentes às transações anteriormente completadas. Isto exige um nível maior de controle e complexidade na programação de aplicativos Web.
Existem vários métodos e recursos que permitem administrar essa complexidade das transações HTTP.
Como já dissemos, o protocolo HTTP é constituído de pedidos ("requests") e respostas ("responses"). Os "requests" são, usualmente, gerados, num formato padrão, pelo cliente Browser, atendendo a eventos como, por exemplo, o "click" do usuário sobre um hyperlink.
Existem vários métodos para o cliente encaminhar um pedido ao servidor Web. O método GET é adequado para obter informações do servidor. Porém, quando for necessário enviar dados para o servidor, geralmente é utilizado o método POST, que permite utilizar FORMs como entrada de dados.
O tipo de ação a ser executada pelo servidor Web é determinado pelo método adotado em relação ao pedido do cliente A codificação completa dos comandos e a sintaxe correta do pedido, em conformidade com o método adotado e as normas do protocolo HTTP, são fornecidas pelo Browser, de maneira automática. Não é necessário que o programa CGI ou ISAPI especifiquem os cabeçalhos do pedido HTTP, ou seja, os comandos que precedem o corpo do documento transferido.
Os pedidos do cliente são formulados em conformidade com as normas do protocolo HTTP. Cada pedido é acompanhado de um cabeçalho ("request header") , que proporciona informações adicionais a respeito da transação HTTP. Esses cabeçalhos constituem, de fato, um protocolo de entendimento entre o cliente Browser e o servidor Web. Veja, a seguir, um exemplo de cabeçalho de pedido tal como seria enviado pelo Browser Internet Explorer 3.0:
GET /default.htm HTTP/1.0 Accept: */* Accept-Language: en UA-pixels: 1024x768 UA-color: color16 UA-OS: Windows NT UA-CPU: x86 User-Agent: Mozilla/2.0 (compatible; MSIE 3.0B; Windows NT) Host: 199.1.154.46 |
Analisando o cabeçalho acima, vemos que:
Os aplicativos CGI ou ISAPI utilizam as informações dos cabeçalhos para montar o corpo da resposta. Desta forma, o cliente (Browser) pode receber o documento solicitado, sendo este apresentado da maneira mais correta e adequada possível.
A resposta do servidor a um pedido do cliente (caso a transação seja completada com sucesso), é precedida de códigos de status e cabeçalhos que definem as características das informações contidas nessa resposta.
Veja, a seguir, um exemplo de uma resposta do servidor Web:
HTTP/1.0 200 OK Server: Microsoft-IIS/2.0 Date: Fri, 31 Dez 1996 16:53:58 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Fri, 12 Jul 1996 01:30:00 GMT Content-Length: 4051 [linha em branco terminada com CRLF] <!doctype html public "-//IETF//DTD HTML//EN"> <html> <head> </head> <body background="/images/backgrnd.gif"> [ corpo da entidade documento ] |
Os principais cabeçalhos de pedido e resposta, especificados pelo protocolo HTTP, reconhecidos e utilizados pela maioria dos servidores Web e clientes Browser, são os seguintes:
|
Request Header |
Descrição |
|
Accept |
Especifica os tipos de mídia que serão aceitáveis na resposta do servidor. Pode ser utilizado para mostrar que o pedido é limitado a um conjunto de tipos de dado, por exemplo, um pedido solicitando uma imagem. |
|
Accept-Language |
Similar ao Accept. Indica um conjunto dos idiomas preferidos na resposta ao pedido. |
|
Authorization |
Serve para que o cliente se autentique a si mesmo |
|
Cache-Control |
Estabelece diretivas a serem observadas pelos mecanismos de caching, ao longo da cadeia de pedido/resposta. Estas diretivas se sobrepõem ao algoritmo padrão de caching. |
|
Content-Base |
Especifica a URI básica, a ser utilizada para resolver as referências relativas a URLs. |
|
Content-Length |
Informa o tamanho do corpo do documento sendo transmitido. |
|
Content-Type |
Especifica o tipo de mídia do documento enviado. |
|
Date |
Representa a data e hora em que a mensagem foi originada. |
|
Expires |
Representa a data/hora após a qual a entidade (documento) perde a validade. Esta informação é importante em relação ao controle de "caching" efetuado pelo Browser e ao "refresh" obrigatório quando as informações não são mais válidas. |
|
Host |
Especifica o Host Internet e o número da porta HTTP. |
|
Server |
Informa sobre o software utilizado pelo servidor que originou a resposta. |
|
User-Agent |
Guarda informações sobre o cliente (user agent) que originou o pedido. Esta informação pode ser utilizada com objetivos estatísticos, trace, log... etc ... |
|
Location |
Especifica a exata localização de um recurso, para ser usada, por exemplo em caso de redirecionamento de URLs |
A primeira linha, no cabeçalho de resposta, é a "linha de status", que informa a versão HTTP em uso e o código de status da transação, conforme a seguinte tabela:
|
Código |
Texto da resposta |
Descrição |
|
200 |
OK |
O pedido foi processado com sucesso |
|
201 |
Created |
O pedido foi processado com sucesso e um novo recurso foi criado. Este novo recurso pode ser referenciado pela URI(s) retornadas na resposta. |
|
202 |
Accepted |
O pedido foi aceito mas o processamento do mesmo ainda não foi completado. |
|
204 |
No Content |
O servidor processou o pedido mas não foram geradas informações para enviar de volta. |
|
300 |
Multiple Choices |
Este código de resposta não é diretamente usado pelo protocolo HTTP, mas serve para interpretar a classe 3XX de respostas. |
|
301 |
Moved Permanently |
O recurso requisitado foi associado de forma definitiva com uma outra nova URL. Quaisquer referências no futuro usarão esta URL. |
|
302 |
Moved Temporarily |
O recurso solicitado reside temporariamente numa outra URL |
|
304 |
Not Modified |
O cliente fez um GET condicional e o acesso foi permitido, mas o documento não foi modificado após a data especificada no campo "If-Modified-Since". O servidor responde com um status code sem enviar ao cliente o corpo da entidade documento. |
|
400 |
Bad Request |
O pedido do cliente não foi reconhecido pelo servidor, devido a uma sintaxe incorreta. |
|
401 |
Unauthorized |
O pedido precisa de autenticação do usuário. |
|
403 |
Forbidden |
O servidor entendeu o pedido mas não vai atendé-lo porque o usuário está proibido de executar o serviço solicitado. |
|
404 |
Not Found |
O servidor não achou a URI solicitada. |
|
500 |
Internal Server Error |
O servidor encontrou uma condição inesperada que impede atender o pedido do cliente. |
|
501 |
Not Implemented |
O servidor não consegue executar o pedido, por exemplo quando ele não reconhece o "request method" e, por tanto, não pode aplicá-lo a nenhum recurso. |
|
502 |
Bad Gateway |
O servidor, quando está atuando como Gateway ou proxy recebe uma resposta inválida de outro servidor. |
|
503 |
Service Unavailable |
O servidor não pode atender o pedido por estar temporariamente sobrecarregado ou em manutenção. |
As variáveis de ambiente (como são chamadas no CGI), ou variáveis do servidor (como são conhecidas na ISAPI), são usadas, geralmente, para passar informações entre o servidor WEB e o programa. A tabela que segue apresenta algumas das variáveis de ambiente mais utilizadas.
|
Nome da variável |
Descrição da variável |
|
CONTENT_LENGTH |
Especifica o tamanho dos dados sendo transferidos, conforme informado pelo cliente. |
|
CONTENT_TYPE |
Especifica o tipo da informação quando esta vai anexada (attached) ao pedido, como é o caso dos métodos POST e PUT. |
|
HTTP_USER_AGENT |
Informa o software cliente (Browser) utilizado. |
|
PATH_INFO |
Especifica uma informação adicional de percurso ("path"). Esta informação pode ser decodificada pelo servidor antes de ser passada para o script CGI ou ISAPI. |
|
QUERY_STRING |
Especifica a informação que acompanha o nome da URL, após o sinal de interrogação ("?"). |
|
REMOTE_HOST |
Especifica o nome do host que fez o pedido. Se o servidor não possuir esta informação, será fornecido o conteúdo da variável "REMOTE_ADDR". |
|
REMOTE_ADDR |
Especifica o endereço IP do host que fez o pedido.. |
|
REQUEST_METHOD |
Especifica o método com o qual está sendo feito o pedido. Pode ser: GET, HEAD, POST. |
|
SERVER_NAME |
Especifica o nome ou endereço IP do servidor. |
|
SERVER_PORT |
Número da porta HTTP pela qual o pedido foi atendido no servidor. |
|
HTTP_COOKIE |
Conteúdo de Cookies previamente definidas através do comando HTTP "Set Cookie: …", a ser especificado, dentro de programa OpusWEB, antes do comando OPUSWEB "Html_head()". |
|
SCRIPT_NAME |
Nome do script (programa, DLL ...) sendo executado no servidor. |