O protocolo HTTP

HTTP é a sigla em língua inglesa de HyperText Transfer Protocol (Protocolo de Transferência de Hipertexto), um protocolo da camada de Aplicação do modelo OSI utilizado para transferência de dados na rede mundial de computadores, a World Wide Web

Por Hardware Pular para comentários
HTTP ? a sigla em l?ngua inglesa de HyperText Transfer Protocol (Protocolo de Transfer?ncia de Hipertexto), um protocolo da camada de Aplica??o do modelo OSI utilizado para transfer?ncia de dados na rede mundial de computadores, a World Wide Web. Tamb?m transfere dados de hiper-m?dia (imagens, sons e textos).

Normalmente, este protocolo utiliza o porta 80 e ? usado para a comunica??o de "sites" (s?tios), comunicando na linguagem HTML (Hipertext Markup Language, ou Linguagem de Marca??o de Hipertexto). Contudo, para haver comunica??o com o servidor do site ? necess?rio utilizar comandos adequados, que n?o est?o em linguagem HTML.

Para acedermos a outro documento a partir de uma palavra presente no documento actual podemos utilizar os chamados links/ (liga?es) ou ?ncoras. Estes documentos encontram-se num "site" (s?tio) com um endere?o de p?gina da Internet - e para entrarmos neles devemos digitar o respectivo endere?o, denominado URI (Universal Resource Indentifier 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.

Funcionamento do protocolo HTTP
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 et al (1999, p. 10), 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 um c?digo de opera??o bem sucedida ou um c?digo de erro, 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 atrav?s 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 (2001, p. 13), 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 (Fielding et al, 1999, p. 21), 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. Nesta 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. O cabe?alho ? 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 (cf. Fielding et al, 1999, p. 21). Estes 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 (cf. Bastos & Ladeira, 2001). 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 (cf. Fielding et al, 1999) est?o descritos todos os campos que pertencem a estes cabe?alhos.

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 o Content-Length que informa a quantidade de bytes que o corpo da mensagem cont?m. A Tabela 2 apresenta alguns tipos MIME.

Tabela 2 ? Alguns tipos MIME [2]
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


Requisi??o
De acordo com Fielding (1999, p. 24), 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 (BASTOS, Leonara de Oliveira; LADEIRA, Adriane Cristina. Protocolo HTTP.) 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), o qual ? composto pela identifica??o do protocolo, pelo endere?o do computador servidor e pelo documento requisitado (cf. Embratel, 2002).

Conex?es
Segundo Hirata ( p5,. HIRATA, Renato. Desempenho em Servidores Web de Grande Porte. 1999. Proposta de Tese de Mestrado ? Universidade Estadual de Campinas, S?o Paulo, 1999. Dispon?vel em: http://www.ic.unicamp.br/~ra951407/PROPOSTA.DOC. Acesso em: 25 fev. 2002), o HTTP/1.0 ? um protocolo stateless. 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(conex?o n?o-persistente). O ideal seria que apenas uma conex?o fosse utilizada para os pedidos e as respostas HTTP, diminuindo, assim, o overhead ocasionado pelas conex?es. Este tipo de conex?o ? chamado de conex?o persistente (Persistent Connection).

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, este processo ? chamado de pipelining (cf. Fielding et al, 1999, p. 30). 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 protocolos
Existem outros tipos de protocolos como o FTP (File Tranfer Protocol, ou Protocolo de Transfer?ncia de Arquivos), usado para envio de arquivos do computador para um servidor na Web, o SMTP (Simple Mail Transfer Protocol, ou Protocolo de Transfer?ncia de Correio Simples), protocolo usado para correio eletr?nico (e-mail), entre outros protocolos.

M?todos
O protocolo HTTP define oito m?todos que indicam a a??o a ser realizada no recurso especificado. Conforme Bastos & Ladeiras (2001), o m?todo determina o que o servidor deve fazer com o URL fornecido no momento da requisi??o de um recurso.

- GET: ? o m?todo mais comum: solicita algum recurso como um arquivo ou um script CGI (qualquer dado que estiver identificado pelo URI) por meio do protocolo HTTP. O m?todo GET ? reconhecido por todos os servidores.

Exemplo. Vemos abaixo uma ?conversa? entre um cliente e um servidor HTTP. O servidor possui a URL www.exemplo.com, porta 80.

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.

Resposta do servidor (seguido 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: ? o mesmo que GET, mas sem que o recurso seja retornado. ? usado para obter meta-informa?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.

A utiliza??o do m?todo POST 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 (cf. 46 HERRMANN, Eric. Aprenda em 1 semana programa??o CGI em Perl 5. Rio de Janeiro: Campus, 1997).

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: 30
Nome=NamePessoa&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).

Um servidor HTTP deve implementar ao menos os m?todos GET e HEAD.

Resposta
Para Fielding et al (1999, p. 26), 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
O Status-Line de uma resposta HTTP indica ao cliente se sua requisi??o foi bem sucedida ou n?o (cf. Herrman, 1997, p. 53). Esta situa??o ? fornecida atrav?s de um c?digo de retorno (Status-Code) e uma frase explicativa (Reason-Phrase). De acordo com Fielding et al (1999, p. 37), 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.

Fonte: Wikip?dia

Compartilhe com seus amigos:
Quer conversar com o(a) Redação, comente:
Carregar comentários
Quantos celulares a Motorola tem em linha?
5(14,59%)
10(58,94%)
15(11,26%)
20(7,42%)
26(7,79%)