Protocolos De Redes - HTTP

Hypertext Transfer Protocol

Protocolos Internet (TCP/IP)

Camada Protocolo

5.Aplicação

HTTP, SMTP, FTP, SSH,Telnet, SIP, RDP, IRC,SNMP, NNTP, POP3, IMAP,BitTorrent, DNS, Ping ...

4.Transporte

TCP, UDP, RTP, SCTP,DCCP ...

3.Rede

IP (IPv4, IPv6) , ARP, RARP,ICMP, IPsec ...

2.Enlace

Ethernet, 802.11 WiFi,IEEE 802.1Q, 802.11g,HDLC, Token ring, FDDI,PPP,Switch ,Frame relay,

1.Física

Modem, RDIS, RS-232,EIA-422, RS-449,Bluetooth, USB, ...

O Hypertext Transfer Protocol (HTTP), em português Protocolo de Transferência de Hipertexto, é um protocolo de comunicação (na camada de aplicação segundo o Modelo OSI) utilizado para sistemas de informação de hipermídia, distribuídos e colaborativos.1 Ele é a base para a comunicação de dados da World Wide Web.

Hipertexto é o texto estruturado que utiliza ligações lógicas (hiperlinks) entre nós contendo texto. O HTTP é o protocolo para a troca ou transferência de hipertexto.

Coordenado pela World Wide Web Consortium e a Internet Engineering Task Force, culminou na publicação de uma série de Requests for Comments; mais notavelmente o RFC 2616, de junho de 1999, que definiu o HTTP/1.1.

Para acedermos a outro documento a partir de uma palavra presente no documento actual podemos utilizar hiperligações (ou âncoras). Estes documentos se encontram no sítio com um endereço de página da Internet - e para acessá-los deve-se digitar o respectivo endereço, denominadoURI (Universal Resource Identifier ou Identificador Universal de Recurso), que não deve ser confundir com URL (Universal Resource Locator ou Localizador Universal de Recurso), um tipo de URI que pode ser directamente localizado.

Visão técnica geral

O HTTP funciona como um protocolo de requisição-resposta no modelo computacional cliente-servidor. Um navegador web, por exemplo, pode ser o cliente e uma aplicação em um computador que hospeda um sítio da web pode ser o servidor. O cliente submete uma mensagem de requisição HTTP para o servidor. O servidor, que fornece os recursos, como arquivos HTML e outros conteúdos, ou realiza outras funções de interesse do cliente, retorna uma mensagem resposta para o cliente. A resposta contem informações de estado completas sobre a requisição e pode também conter o conteúdo solicitado no corpo de sua mensagem.

Um navegador web é um exemplo de agente de usuário (AU). Outros tipos de agentes de usuário incluem o software de indexação usado por provedores de consulta (web crawler), navegadores vocais, aplicações móveis e outros software que acessam, consomem ou exibem conteúdo web.

O HTTP é projetado para permitir intermediações de elementos de rede para melhorar ou habilitar comunicações entre clientes e servidores. Sites web de alto tráfego geralmente se beneficial dos servidores de cache web que entregam conteúdo em nome de servidores de upstream para melhorar o tempo de resposta. Navegadores web armazenam os recursos web acessados anteriormente e reutilizam-nos quando possível para reduzir o tráfego de rede. Servidores proxy HTTP nas fronteiras de redes privadas podem facilitar a comunicação para os cliente sem um endereço globalmente roteável, transmitindo mensagens com servidores externos.

História

O HyperText Transfer Protocol é um protocolo de aplicação responsável pelo tratamento de pedidos e respostas entre cliente e servidor na World Wide Web. Ele surgiu da necessidade de distribuir informações pela Internet e para que essa distribuição fosse possível foi necessário criar uma forma padronizada de comunicação entre os clientes e os servidores da Web e entendida por todos os computadores ligados à Internet. Com isso, o protocolo HTTP passou a ser utilizado para a comunicação entre computadores na Internet e a especificar como seriam realizadas as transacções entre clientes e servidores, através do uso de regras básicas.

