Hipertexto é o texto estruturado que utiliza ligações lógicas (hiperlinks) entrenós contendo texto. O HTTP é o protocolo para a troca ou transferência de hipertexto.
Coordenado pelaWorld Wide Web Consortium e aInternet Engineering Task Force, culminou na publicação de uma série deRequests for Comments; mais notavelmente oRFC 2616, de junho de 1999, que definiu o HTTP/1.1. Em Junho de 2014 foram publicados 6 RFC's para maior clareza do protocolo HTTP/1.1.[2] Em Março de 2015, foi divulgado o lançamento doHTTP/2. A atualização deixará o navegador com um tempo de resposta melhor e mais seguro. Ele também melhorará a navegação em smartphones.[3] Os trabalhos noHTTP/3 já começaram e suas versões beta estão em teste por grandes empresas.[4]
Para acedermos a outro documento a partir de uma palavra presente no documento actual podemos utilizarhiperligações (ou âncoras). Estes documentos se encontram no sítio com um endereço de página daInternet – 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 confundido comURL (Universal Resource Locator ou Localizador Universal de Recurso), um tipo de URI que pode ser directamente localizado.
O HTTP funciona como um protocolo derequisição-resposta no modelo computacionalcliente-servidor. Umnavegador web, por exemplo, pode ser ocliente e uma aplicação em um computador quehospeda umsítio da web pode ser oservidor. O cliente submete uma mensagem derequisição HTTP para o servidor. O servidor, que fornece osrecursos, como arquivosHTML e outros conteúdos, ou realiza outras funções de interesse do cliente, retorna uma mensagemresposta para o cliente. A resposta contém 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 deagente 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 beneficiam dos servidores decache web que entregam conteúdo em nome deservidores 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 deredes privadas podem facilitar a comunicação para o cliente sem um endereço globalmente roteável, transmitindo mensagens com servidores externos.
Basicamente, o HTTP define como clientes Web requisitam páginas Web aos servidores e como elas as transferem a clientes. Quando um usuário solicita uma página Web (acessa uma URL), o navegador envia ao servidor mensagens de requisição HTTP para os objetos da página. O servidor, por sua vez, recebe estas requisições e responde com mensagens de resposta HTTP que contém os objetos (...). O protocolo HTTP utiliza por padrão a porta 80 para comunicação (MACEDO et al., 2018).[5]
O HyperText Transfer Protocol é um protocolo de aplicação responsável pelo tratamento de pedidos e respostas entre cliente e servidor naWorld Wide Web. Ele surgiu da necessidade de distribuir informações pelaInternet 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 transaçõ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 textoASCII pela Internet, através de um único método de requisição, chamadoGET. 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 tipoMIME44 (Multipurpose Internet Mail Extension) e foram implementados novos métodos de requisição, chamadosPOST eHEAD.
No HTTP/1.1, versão do protocolo descrito naRFC 2616,[6] foi desenvolvido um conjunto de implementações adicionais ao HTTP/1.0, como por exemplo: o uso de conexões persistentes; o uso de servidoresproxy que permitem uma melhor organização dacache; 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 eproxies/gateways com outros protocolos, como oSMTP,NNTP,FTP,Gopher, eWAIS, permitindo o acesso a recursos disponíveis em aplicações diversas.[6]
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ãoTransmission Control Protocol (TCP) para umaporta particular de um servidor (normalmente a porta 80. VejaLista de portas dos protocolos TCP e UDP). 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.
O termo cookie é derivado do inglês que significa biscoito. Recebeu esse nome de uma antiga gíria usada pelos programadores que consistia em um programa que chamava um procedimento e recebia de volta algo que seria necessário apresentar novamente mais tarde para realizar algum trabalho. Foi criado pela Netscape para solucionar o problema do envio e solicitação de arquivos, que eram esquecidos pelo servidor e que poderiam ser usados por outros computadores com o mesmo IP conforme (TANEMBAUM, 2003), o que causava problemas, pois não se sabia na realidade se era ou não aquele usuário mesmo. Os cookies são arquivos ou strings e não são programas executáveis. Eles são tratados como dados pelo navegador, não existe nenhuma maneira dele ser usado como vírus, apesar de que podem ser explorados bugs no servidor e causar a ativação de um cookie como vírus, por um hacker. Basicamente ele é um grupo de dados trocados entre o servidor de páginas e o navegador colocado em um ficheiro criado no computador do usuário. Serve para manter a persistência das sessões HTTP. Ele funciona da seguinte forma: Um usuário solicita uma página da Web, nisso o servidor pode fornecer informações adicionais acompanhando a página solicitada. Essas informações podem incluir um cookie, um pequeno arquivo ou string (com quatro KB no máximo). Este cookie pode ter até 5 campos (figura abaixo): Domain, Path, Content, Expires, Secure. Domain informa de onde veio o cookie. O navegador confirma que os servidores estão enviando dados fieis a respeito de seu domínio. Cada domínio pode armazenar no máximo 20 cookies por cliente. O campo Path é um caminho na estrutura de diretórios do servidor que identifica as partes da árvore de arquivos do servidor que podem usar o cookie. Frequentemente, ele obtém o símbolo / (barra), que representa a árvore inteira. O campo Content utiliza a forma nome = valor, podendo o servidor definir da maneira que quiser tanto o valor quanto o nome, e é nele que fica armazenado o conteúdo do cookie. Expires é o campo que faz o cookie persistir, nele contém a data e o horário, e se ele estiver ausente o navegador descartara automaticamente após o termino da sessão. O último campo define se ele é seguro ou não.
Domain
Path
Content
Expires
Secure
toms-casino.com
/
CustomerlD=497793521
15 de outubro de 2002
17:00
Yes
joes-store.com
/
Cart=1-00501;1-07031;2-13721
11 de outubro de 2002
14:22
No
aportal.com
/
Prefs=Stk:SUNW+ORCL;Spt:Jet
s
31 de dezembro de 2010
23:59
No
sneaky.com 31-
/
UserID=3627239101
12-12
23:59
No
Figura x: Alguns exemplos de cookie.↵Fonte: (TANEMBAUM, 2003).
O cookie é usado para identificar um usuário que configurou uma página web, para que na próxima vez que ele entrar ela esteja configurada do modo em que ele deixou. Pode ser usado também quando se faz a solicitação de armazenamento de senha, na vez posterior em que entrar no site, a sua senha será lembrada. É usado também em sites de compra, como e-commerce, armazenando os produtos que o cliente colocou no carrinho para que no final da compra não necessite fazer todo o processo novamente.
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 protocolosTCP eIP (Internet Protocol, Protocolo de Internet) tornem possível a conexão entre clientes e servidores através desocketsTCP/IP.
De acordo com Fielding,[7] o HTTP utiliza o modelocliente-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 aURI, a versão do protocolo, uma mensagemMIME (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.
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,[8] os dois tipos de mensagens existentes no protocolo utilizam um formato genérico, definido naRFC 822, para a transferência de entidades.
Uma mensagem, tanto de requisição quanto de resposta, é composta, conforme definido naRFC 2616,[9] 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 sessã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.
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,request-header,response-header eentity-header.[10]
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.[11] 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 (response-header). NaRFC 2616,[12] estão descritos todos os campos que pertencem a esses cabeçalhos.
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, oContent-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.
De acordo com Fielding,[14] 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,[15]Request-URI é umidentificador 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 Locator), composto pela identificação do protocolo, pelo endereço do computador servidor e pelo documento requisitado.[16]
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,[17] o método determina o que o servidor deve fazer com o URL fornecido no momento da requisição de um recurso. Umservidor HTTP deve implementar ao menos os métodos GET e HEAD. Os métodos GET e POST são os que aparecem mais comumente durante odesenvolvimento web.
Umasolicitação HTTP, ouHTTP Request é uma maneira donavegador mostrar umapágina da internet utilizando um dos oito métodos de solicitação do protocolo HTTP.[18]
Além de solicitar um determinado arquivo, envia várias informação para o servidor, sendo elas: o seuIP, a versão do navegador que está usando, que página utilizou para pedir aHTTP Request e a idioma que você usa, entre outros.[18]
O método GET requisita uma representação do recurso especificado. Requisições usando GET devem apenasrecuperar dados e não devem ter qualquer outro efeito. (Isto também é verdade para alguns outros métodos HTTP.) OW3C publicou princípios de orientações sobre esta distinção, "O projeto deaplicações web devem ser informados pelos princípios acima, mas também por limitações relevantes."
Abaixo segue um exemplo de uma comunicação entre um cliente e um servidor HTTP. O servidor possui a URLwww.exemplo.com, porta 80.
Opedido do cliente (seguido por uma linha em branco, de maneira que o pedido termina com umnewline duplo, cada um composto por umcarriage return seguido de umLine Feed):
GET /index.html HTTP/1.1Host: www.exemplo.com
O cabeçalhoHost reconhece vários diferentes nomesDNS que tenham o mesmoIP.
Aresposta do servidor (seguida por uma linha em branco e o texto da página solicitada):
Variação doGET em que o recurso não é retornado. É usado para obtermetainformações por meio do cabeçalho da resposta, sem ter que recuperar todo o conteúdo.
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 programascript identificado noRequest-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 umaquery string, além de conter cabeçalhos adicionais especificando seu tamanho (Content-Length) 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étodoGET que os dados são anexados a URL, ficando visíveis ao usuário.[19] 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
O método PUT envia os dados de forma semelhante ao POST, através do corpo do HTTP a diferença entre os 2 métodos é semântica. Por exemplo:
Caso você necessite atualizar os dados de um usuário, utilizando o método PUT você pode os atualizar diversas vezes, pois o PUT vai sobrescrever os dados com isso ficará somente com um único registro atualizado.
Se você executasse este mesmo procedimento utilizando o método POST, você criaria diversos registros para cada requisição realizada.
Do HTTP/1.0 em diante, a primeira linha da resposta HTTP é chamadalinha de estado e inclui umcódigo de estado numérico (como "404") e umafrase de razão textual (como "Not Found" - Não Encontrado). A maneira que oagente de usuário manipula a resposta depende primeiramente do código e secundariamente noscabeç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, asfrases 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 afrase 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 afrase 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.
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. Taisconexões persistentes reduzem alatê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 deiní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 acodificaçã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. Opipelining 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 obyte serving, onde um servidor transmite apenas a porção de um recurso solicitado explicitamente por um cliente.
O HTTP é umprotocolo 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, algumasaplicações web implementam estado ousessões do lado servidor usando um ou mais de um dos métodos a seguir:
Para Fielding,[20] 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.
A linha inicial de uma resposta HTTP indica ao cliente se sua requisição foi bem sucedida ou não.[21] Essa situação é fornecida através de um código de retorno (Status-Code) e uma frase explicativa (Reason-Phrase). De acordo com Fielding,[22] 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 naRFC 2616, mas cada servidor pode definir seus próprios códigos.
Segundo Hirata,[23] 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, asobrecarga 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 depipelining.[24] Pode também dar-se o caso de ser estabelecida uma conexão sempipelining, 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çalhoConnection: 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.
Existem outros tipos de protocolos como oFTP (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 paracorreio eletrônico, entre outros protocolos.
GET <ficheiro> HTTP/1.1Host: <ip>User-Agent: <Agente>Connection: <tipo>
O agente é quem faz a ligação ao servidor, normalmente umnavegador. 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 doMozilla Firefox v3.6b5 (pt-BR, para Windows):