Este protocolo tem sido usado pela WWW desde 1990. A primeira versão de HTTP, chamada HTTP/0.9, era um protocolo simples para a transferência de dados no formato de texto ASCII pela Internet, através de um único método de requisição, chamado GET. A versão HTTP/1.0 foi desenvolvida entre 1992 e 1996 para suprir a necessidade de transferir não apenas texto. Com essa versão, o protocolo passou a transferir mensagens do tipo MIME44 (Multipurpose Internet Mail Extension) e foram implementados novos métodos de requisição, chamados POST e HEAD.

No HTTP/1.1, versão actual do protocolo descrito na RFC 2616, 2 foi desenvolvido um conjunto de implementações adicionais ao HTTP/1.0, como por exemplo: o uso de conexões persistentes; o uso de servidores proxy que permitem uma melhor organização da cache; novos métodos de requisições; entre outros. Afirma-se que o HTTP também é usado como um protocolo genérico para comunicação entre os agentes de utilizadores e proxies/gateways com outros protocolos, como o SMTP, NNTP, FTP, Gopher, e WAIS, permitindo o acesso a recursos disponíveis em aplicações diversas.2

Sessão HTTP

Uma sessão HTTP é uma sequência de transações de rede de requisição-resposta. Um cliente HTTP inicia uma requisição estabelecendo uma conexão Transmission Control Protocol (TCP) para uma porta particular de um servidor (normalmente a porta 80. Veja Lista de portas de protocolos). Um servidor HTTP ouvindo naquela porta espera por uma mensagem de requisição de cliente. Recebendo a requisição, o servidor retorna uma linha de estado, como "HTTP/1.1 200 OK", e uma mensagem particular própria. O corpo desta mensagem normalmente é o recurso solicitado, apesar de uma mensagem de erro ou outra informação também poder ser retornada.

Funcionamento

Um sistema de comunicação em rede possui diversos protocolos que trabalham em conjunto para o fornecimento de serviços. Para que o protocolo HTTP consiga transferir seus dados pela Web, é necessário que os protocolos TCP e IP (Internet Protocol, Protocolo de Internet) tornem possível a conexão entre clientes e servidores através de sockets TCP/IP.

De acordo com Fielding,3 o HTTP utiliza o modelo cliente-servidor, como a maioria dos protocolos de rede, baseando-se no paradigma de requisição e resposta. Um programa requisitante (cliente) estabelece uma conexão com um outro programa receptor (servidor) e envia-lhe uma requisição, contendo a URI, a versão do protocolo, uma mensagem MIME (padrão utilizado para codificar dados em formato de textos ASCII para serem transmitidos pela Internet) contendo os modificadores da requisição, informações sobre o cliente e, possivelmente, o conteúdo no corpo da mensagem.

O servidor responde com uma linha de status (status line) incluindo sua versão de protocolo e com os códigos de erro informando se a operação foi bem sucedida ou fracasso, seguido pelas informações do servidor, metainformações da entidade e possível conteúdo no corpo da mensagem. Após o envio da resposta pelo servidor, encerra-se a conexão estabelecida.

Mensagem HTTP

O protocolo HTTP faz a comunicação entre o cliente e o servidor por meio de mensagens. O cliente envia uma mensagem de requisição de um recurso e o servidor envia uma mensagem de resposta ao cliente com a solicitação. Segundo Foscarini,4 os dois tipos de mensagens existentes no protocolo utilizam um formato genérico, definido na RFC 822, para a transferência de entidades.

Uma mensagem, tanto de requisição quanto de resposta, é composta, conforme definido na RFC 2616,5 por uma linha inicial, nenhuma ou mais linhas de cabeçalhos, uma linha em branco obrigatória finalizando o cabeçalho e por fim o corpo da mensagem, opcional em determinados casos. Nessa seção serão apresentados os campos que compõem uma mensagem mais detalhadamente; ou seja, o HTTP apresenta o sítio ou local onde está a página da Internet.

Cabeçalho da mensagem

O cabeçalho da mensagem (header) é utilizado para transmitir informações adicionais entre o cliente e o servidor. Ele é especificado imediatamente após a linha inicial da transação (método), tanto para a requisição do cliente quanto para a resposta do servidor, seguido de dois pontos (:) e um valor. Existem quatro tipos de cabeçalhos que poderão ser incluídos na mensagem os quais são: general-header, requestheader, response-header e entity-header.6

Esses cabeçalhos são utilizados para enviar informações adicionais sobre a mensagem transmitida (general-header), a requisição e os clientes (request-header) que comunicam suas configurações e os formatos de documentos desejados como resposta.7 Além disso, são utilizados pelo servidor ao retornar o recurso no qual foi requisitado pelo cliente, para transmitir informações que descrevem as configurações do servidor e do recurso identificado pelo URI de requisição, e que não pertence à linha de status (responseheader). Na RFC 2616,8 estão descritos todos os campos que pertencem a esses cabeçalhos.

Alguns tipos MIME9

Exemplo Descrição

text/plain Arquivo no formato texto (ASCII)

text/html Arquivo no formato HTML, utilizado

como padrão para documentos Web

Image/gif Imagem com o formato GIF

Image/jpeg Imagem com o formato JPEG

application/zip Arquivo compactado

Corpo da mensagem

Uma mensagem HTTP pode conter um corpo de dados que são enviados abaixo das linhas de cabeçalho. Em uma mensagem de resposta, o corpo da mensagem é o recurso que foi requisitado pelo cliente, ou ainda uma mensagem de erro, caso este recurso não seja possível. Já em uma mensagem de requisição, o corpo pode conter dados que serão enviados diretamente pelo usuário ou um arquivo que será enviado para o servidor. Quando uma mensagem HTTP tiver um corpo, poderão ser incluídos cabeçalhos de entidades que descrevem suas características, como por exemplo, o Content-Type que informa o tipo MIME dos dados no corpo da mensagem e oContent-Length que informa a quantidade de bytes que o corpo da mensagem contém. A tabela ao lado apresenta alguns tipos MIME.

Requisição

De acordo com Fielding,10 uma mensagem de requisição do cliente é composta pelos seguintes campos: uma linha inicial (Request-Line); linhas de cabeçalhos (Request-header); uma linha em branco obrigatória e um corpo de mensagem opcional. A linha inicial de uma requisição é composta por três partes separadas por espaços: o método (Method), a identificação do URI (Request-URI) e a versão do HTTP (HTTP-Version) utilizado.

Segundo Bastos & Ladeira,11 Request-URI é um identificador uniforme de recurso (Uniform Resource Identifier) que identifica sobre qual recurso será aplicada a requisição. No protocolo HTTP, o tipo de URI utilizado é chamado de URL (Uniform Resource Locater), composto pela identificação do protocolo, pelo endereço do computador servidor e pelo documento requisitado.12,

Métodos

O protocolo HTTP define oito métodos (GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS e CONNECT) que indicam a ação a ser realizada no recurso especificado. Conforme Bastos e Ladeiras,13 o método determina o que o servidor deve fazer com o URL fornecido no momento da requisição de um recurso. Um servidor HTTP deve implementar ao menos os métodos GET e HEAD.

GET

Solicita algum recurso como um arquivo ou um script CGI (qualquer dado que estiver identificado pelo URI) por meio do protocolo HTTP. Por exemplo, segue abaixo uma comunicação entre um cliente e um servidor HTTP. O servidor possui a URL www.exemplo.com, porta 80.

O pedido do cliente (seguido por uma linha em branco, de maneira que o pedido termina com um newline duplo, cada um composto por um carriage return seguido de um Line Feed):

GET /index.html HTTP/1.1

Host: www.exemplo.com

O cabeçalho Host reconhece vários diferentes nomes DNS que tenham o mesmo IP.

A resposta do servidor (seguida por uma linha em branco e o texto da página solicitada):

HTTP/1.1 200 OK

Date: Mon, 23 May 2005 22:38:34 GMT

Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)

Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT

Etag: "3f80f-1b6-3e1cb03b"

Accept-Ranges: bytes

Content-Length: 438

Connection: close

Content-Type: text/html; charset=UTF-8

HEAD

Variação do GET em que o recurso não é retornado. É usado para obter metainformações por meio do cabeçalho da resposta, sem ter que recuperar todo o conteúdo.

POST

Envia dados para serem processados (por exemplo, dados de um formulário HTML) para o recurso especificado. Os dados são incluídos no corpo do comando. Sua utilização em uma requisição ocorre quando é necessário enviar dados ao servidor para serem processados, geralmente por um programa script identificado no Request-URI. Uma requisição por meio desse método sempre requer que as informações submetidas sejam incluídas no corpo da mensagem e formatadas como uma query string, além de conter cabeçalhos adicionais especificando seu tamanho (Content-Lenght) e seu formato (Content-Type). Por isso, esse método oferece uma maior segurança em relação aos dados transferidos, ao contrário do método GET que os dados são anexados a URL, ficando visíveis ao usuário.14 Por exemplo:,

POST /index.html HTTP/1.0

Accept: text/html

If-modified-since: Sat, 29 Oct 1999 19:43:31 GMT

Content-Type: application/x-www-form-urlencoded

Content-Length: 41

Nome=NomePessoa&Idade=99&Curso=Computacao

PUT

Envia certo recurso.

DELETE

Exclui o recurso.

TRACE

Ecoa o pedido, de maneira que o cliente possa saber o que os servidores intermediários estão mudando em seu pedido.

OPTIONS

Recupera os métodos HTTP que o servidor aceita.

CONNECT

Serve para uso com um proxy que possa se tornar um túnel SSL (um túnel pode ser usado, por exemplo, para criar uma conexão segura).

Códigos de estado

Ver também: Anexo:Lista de códigos de status HTTP

Do HTTP/1.0 em diante, a primeira linha da resposta HTTP é chamada linha de estado e inclui um código de estado numérico (como "404") e uma frase de razão textual (como "Not Found" - Não Encontrado). A maneira que o agente de usuário manipula a resposta depende primeiramente do código e secundariamente nos cabeçalhos de resposta. Códigos de estado personalizados podem ser usados, uma vez que, se o agente de usuário encontrar um código que ele não reconheça, ele pode usar o primeiro dígito do código para determinar a classe geral da resposta.

Da mesma forma, as frases de razão padrões são apenas recomendações e podem ser substituídas com "equivalentes locais" a critério do desenvolvedor web. Se o código de estado indicou um problema, o agente de usuário pode mostrar a frase de razão para o usuário, para que sejam fornecidas informações adicionais sobre a natureza do problema. O padrão também permite que o agente de usuário tente interpretar a frase de razão, apesar disto poder ser imprudente uma vez que o padrão especifica explicitamente que os códigos de estado são legíveis por máquina e asfrases de razão são legíveis por homens.

Conexões persistentes

Ver artigo principal: Conexão persistente HTTP

No HTTP/0.9 e 1.0, a conexão é fechada após um único par de requisição/resposta. No HTTP/1.1 um mecanismo de persistência de vida (keep-alive) foi introduzido, onde uma conexão pode ser reutilizada para mais de uma requisição. Tais conexões persistentes reduzem a latência de requisição perceptível, pois o cliente não precisa renegociar a conexão TCP após a primeira requisição ter sido enviada. Outro efeito colateral positivo é que em geral a conexão se torna mais rápida com o tempo devido ao mecanismo de início-lento do TCP.

A versão 1.1 do protocolo também faz melhoras na otimização de comprimento de banda para o HTTP/1.0. Por exemplo, o HTTP/1.1 introduziu a codificação de transferência em partes para permitir que o conteúdo em conexões persistentes sejam transmitidos em vez de armazenados temporariamente para posterior transmissão. O pipelining HTTP reduz ainda mais o tempo de atraso, permitindo que os clientes enviem várias requisições antes de esperar por cada resposta. Outra melhoria para o protocolo foi o byte serving, onde um servidor transmite apenas a porção de um recurso solicitado explicitamente por um cliente.

Estado de sessão HTTP

O HTTP é um protocolo sem estado. Um protocolo sem estado não exige que o servidor HTTP retenha informações ou estado sobre cada usuário para a duração de várias solicitações. Entretanto, algumas aplicações web implementam estado ou sessões do lado servidor usando um ou mais de um dos métodos a seguir:

• Variáveis ocultas dentro de formulários web

• Cookies HTTP

• Parâmetros de query string, por exemplo, /index.php?session_id=algum_código_único_de_sessão

Resposta

Para Fielding,15 uma mensagem de resposta do servidor é composta pelos seguintes campos: uma linha inicial (Status-Line); linhas de cabeçalhos (Responseheader); uma linha em branco obrigatória e um corpo de mensagem opcional. A linha inicial de uma resposta, chamada de linha de status, possui por sua vez três partes separadas por espaços: a versão do protocolo HTTP (HTTP-Version), um código de status (Status-Code) da resposta, que fornece o resultado da requisição, e uma frase de justificativa (Reason-Phrase) que descreve o código do status.

Códigos de retorno

A linha inicial de uma resposta HTTP indica ao cliente se sua requisição foi bem sucedida ou não.16 Essa situação é fornecida através de um código de retorno (Status-Code) e uma frase explicativa (Reason-Phrase). De acordo com Fielding,17 o código de status é formado por três dígitos e o primeiro dígito representa a classe que pertence classificada em cinco tipos:

• 1xx: Informational (Informação) – utilizada para enviar informações para o cliente de que sua requisição foi recebida e está sendo processada;

• 2xx: Success (Sucesso) – indica que a requisição do cliente foi bem sucedida;

• 3xx: Redirection (Redirecionamento) – informa a ação adicional que deve ser tomada para completar a requisição;

• 4xx: Client Error (Erro no cliente) – avisa que o cliente fez uma requisição que não pode ser atendida;

• 5xx: Server Error (Erro no servidor) – ocorreu um erro no servidor ao cumprir uma requisição válida.

O protocolo HTTP define somente alguns códigos em cada classe descritos na RFC 2616, mas cada servidor pode definir seus próprios códigos.

Conexões

Segundo Hirata,18 o HTTP/1.0 é um protocolo sem estado. Isto significa que as conexões entre um cliente e um servidor são encerradas após o envio de cada requisição ou resposta. Cada vez que uma conexão é estabelecida ou encerrada, é consumida uma grande quantidade de tempo da CPU, de largura de banda e de memória.

Na maioria das vezes, para se obter o resultado esperado, é necessário realizar mais de uma solicitação de recursos através de várias conexões. Por exemplo, no caso de uma página Web, que consiste de diversos arquivos (.html, .gif, .css, etc) é preciso que sejam feitas várias requisições para compor a página, uma conexão não-persistente. O ideal seria que apenas uma conexão fosse utilizada para os pedidos e as respostas HTTP, diminuindo, assim, a sobrecarga ocasionada pelas conexões, uma conexão persistente.

A conexão persistente, implementada como conexão padrão no protocolo HTTP/1.1, possibilita que uma conexão seja estabelecida para enviar várias requisições em seqüência sem a necessidade de esperar por cada resposta, no qual serão recebidas na mesma ordem em que as solicitações foram enviadas, um processo chamado de pipelining.19 Pode também dar-se o caso de ser estabelecida uma conexão sem pipelining, em que o cliente só faz nova requisição quando o servidor lhe envia a resposta, ou seja, o servidor fica inactivo até o objecto (.html, .gif, .css, etc) atingir o seu destino no cliente.

Se uma requisição incluir o cabeçalho Connection: close, a conexão será encerrada após o envio da resposta correspondente. Utiliza-se este cabeçalho quando não há suporte a conexões persistentes, quando for a última requisição a ser enviada nesta conexão, ou ainda, sempre que quiser encerrar a conexão mesmo que nem todas as requisições tenham sido completadas. Além disso, o servidor pode fechar uma conexão se estiver ociosa por um determinado período de tempo.

Outros protocolo

Existem outros tipos de protocolos como o FTP (File Transfer Protocol, ou Protocolo de Transferência de Arquivos), usado para envio de arquivos do computador para um servidor na Web, oSMTP (Simple Mail Transfer Protocol, ou Protocolo de Transferência de Correio Simples), protocolo usado para correio eletrônico, entre outros protocolos.

Esquema de comunicação

Pedido básico de HTTP cliente-servidor:

GET <ficheiro> HTTP/1.1

Host: <ip>

User-Agent: <Agente>

Connection: <tipo>

O agente é quem faz a ligação ao servidor, normalmente um navegador. O tipo indica como o servidor deve proceder com a conexão. É comumente utilizado para requisições persistentes.

Uma requisição completa pode exigir muitas informações. A requisição abaixo - utilizando o método POST - fora retirada do Mozilla Firefox v3.6b5 (pt-BR, para Windows):

POST /diretorio/arquivo.html HTTP/1.1

Host: www.exemplo.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-BR; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-alive: 115

Cookie: nome=valor; nome2=valor2

Connection: keep-alive

Content-Length: 28

usuario=exemplo&senha=123456

http://pt.wikipedia.org/wiki/Hypertext_Transfer_Protocol

O protocolo HTTP

Introdução ao protocolo HTTP

O protocolo HTTP (HyperText Transfer Protocol) é o protocolo mais utilizado na Internet desde 1990. A versão 0.9 destinava-se unicamente a transferir dados na Internet (em especial páginas Web escritas em HTML). A versão 1.0 do protocolo (a mais utilizada) permite doravante transferir mensagens com cabeçalhos que descrevem o conteúdo da mensagem utilizando uma codificação de tipo MIMO.

O objectivo do protocolo HTTP é permitir uma transferência de ficheiros (essencialmente no formato HTML) localizados graças a uma cadeia de caracteres chamada URL entre um navegador (o cliente) e um servidor Web (chamado de resto httpd nas máquinas UNIX).

Comunicação entre navegador e servidor

A comunicação entre o navegador e o servidor faz-se em dois tempos :

• O navegador efectua um pedido HTTP

• O servidor trata o pedido e seguidamente envia uma resposta HTTP

Na realidade, a comunicação efectua-se em mais tempo se considerarmos o tratamento do pedido pelo servidor. Dado que nos interessamos unicamente pelo protocolo HTTP, o tratamento do lado de servidor não será esclarecido no âmbito deste artigo…

Se este assunto lhe interessar, consulte o artigo sobre o tratamento dos CGI.

Pedido HTTP

Um pedido HTTP é um conjunto de linhas enviado ao servidor pelo navegador. Compreende:

• Uma linha de pedido : A linha compreende três elementos que devem ser separados por um espaço:

• O método

• O URL

• A versão do protocolo utilizado pelo cliente (geralmente HTTP/1.0)

• Os campos de cabeçalho do pedido : trata-se de um conjunto de linhas facultativas que permitem dar informações suplementares sobre o pedido e/ou o cliente (Navegador, sistema de exploração,…). Cada um destas linhas é composta por um nome que qualifica o tipo de cabeçalho, seguido de dois pontos (:) e do valor do cabeçalho

• O corpo do pedido : é um conjunto de linhas opcionais que devem ser separadas das linhas precedentes por uma linha vazia e permitindo por exemplo um envio de dados por um comando POST aquando do envio de dados ao servidor por um formulário

Um pedido HTTP tem por conseguinte a sintaxe seguinte (<crlf> significa regresso salto de linha):

METHODE URL VERSION<crlf>

EN-TETE : Valeur<crlf>

.

.

.

EN-TETE : Valeur<crlf>

Ligne vide<crlf>

CORPS DE LA REQUETE

Eis então um exemplo de pedido HTTP:

GET http://pt.kioskea.net HTTP/1.0

Accept : text/html

If-Modified-Since : Saturday, 15-January-2000 14:37:11 GMT

User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)

Comandos

Comando Descrição

GET Pedido do recurso situado na URL especificada

HEAD Pedido do cabeçalho do recurso situado na URL especificada

POST Envio de dados ao programa situado na URL especificada

PUT Envio de dados à URL especificada

DELETE Supressão do recurso situado na URL especificada

Rubricas

Nome da rubrica Descrição

Accept Tipo de conteúdo aceite pelo motor de pesquisa (por exemplo text/HTML). Ver tipos MIMO

Accept-Charset Jogo de caracteres esperado pelo motor de pesquisa

Accept-Encoding Codificação de dados aceite pelo motor de pesquisa

Accept-Language Linguagem esperada pelo motor de pesquisa (inglês, por defeito)

Authorization Identificação do motor de pesquisa junto do servidor

Content-Encoding Tipo de codificação do corpo do pedido

Content-Language Tipo de linguagem do corpo do pedido

Content-Length Comprimento do corpo do pedido

Content-Type Tipo de conteúdo do corpo do pedido (por exemplo text/HTML). Ver tipos MIMO

Date Data de início de transferência dos dados

Forwarded Utilizado pelas máquinas intermédias entre o motor de pesquisa e o servidor

From Permite especificar o e-mail do cliente

From Permite especificar que o documento deve ser enviado se tiver sido alterado a partir de uma certa data

Link Relação entre duas URL

Orig-URL URL de origem do pedido

Referer URL da ligação a partir da qual o pedido foi efectuado

User-Agent Cadeia dando informações sobre o cliente, como o nome e a versão do navegador, do sistema de exploração

Resposta HTTP

Uma resposta HTTP é um conjunto de linhas enviadas ao navegador pelo servidor. Compreende:

• Uma linha de estatuto : é uma linha que precisa a versão do protocolo utilizado e o estado do tratamento do pedido através de um código e de um texto explicativo. A linha compreende três elementos que devem ser separados por um espaço:

• A versão do protocolo utilizado

• O código de estatuto

• A significado do código

• Os campos de rubrica da resposta : trata-se de um conjunto de linhas facultativas que permitem dar informações suplementares sobre a resposta e/ou o servidor. Cada um destas linhas é composta de um nome que qualifica o tipo de rubrica, seguido de dois pontos (:) e do valor da rubrica

• O corpo da resposta : contem o documento pedido

Uma resposta HTTP tem por conseguinte a sintaxe seguinte (<crlf> significa salto de linha) :

VERSION-HTTP CODE EXPLICATION<crlf>

EN-TETE : Valeur<crlf>

.

.

.

EN-TETE : Valeur<crlf>

Ligne vide<crlf>

CORPS DE LA REPONSE

Eis aqui um exemplo de resposta HTTP :

HTTP/1.0 200 OK

Date : Sat, 15 Jan 2000 14:37:12 GMT

Server : Microsoft-IIS/2.0

Content-Type : text/HTML

Content-Length : 1245

Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT

CORPO DA RESPOSTA

Nome da rubrica Descrição

Content-Encoding Tipo de codificação do corpo da resposta

Content-Language Tipo de linguagem do corpo da resposta

Content-Length Comprimento do corpo da resposta

Content-Type Tipo de conteúdo do corpo da resposta (por exemplo text/HTML). Vertipos MIMO

Date Data de início de transferência dos dados

Expires Data limite de consumo dos dados

Forwarded Utilizado pelas máquinas intermédias entre o motor de pesquisa e o servidor

Location Redireccionamento para uma nova URL associada ao documento

Server Características do servidor que envia a resposta

Os códigos de resposta

São os códigos que vê quando o navegador não lhe consegue mostrar a página pedida. O código de resposta é constituído por três algarismos: o primeiro indica a classe de estatuto e seguintes a natureza exacta do erro.

Código Mensagem Descrição

10x</gras> Mensagem de informação Estes códigos não são utilizados na versão 1.0 do protocolo

20x</gras> Sucesso Estes códigos indicam o bom desenrolar da transacção

200 OK O pedido foi realizado correctamente

201 CREATED

Segue um comando POST, indica o sucesso, o corpo do resto do documento deve indicar a URL onde o documento recentemente criado deveria encontrar-se.

202 ACCEPTED O pedido foi aceite, mas o procedimento seguinte não foi realizado

203 PARTIAL INFORMATION Quando este código é recebido em resposta a um comandoGET, isto indica que a resposta não está completa.

204 NO RESPONSE O servidor recebeu o pedido mas não há informação a devolver

205 RESET CONTENT O servidor indica ao navegador para suprimir o conteúdo dos campos de um formulário

206 PARTIAL CONTENT Trata-se de uma resposta a um pedido que comporta a rubrica range. O servidor deve indicar a rubrica content-range

30x Redirecção Estes códigos indicam que o recurso já não está no lugar indicado

301 MOVED Os dados pedidos foram transferidos para um novo endereço

302 FOUND Os dados pedidos são de uma nova URL, contudo talvez tenham sido deslocados desde então...

303 METHOD Isto implica que o cliente deve tentar um novo endereço, tentando preferivelmente um outro método além do GET

304 NOT MODIFIED Se o cliente efectuar um comando GET condicional (perguntando se o documento foi alterado desde a última vez) e se o documento não tiver sido alterado, devolve este código.

40x Erro devido ao cliente Estes códigos indicam que o pedido está incorrecto

400 BAD REQUEST A sintaxe do pedido está mal formulada ou é impossível de satisfazer

401 UNAUTHORIZED O parâmetro da mensagem dá as especificações das formas de autorização aceitáveis. O cliente deve reformular o seu pedido com os bons dados de autorização

402 PAYMENT REQUIRED O cliente deve reformular o seu pedido com os bons dados de pagamento

403 FORBIDDEN O acesso ao recurso é simplesmente proibido

404 NOT FOUND Clássico! O servidor não encontrou nada no endereço indicado. Partiram sem deixar endereço…:)

50x Erro devido ao servidor Estes códigos indicam que houve um erro interno do servidor

500 INTERNAL ERROR O servidor encontrou uma condição inesperada que o impediu de satisfazer o pedido (às vezes acontecem coisas aos servidores…)

501 NOT IMPLEMENTED O servidor não suporta o serviço pedido (não podemos saber fazer tudo, não é?…)

502 BAD GATEWAY O servidor recebeu uma resposta inválida por parte do servidor que tentava aceder agindo como uma ponte estreita ou um proxy

503 SERVICE UNAVAILABLE O servidor não pode responder-lhe no momento presente, porque o tráfego é demasiado denso (todas as linhas do seu correspondente são ocupadas quererão recordar ulteriormente)

504 GATEWAY TIMEOUT A resposta do servidor foi demasiado longa no que diz respeito ao tempo durante o qual a ponte estreita estava preparada para o esperar (o tempo que lhe estava destinado esgotou-se…)

...