Hyper Text Transfer Protocol

O Protocolo de Transferência de Hipertexto (HTTP) é um protocolo de camada de aplicação no modelo de conjunto de protocolos da Internet para sistemas de informação distribuídos e colaborativos baseados em hipermeios. O HTTP é a base da comunicação de dados na World Wide Web, onde documentos de hipertexto incluem hiperlinks para outros recursos que o usuário pode acessar facilmente, por exemplo, com um clique do mouse ou tocando na tela em um navegador da web.

O desenvolvimento do HTTP foi iniciado por Tim Berners-Lee no CERN em 1989 e resumido em um documento simples descrevendo o comportamento de um cliente e um servidor usando a primeira versão do HTTP, chamada 0.9. Essa versão foi posteriormente desenvolvida, eventualmente se tornando pública na versão 1.0.

O desenvolvimento das primeiras Requisições para Comentários HTTP (RFCs) começou alguns anos depois em um esforço coordenado pelo Internet Engineering Task Force (IETF) e pelo World Wide Web Consortium (W3C), com o trabalho posterior sendo transferido para o IETF.

O HTTP/1 foi finalizado e totalmente documentado (como versão 1.0) em 1996. Evoluiu (como versão 1.1) em 1997 e suas especificações foram atualizadas em 1999, 2014 e 2022.

Sua variante segura, chamada HTTPS, é usada por mais de 80% dos sites. O HTTP/2, publicado em 2015, fornece uma expressão mais eficiente das semânticas do HTTP "na fiação". Em abril de 2023, ele é usado por 39% dos sites e suportado por quase todos os navegadores da web (mais de 97% dos usuários). É também suportado pelos principais servidores da web com Transport Layer Security (TLS) usando uma extensão de Application-Layer Protocol Negotiation (ALPN), onde é necessária a versão TLS 1.2 ou mais recente.

O HTTP/3, sucessor do HTTP/2, foi publicado em 2022. Ele agora é usado em mais de 26% dos sites e é suportado pela maioria dos navegadores da web, pelo menos parcialmente, com suporte de 94% dos navegadores da web. O HTTP/3 utiliza o QUIC em vez do TCP para o protocolo de transporte subjacente. Como o HTTP/2, ele não obsolesce as principais versões anteriores do protocolo. O suporte ao HTTP/3 foi adicionado ao Cloudflare e ao Google Chrome primeiro e também está habilitado no Firefox. O HTTP/3 tem menor latência para páginas da web do mundo real, se habilitado no servidor, carrega mais rápido do que o HTTP/2 e até mais rápido do que o HTTP/1.1 em alguns casos, sendo mais de 3 vezes mais rápido que o HTTP/1.1, que ainda é comumente usado.

Visão Técnica

O HTTP funciona como um protocolo de solicitação-resposta no modelo cliente-servidor. Um navegador da web, por exemplo, pode ser o cliente, enquanto um processo chamado servidor da web, em um computador que hospeda um ou mais sites, pode ser o servidor. O cliente envia uma mensagem de solicitação HTTP para o servidor. O servidor, que fornece recursos como arquivos HTML e outros conteúdos ou executa outras funções em nome do cliente, retorna uma mensagem de resposta para o cliente. A resposta contém informações de status sobre a conclusão da solicitação e pode também conter o conteúdo solicitado em seu corpo de mensagem.

Um navegador da web é um exemplo de agente do usuário (UA). Outros tipos de agentes do usuário incluem software de indexação usado por provedores de pesquisa (rastreadores da web), navegadores de voz, aplicativos móveis e outros tipos de software que acessam, consomem ou exibem conteúdo da web.

O HTTP é projetado para permitir que elementos de rede intermediários melhorem ou habilitem comunicações entre clientes e servidores. Sites de alto tráfego frequentemente se beneficiam de servidores de cache da web que entregam conteúdo em nome de servidores upstream para melhorar o tempo de resposta. Os navegadores da web armazenam em cache recursos da web acessados anteriormente e os reutilizam sempre que possível para reduzir o tráfego de rede. Servidores proxy HTTP em limites de redes privadas podem facilitar a comunicação de clientes sem um endereço globalmente roteável, encaminhando mensagens com servidores externos.

Para permitir que nós intermediários HTTP (servidores proxy, caches da web, etc.) realizem suas funções, alguns dos cabeçalhos HTTP (encontrados em solicitações/respostas HTTP) são gerenciados hop-a-hop, enquanto outros cabeçalhos HTTP são gerenciados end-to-end (gerenciados apenas pelo cliente de origem e pelo servidor web de destino).

O HTTP é um protocolo de camada de aplicação projetado dentro do framework do conjunto de protocolos da Internet. Sua definição presume um protocolo de camada de transporte subjacente e confiável. Na versão mais recente, o HTTP/3, o Transmission Control Protocol (TCP) não é mais usado, mas as versões mais antigas ainda são amplamente usadas e geralmente usam TCP. Elas também foram adaptadas para usar protocolos não confiáveis, como o User Datagram Protocol (UDP), que o HTTP/3 também (indiretamente) sempre utiliza, por exemplo, no HTTPU e no Simple Service Discovery Protocol (SSDP).

Os recursos HTTP são identificados e localizados na rede por Localizadores de Recursos Uniformes (URLs), usando os esquemas de Identificadores de Recursos Uniformes (URI)http e https, conforme definido em RFC 3986. Como definido em RFC 3986, os URIs são codificados como hiperlinks em documentos HTML, a fim de formar documentos de hipertexto interligados.

No HTTP/1.0, uma conexão TCP separada para o mesmo servidor é feita para cada solicitação de recurso.

No HTTP/1.1, em vez disso, uma conexão TCP pode ser reutilizada para fazer várias solicitações/respostas de recursos (ou seja, de páginas HTML, quadros, imagens, scripts, folhas de estilo, etc.).

O HTTP/2 é uma revisão do HTTP/1.1 anterior, a fim de manter o mesmo modelo cliente-servidor e os mesmos métodos de protocolo, mas com essas diferenças:

• Usar uma representação binária comprimida de metadados (cabeçalhos HTTP) em vez de uma representação textual, para que os cabeçalhos exijam muito menos espaço.
• Usar uma única conexão TCP/IP (normalmente criptografada) por domínio de servidor acessado em vez de 2 a 8 conexões TCP/IP.
• Usar um ou mais fluxos bidirecionais por conexão TCP/IP, nos quais solicitações e respostas HTTP são divididas e transmitidas em pequenos pacotes para resolver quase completamente o problema do bloqueio de cabeça de linha (HOLB).
• Adicionar uma capacidade de push para permitir que a aplicação do servidor envie dados para os clientes sempre que novos dados estiverem disponíveis (sem forçar os clientes a solicitar periodicamente novos dados para o servidor usando métodos de pesquisa).

As comunicações HTTP/2, portanto, experimentam muito menos latência e, na maioria dos casos, até mais velocidade do que as comunicações HTTP/1.1.

O HTTP/3, uma revisão do HTTP/2, foi publicado em 2022. Ele agora é usado em mais de 26% dos sites e é suportado pela maioria dos navegadores da web, pelo menos parcialmente, com suporte de 94% dos navegadores da web. O HTTP/3 utiliza o QUIC em vez do TCP como protocolo de transporte subjacente. Como o HTTP/2, ele não obsolesce as principais versões anteriores do protocolo. O suporte ao HTTP/3 foi adicionado ao Cloudflare e ao Google Chrome primeiro e também está habilitado no Firefox. O HTTP/3 tem menor latência para páginas da web do mundo real, se habilitado no servidor, carrega mais rápido do que o HTTP/2 e até mais rápido do que o HTTP/1.1 em alguns casos, sendo mais de 3 vezes mais rápido que o HTTP/1.1, que ainda é comumente usado.

História

O termo hipertexto foi cunhado por Ted Nelson em 1965 no Projeto Xanadu, que, por sua vez, foi inspirado pela visão de Vannevar Bush dos anos 1930 de um sistema de recuperação e gerenciamento de informações baseado em microfilme descrito em seu ensaio de 1945 "Conforme Podemos Pensar". Tim Berners-Lee e sua equipe no CERN são creditados por inventar o HTTP original, junto com o HTML e a tecnologia associada para um servidor web e uma interface do usuário do cliente chamada navegador web. Berners-Lee projetou o HTTP para ajudar na adoção de sua outra ideia: o projeto WorldWideWeb, que foi proposto pela primeira vez em 1989 e agora é conhecido como World Wide Web.

O primeiro servidor web foi ao ar em 1990. O protocolo usado tinha apenas um método, o GET, que solicitaria uma página a partir de um servidor. A resposta do servidor era sempre uma página HTML.

Resumo das Versões Importantes do HTTP

Versão	Ano de Introdução	Estado Atual
HTTP/0.9	1991	Obsoleto
HTTP/1.0	1996	Obsoleto
HTTP/1.1	1997	Padrão
HTTP/2	2015	Padrão
HTTP/3	2022	Padrão

• HTTP/0.9: Em 1991, a primeira versão oficial documentada do HTTP foi escrita como um documento simples, com menos de 700 palavras, e essa versão foi chamada de HTTP/0.9. Ela suportava apenas o método GET, permitindo que os clientes apenas recuperassem documentos HTML do servidor, sem suporte a outros formatos de arquivo ou carregamento de informações.

• HTTP/1.0-draft: Desde 1992, um novo documento foi escrito para especificar a evolução do protocolo básico em direção à próxima versão completa. Ele suportava tanto o método de solicitação simples da versão 0.9 quanto a solicitação GET completa, que incluía a versão HTTP do cliente. Este foi o primeiro dos muitos rascunhos não oficiais do HTTP/1.0 que antecederam o trabalho final no HTTP/1.0.

• W3C HTTP Working Group: Após decidir que novos recursos do protocolo HTTP eram necessários e que eles deveriam ser totalmente documentados como RFCs oficiais, o HTTP Working Group (HTTP WG, liderado por Dave Raggett) foi constituído no início de 1995 com o objetivo de padronizar e expandir o protocolo com operações estendidas, negociação estendida, meta-informação mais rica, atrelada a um protocolo de segurança que se tornou mais eficiente, adicionando métodos e campos de cabeçalho adicionais.

• HTTP/1.0: Em maio de 1996, a RFC 1945 foi publicada como uma revisão final do HTTP/1.0, que havia sido usado nos quatro anos anteriores como um rascunho pré-padronizado do HTTP/1.0 que já era usado por muitos navegadores da web e servidores da web.

• HTTP/1.1: Desde o início de 1996, os principais navegadores da web e desenvolvedores de servidores da web também começaram a implementar novos recursos especificados por rascunhos pré-padronizados do HTTP/1.1. A adoção do usuário final das novas versões de navegadores e servidores foi rápida. Em março de 1996, uma empresa de hospedagem na web relatou que mais de 40% dos navegadores usados na Internet estavam usando o novo cabeçalho HTTP/1.1 "Host" para permitir a hospedagem virtual. A mesma empresa de hospedagem na web relatou que, em junho de 1996, 65% de todos os navegadores que acessavam seus servidores estavam em conformidade com o HTTP/1.1 pré-padronizado.

• HTTP/1.1 adicionou também o HTTP pipelining para reduzir ainda mais o tempo de espera ao usar conexões persistentes, permitindo que os clientes enviem várias solicitações antes de esperar por cada resposta. Esta otimização nunca foi considerada realmente segura porque alguns servidores web e muitos servidores proxy, especialmente servidores proxy transparentes colocados na Internet/intranets entre clientes e servidores, não tratavam as solicitações em pipeline adequadamente (eles serviam apenas a primeira solicitação, descartando as outras, fechavam a conexão porque viam mais dados após a primeira solicitação ou alguns servidores proxy até retornavam respostas fora de ordem, etc.). Além disso, apenas solicitações HEAD e alguns GET (ou seja, limitados a solicitações de arquivos reais e, portanto, com URLs sem sequência de consulta usada como um comando, etc.) poderiam ser encadeados de forma segura e idempotente. Após muitos anos de luta com os problemas introduzidos pela ativação do encadeamento, esse recurso foi primeiro desativado e depois removido da maioria dos navegadores devido à adoção anunciada do HTTP/2.

• HTTP/2 estendeu o uso de conexões persistentes por meio da multiplexação de muitas solicitações/respostas concorrentes por meio de uma única conexão TCP/IP.

• HTTP/3 não usa conexões TCP/IP, mas QUIC + UDP para transportar protocolos, para melhorar a velocidade média das comunicações e evitar congestionamentos temporários ou desacelerações da conexão TCP que podem bloquear ou retardar o fluxo de dados de todos os seus fluxos (outra forma de "bloqueio de cabeçalho de linha").

Em 2020, os primeiros rascunhos de HTTP/3 foram publicados e os principais navegadores da web e servidores da web começaram a adotá-lo. Em 6 de junho de 2022, a IETF padronizou o HTTP/3 como RFC 9114.

Em junho de 2022, um lote de RFCs foi publicado, descontinuando muitos dos documentos anteriores e introduzindo algumas alterações menores e uma refatoração da descrição da semântica do HTTP em um documento separado.

Troca de Dados no HTTP

O HTTP é um protocolo de aplicação sem estado e requer uma conexão de transporte de rede confiável para a troca de dados entre o cliente e o servidor. Nas implementações de HTTP, são usadas conexões TCP/IP usando portas bem conhecidas (normalmente a porta 80 se a conexão não estiver criptografada ou a porta 443 se a conexão estiver criptografada, consulte também a Lista de números de porta TCP e UDP). No HTTP/2, é usada uma conexão TCP/IP mais canais de protocolo múltiplos. No HTTP/3, o protocolo de transporte de aplicativo QUIC sobre UDP é usado, não o TCP/IP.

Na arquitetura cliente-servidor, o servidor aguarda, ouve a porta especificada (por padrão, a porta 80 se a conexão não estiver criptografada, a porta 443 se estiver criptografada) para solicitações do cliente. Os navegadores da web são os clientes mais conhecidos, mas qualquer software cliente pode ser usado. Quando o servidor recebe uma solicitação HTTP, ele a interpreta e atende ao cliente com os recursos apropriados. O HTTP deve ser implementado em qualquer software de servidor da web de acordo com os padrões definidos pela RFC, que é mantida e publicada pelo IETF.

Métodos HTTP

O HTTP define um conjunto de métodos de solicitação para indicar a ação desejada a ser executada para um recurso identificado. Cada método HTTP tem um significado específico. Alguns dos métodos HTTP mais comuns são:

• GET: Solicita dados de um recurso específico. Um pedido GET não deve ter efeito colateral no servidor.

• POST: Envia dados para serem processados para um recurso identificado. É comum usar este método ao enviar um formulário da web.

• PUT: Atualiza um recurso existente com dados fornecidos. Se o recurso não existir, ele pode ser criado.

• DELETE: Remove um recurso específico.

• HEAD: Solicita uma resposta semelhante à de um pedido GET, mas sem o corpo da resposta. É usado para obter informações sobre o recurso, como os cabeçalhos de resposta, sem receber o corpo.

• OPTIONS: Solicita informações sobre os métodos de comunicação disponíveis para o recurso identificado.

• PATCH: Aplica modificações parciais a um recurso.

• CONNECT: Estabelece uma conexão de rede com um recurso, geralmente para usar como túnel SSL/TLS.

Esses métodos permitem que os clientes interajam com os servidores de várias maneiras, dependendo do que desejam fazer com um determinado recurso. Por exemplo, o método GET é usado para recuperar informações, enquanto o POST é usado para enviar informações para o servidor. Cada método tem seu próprio propósito e uso apropriado.

Cabeçalhos HTTP

Os cabeçalhos HTTP fornecem informações adicionais nas mensagens de solicitação e resposta HTTP. Eles ajudam a transmitir informações sobre o cliente, o servidor, o tipo de conteúdo e como a mensagem deve ser tratada. Alguns exemplos de cabeçalhos HTTP comuns incluem:

• User-Agent: Este cabeçalho informa o servidor sobre o navegador ou aplicativo que está fazendo a solicitação. Isso permite que o servidor saiba como formatar a resposta para atender às capacidades do cliente.

• Host: Este cabeçalho especifica o nome do host do servidor. Isso é usado quando vários sites estão hospedados no mesmo servidor.

• Content-Type: Este cabeçalho indica o tipo de conteúdo na mensagem de resposta, como HTML, JSON ou imagem.

• Location: Usado em respostas de redirecionamento para informar ao cliente a URL para a qual ele deve redirecionar.

• Authorization: Usado para autenticar o cliente perante o servidor. Isso é comumente usado em solicitações protegidas por senha.

• Accept-Language: Indica a preferência do idioma do cliente, permitindo que o servidor forneça conteúdo em um idioma preferido, se disponível.

• Cache-Control: Controla o cache do navegador, permitindo que o servidor especifique quanto tempo o recurso pode ser armazenado em cache no navegador.

Existem muitos outros cabeçalhos HTTP, cada um com seu próprio propósito. Os cabeçalhos desempenham um papel crucial na formatação e no processamento adequado das mensagens HTTP. Eles permitem que o servidor e o cliente se comuniquem de maneira eficaz, garantindo que os recursos sejam entregues corretamente.

Autenticação no HTTP

A autenticação no HTTP é o processo de verificar a identidade de um cliente ou servidor que faz uma solicitação ou resposta HTTP. Ela é fundamental para restringir o acesso a recursos protegidos e garantir que apenas usuários autorizados possam interagir com esses recursos. Existem várias maneiras de autenticar em um ambiente HTTP:

• Autenticação básica: Isso envolve a inclusão de um cabeçalho Authorization na solicitação HTTP que contém um nome de usuário e uma senha. Embora seja simples de implementar, não é muito seguro, pois as credenciais são facilmente decodificadas.

• Autenticação de token: Neste método, um token é gerado e usado para autenticar o cliente. Esse token pode ser usado em vez de uma senha e é normalmente mais seguro.

• Autenticação baseada em certificado: Os certificados digitais são usados para autenticar tanto o cliente quanto o servidor. Isso envolve o uso de criptografia assimétrica para verificar a identidade das partes.

• OAuth: É um protocolo de autorização que permite que aplicativos de terceiros acessem recursos em nome do usuário. Ele é amplamente utilizado em aplicativos que dependem de serviços de terceiros, como fazer login em aplicativos usando sua conta do Google ou Facebook.

• Bearer Token: Muitas vezes, um token chamado "Bearer Token" é usado para autenticar solicitações em serviços da web. Ele é inserido no cabeçalho de autorização e é usado para verificar a identidade do cliente que faz a solicitação.

A escolha do método de autenticação depende das necessidades de segurança do sistema e dos recursos disponíveis. É importante escolher um método que atenda aos requisitos de segurança do aplicativo e proteja as informações confidenciais.

Criptografia no HTTP

A criptografia no HTTP é essencial para proteger a privacidade e a segurança dos dados transmitidos pela rede. O HTTP pode ser criptografado usando o protocolo TLS (Transport Layer Security), que é a evolução do protocolo SSL (Secure Sockets Layer). Quando o HTTP é usado com criptografia, ele se torna HTTPS (HTTP Secure). O HTTPS fornece uma camada adicional de segurança para proteger as informações confidenciais, como senhas e informações de pagamento.

A criptografia HTTPS funciona através do estabelecimento de um canal de comunicação seguro entre o cliente e o servidor. Isso garante que os dados transmitidos sejam confidenciais e não possam ser interceptados por terceiros. A criptografia também permite que os clientes verifiquem a identidade do servidor, o que é importante para proteger contra ataques de "homem no meio" em que um atacante se faz passar pelo servidor.

Para configurar o HTTPS, um servidor da web precisa de um certificado digital emitido por uma autoridade de certificação confiável (CA). Esse certificado é usado para provar a identidade do servidor para os clientes. Quando um cliente se conecta a um servidor HTTPS, o servidor envia seu certificado digital para o cliente. O cliente, por sua vez, verifica a validade do certificado e, se estiver satisfeito, estabelece uma conexão criptografada com o servidor.

A criptografia HTTPS se tornou a norma para muitos sites, especialmente aqueles que lidam com informações sensíveis. Garante a privacidade dos dados do usuário e protege contra várias formas de ataques cibernéticos. Além disso, os motores de busca geralmente classificam os sites HTTPS mais alto em seus resultados de pesquisa, o que incentiva ainda mais a adoção do HTTPS.

REST (Representational State Transfer)

O REST (Representational State Transfer) é um estilo de arquitetura de software que é amplamente usado na construção de sistemas web. Ele é baseado em princípios simples que promovem a escalabilidade, a simplicidade e a interoperabilidade entre sistemas. O REST utiliza vários conceitos-chave, incluindo:

• Recursos: Os recursos são entidades que podem ser acessadas por meio de uma URL. No contexto do HTTP, os recursos podem ser páginas da web, imagens, vídeos, serviços da web ou qualquer outra coisa que possa ser identificada por uma URL.

• Verbos HTTP: Os verbos HTTP (GET, POST, PUT, DELETE, etc.) são usados para realizar operações nos recursos. Por exemplo, o verbo GET é usado para recuperar informações de um recurso, enquanto o POST é usado para criar um novo recurso.

• Representações: Os recursos podem ter várias representações, como HTML, XML, JSON, etc. Cada representação fornece uma visão do estado atual do recurso.

• Stateless (sem estado): O REST é um estilo de arquitetura sem estado, o que significa que cada solicitação do cliente para o servidor deve conter todas as informações necessárias para entender e processar a solicitação. O servidor não mantém nenhum estado da sessão entre solicitações.

• Uniform Interface (Interface Uniforme): O REST segue uma interface uniforme que simplifica a comunicação entre clientes e servidores. Isso inclui a identificação de recursos por meio de URLs, o uso consistente de verbos HTTP e o uso de representações para transmitir o estado.

O REST é amplamente utilizado na construção de serviços da web e é uma abordagem popular para criar APIs da web. Ele oferece uma maneira simples e escalável de projetar sistemas web que são fáceis de entender e manter.

WebSockets

Embora o HTTP tenha sido projetado principalmente para transferir dados de maneira assíncrona por meio de solicitações e respostas, há casos em que a comunicação em tempo real é necessária. É aí que os WebSockets entram em cena.

Os WebSockets são um protocolo de comunicação bidirecional que permite a transferência de dados em tempo real entre clientes e servidores. Em vez de usar o modelo tradicional de solicitação e resposta, os WebSockets estabelecem uma conexão persistente entre o cliente e o servidor, permitindo que os dados fluam em ambas as direções a qualquer momento.

Os WebSockets são usados em uma variedade de aplicativos da web que exigem comunicação em tempo real, como bate-papos on-line, jogos multijogador, feeds de notícias em tempo real e muito mais. Eles são uma alternativa eficaz ao modelo tradicional baseado em HTTP para cenários em que a latência é crítica.

 

Autenticação HTTP

O HTTP fornece vários esquemas de autenticação, como autenticação de acesso básica e autenticação de acesso digest, que operam por meio de um mecanismo de desafio e resposta, em que o servidor identifica e emite um desafio antes de fornecer o conteúdo solicitado.

O HTTP fornece um quadro geral para controle de acesso e autenticação, por meio de um conjunto extensível de esquemas de autenticação de desafio-resposta, que podem ser usados por um servidor para desafiar uma solicitação do cliente e pelo cliente para fornecer informações de autenticação.

Os mecanismos de autenticação descritos acima pertencem ao protocolo HTTP e são gerenciados pelo software HTTP do cliente e do servidor (se configurado para exigir autenticação antes de permitir o acesso do cliente a um ou mais recursos da web) e não pelas aplicações da web que usam uma sessão de aplicação da web.

Domínios de Autenticação

A especificação de Autenticação HTTP também fornece uma construção arbitrária específica de implementação para dividir ainda mais os recursos comuns em um determinado URI raiz. A cadeia do valor do domínio, se presente, é combinada com o URI raiz canônico para formar o componente de espaço de proteção do desafio. Isso permite que o servidor defina separadamente os escopos de autenticação sob um único URI raiz.

Sessão de Aplicação HTTP

O HTTP é um protocolo sem estado. Um protocolo sem estado não requer que o servidor da web retenha informações ou estado sobre cada usuário durante várias solicitações.

Algumas aplicações da web precisam gerenciar sessões de usuário, então elas implementam estados ou sessões do lado do servidor, usando, por exemplo, cookies HTTP ou variáveis ocultas em formulários da web.

Para iniciar uma sessão de usuário em uma aplicação, uma autenticação interativa por meio de um login da aplicação da web deve ser realizada. Para encerrar uma sessão de usuário, uma operação de logout deve ser solicitada pelo usuário. Essas operações não utilizam a autenticação HTTP, mas sim uma autenticação personalizada gerenciada pela aplicação da web.

Mensagens de Solicitação HTTP/1.1

As mensagens de solicitação são enviadas por um cliente para um servidor de destino.

Sintaxe da Solicitação

Um cliente envia mensagens de solicitação ao servidor, que consistem em:

• Uma linha de solicitação, composta pelo método de solicitação sensível a maiúsculas, um espaço, a URL solicitada, outro espaço, a versão do protocolo, um retorno de carro e uma alimentação de linha. Exemplo:

  bashCopy code

  GET /images/logo.png HTTP/1.1

• Zero ou mais campos de cabeçalho de solicitação (pelo menos 1 ou mais cabeçalhos no caso do HTTP/1.1), cada um composto pelo nome do campo não sensível a maiúsculas, dois pontos, espaço em branco opcional, o valor do campo, espaço em branco opcional no início e terminando com um retorno de carro e uma alimentação de linha. Exemplo:

  makefileCopy code

  Host: www.example.com Accept-Language: en

• Uma linha em branco, composta por um retorno de carro e uma alimentação de linha.

• Um corpo de mensagem opcional.

No protocolo HTTP/1.1, todos os campos de cabeçalho, exceto Host: hostname, são opcionais. Uma linha de solicitação contendo apenas o nome do caminho é aceita pelos servidores para manter a compatibilidade com clientes HTTP antes da especificação HTTP/1.0 em RFC 1945.

Métodos de Solicitação

O HTTP define métodos (às vezes chamados de "verbos", embora a especificação não mencione "verbo") para indicar a ação desejada a ser executada no recurso identificado. O que esse recurso representa, se são dados preexistentes ou dados gerados dinamicamente, depende da implementação do servidor. A especificação HTTP/1.0 definiu os métodos GET, HEAD e POST, e a especificação HTTP/1.1 adicionou cinco novos métodos: PUT, DELETE, CONNECT, OPTIONS e TRACE. Qualquer cliente pode usar qualquer método, e o servidor pode ser configurado para oferecer suporte a qualquer combinação de métodos. Se um método for desconhecido para um intermediário, ele será tratado como um método não seguro e não idempotente. Não há limite para o número de métodos que podem ser definidos, permitindo a especificação de futuros métodos sem quebrar a infraestrutura existente. Por exemplo, o WebDAV definiu sete novos métodos e o RFC 5789 especificou o método PATCH.

Os nomes dos métodos são sensíveis a maiúsculas. Isso é diferente dos nomes dos campos de cabeçalho HTTP, que são insensíveis a maiúsculas.

• GET: O método GET solicita que o recurso de destino transfira uma representação de seu estado. Solicitações GET devem apenas recuperar dados e não devem ter outro efeito. Isso também é verdade para alguns outros métodos HTTP. Para recuperar recursos sem fazer alterações, o GET é preferido sobre o POST, pois eles podem ser acessados por meio de uma URL. Isso permite a criação de favoritos e o compartilhamento, e torna as respostas do GET elegíveis para o armazenamento em cache, economizando largura de banda. O W3C publicou princípios de orientação sobre essa distinção, dizendo: "O design de aplicações da web deve ser informado pelos princípios acima, mas também pelas limitações relevantes." Veja os métodos seguros abaixo.

• HEAD: O método HEAD solicita que o recurso de destino transfira uma representação de seu estado, como uma solicitação GET, mas sem os dados da representação no corpo da resposta. Isso é útil para recuperar os metadados da representação no cabeçalho da resposta, sem a necessidade de transferir a representação completa.

• POST: O método POST solicita que o recurso de destino processe a representação contida na solicitação, de acordo com a semântica do recurso de destino. Por exemplo, ele é usado para publicar uma mensagem em um fórum da internet, se inscrever em uma lista de discussão por email ou concluir uma transação de compra online.

• PUT: O método PUT solicita que o recurso de destino crie ou atualize seu estado com o estado definido pela representação contida na solicitação. A diferença em relação ao POST é que o cliente especifica a localização de destino no servidor.

• DELETE: O método DELETE solicita que o recurso de destino exclua seu estado.

• CONNECT: O método CONNECT solicita que o intermediário estabeleça um túnel TCP/IP para o servidor de origem identificado pelo destino da solicitação. Ele é frequentemente usado para criar conexões seguras por meio de um ou mais proxies HTTP com TLS. Veja o método CONNECT HTTP.

• OPTIONS: O método OPTIONS solicita que o recurso de destino transfira os métodos HTTP que ele suporta. Isso pode ser usado para verificar a funcionalidade de um servidor da web solicitando '*' em vez de um recurso específico.

• TRACE: O método TRACE solicita que o recurso de destino transfira a solicitação recebida no corpo da resposta. Dessa forma, um cliente pode ver quais mudanças ou adições (se houver) foram feitas por intermediários.

• PATCH: O método PATCH solicita que o recurso de destino modifique seu estado de acordo com a atualização parcial definida na representação contida na solicitação. Isso pode economizar largura de banda, atualizando parte de um arquivo ou documento sem transferi-lo inteiramente.

Todos os servidores web de propósito geral são obrigados a implementar pelo menos os métodos GET e HEAD, e todos os outros métodos são considerados opcionais pela especificação.

Métodos Seguros

Um método de solicitação é considerado seguro se uma solicitação com esse método não tiver um efeito intencional no servidor. Os métodos GET, HEAD, OPTIONS e TRACE são definidos como seguros. Em outras palavras, os métodos seguros destinam-se a ser somente leitura. No entanto, eles não excluem os efeitos colaterais, como anexar informações de solicitação a um arquivo de log ou cobrar uma conta publicitária, uma vez que não são solicitados pelo cliente, por definição.

Em contraste, os métodos POST, PUT, DELETE, CONNECT e PATCH não são seguros. Eles podem modificar o estado do servidor ou ter outros efeitos, como o envio de um email. Esses métodos geralmente não são usados por robôs ou rastreadores da web que seguem as regras, pois alguns deles podem não levar em consideração o contexto ou as consequências.

Apesar da prescrição da segurança das solicitações GET, na prática, seu tratamento pelo servidor não é tecnicamente limitado de forma alguma. Programação descuidada ou irregular pode permitir que as solicitações GET causem alterações significativas no servidor. Isso é desencorajado devido aos problemas que podem ocorrer quando o armazenamento em cache da web, mecanismos de pesquisa e outros agentes automatizados fazem alterações não intencionais no servidor. Por exemplo, um site pode permitir a exclusão de um recurso por meio de uma URL como "https://example.com/article/1234/delete", que, se obtido arbitrariamente, mesmo usando GET, simplesmente excluiria o artigo. Um site adequadamente codificado exigiria um método DELETE ou POST para essa ação, o que bots não maliciosos não fariam.

Um exemplo disso ocorreu na breve versão beta do Google Web Accelerator, que pré-carregava URLs arbitrárias na página que o usuário estava visualizando, causando registros serem alterados ou excluídos automaticamente em massa. O beta foi suspenso apenas algumas semanas após seu lançamento, após críticas generalizadas.

Métodos Idempotentes

Um método de solicitação é considerado idempotente se várias solicitações idênticas com esse método tiverem o mesmo efeito que uma única solicitação. Os métodos PUT e DELETE, bem como os métodos seguros, são definidos como idempotentes. Os métodos seguros são idempotentes de forma trivial, pois são destinados a não ter nenhum efeito no servidor, por definição. Os métodos PUT e DELETE, por outro lado, são idempotentes porque solicitações sucessivas idênticas serão ignoradas. Um site pode, por exemplo, configurar um ponto de extremidade PUT para modificar o endereço de email registrado de um usuário. Se esse ponto de extremidade estiver configurado corretamente, solicitações que solicitem alterar o endereço de email para o mesmo endereço de email já registrado - ou seja, solicitações duplicadas após uma solicitação bem-sucedida - não terão efeito. Da mesma forma, uma solicitação para DELETE de um determinado usuário não terá efeito se esse usuário já tiver sido excluído.

Em contraste, os métodos POST, CONNECT e PATCH não são necessariamente idempotentes, portanto, o envio de várias solicitações POST idênticas pode modificar ainda mais o estado do servidor ou ter mais efeitos, como o envio de vários emails. Em alguns casos, esse é o efeito desejado, mas em outros casos, pode ocorrer acidentalmente. Um usuário pode, por exemplo, inadvertidamente enviar várias solicitações POST clicando em um botão novamente se não receber um feedback claro de que o primeiro clique está sendo processado. Embora os navegadores da web possam exibir caixas de diálogo de alerta para avisar os usuários em alguns casos em que recarregar uma página pode reenviar uma solicitação POST, geralmente cabe à aplicação da web lidar com os casos em que uma solicitação POST não deve ser enviada mais de uma vez.

Observe que se um método é idempotente ou não não é imposto pelo protocolo ou servidor web. É perfeitamente possível escrever uma aplicação da web em que uma inserção de banco de dados ou outra ação não idempotente seja acionada por uma solicitação GET ou outra. No entanto, fazer isso contra as recomendações pode resultar em consequências indesejadas, se um agente de usuário presumir que repetir a mesma solicitação é seguro quando não é.

Métodos Cacheáveis

Um método de solicitação é considerado cacheável se as respostas a solicitações com esse método podem ser armazenadas para uso futuro. Os métodos GET, HEAD e POST são definidos como cacheáveis.

Em contraste, os métodos PUT, DELETE, CONNECT, OPTIONS, TRACE e PATCH não são cacheáveis.

Campos de Cabeçalho da Solicitação

Os campos de cabeçalho da solicitação permitem que o cliente transmita informações adicionais além da linha de solicitação, atuando como modificadores de solicitação (semelhantes aos parâmetros de um procedimento). Eles fornecem informações sobre o cliente, sobre o recurso de destino ou sobre o tratamento esperado da solicitação.

Mensagens de Resposta HTTP/1.1

Uma mensagem de resposta é enviada por um servidor a um cliente como resposta à sua solicitação anterior.

Sintaxe da Resposta

Um servidor envia mensagens de resposta ao cliente, que consistem em:

• Uma linha de status, que consiste na versão do protocolo, um espaço, o código de status da resposta, possivelmente uma frase de motivo vazia e uma quebra de linha e alimentação, por exemplo:

   

  HTTP/1.1 200 OK

• Zero ou mais campos de cabeçalho da resposta, cada um consistindo no nome do campo insensível a maiúsculas e minúsculas, dois pontos, espaço em branco opcional à esquerda, o valor do campo, espaço em branco opcional à direita e terminando com uma quebra de linha e alimentação, por exemplo:

   

  Content-Type: text/html

• Uma linha em branco, consistindo de uma quebra de linha e alimentação.

• Um corpo de mensagem opcional.

Códigos de Status da Resposta

Na HTTP/1.0 e depois, a primeira linha da resposta HTTP é chamada de linha de status e inclui um código de status numérico (como "404") e uma frase de motivo textual (como "Não encontrado"). O código de status da resposta é um código de três dígitos que representa o resultado da tentativa do servidor de entender e atender à solicitação correspondente do cliente. A forma como o cliente lida com a resposta depende principalmente do código de status e secundariamente dos outros campos de cabeçalho da resposta. Os clientes podem não entender todos os códigos de status registrados, mas devem entender sua classe (dada pelo primeiro dígito do código de status) e tratar um código de status não reconhecido como equivalente ao código de status x00 dessa classe.

As frases de motivo padrão são apenas recomendações e podem ser substituídas por "equivalentes locais" a critério do desenvolvedor web. Se o código de status indicar um problema, o agente do usuário poderá exibir a frase de motivo ao usuário para fornecer mais informações sobre a natureza do problema. O padrão também permite que o agente do usuário tente interpretar a frase de motivo, embora isso possa ser imprudente, uma vez que o padrão especifica explicitamente que os códigos de status são legíveis por máquina e as frases de motivo são legíveis por humanos.

O primeiro dígito do código de status define sua classe:

• 1XX (informativo): A solicitação foi recebida, continuando o processo.
• 2XX (bem-sucedido): A solicitação foi recebida, entendida e aceita com sucesso.
• 3XX (redirecionamento): Ação adicional precisa ser tomada para concluir a solicitação.
• 4XX (erro do cliente): A solicitação contém uma sintaxe ruim ou não pode ser atendida.
• 5XX (erro do servidor): O servidor falhou em atender a uma solicitação aparentemente válida.

Campos de Cabeçalho da Resposta

Os campos de cabeçalho da resposta permitem que o servidor transmita informações adicionais além da linha de status, atuando como modificadores de resposta. Eles fornecem informações sobre o servidor ou sobre um acesso adicional ao recurso de destino ou a recursos relacionados.

Cada campo de cabeçalho de resposta tem um significado definido que pode ser refinado ainda mais pelas semânticas do método de solicitação ou pelo código de status da resposta.

Exemplo de Transação de Solicitação/Resposta HTTP/1.1

A seguir, há um exemplo de transação HTTP entre um cliente HTTP/1.1 e um servidor HTTP/1.1 em execução em www.example.com, na porta 80.

Solicitação do Cliente

Uma solicitação do cliente (consistindo neste caso na linha de solicitação e em alguns cabeçalhos que podem ser reduzidos apenas ao cabeçalho "Host: hostname") é seguida por uma linha em branco, de modo que a solicitação termine com uma quebra de linha e alimentação dupla, cada uma na forma de um retorno de carro seguido de uma quebra de linha. O valor do cabeçalho "Host: hostname" distingue entre vários nomes DNS que compartilham um único endereço IP, permitindo o hospedamento virtual baseado em nome. Embora opcional no HTTP/1.0, ele é obrigatório no HTTP/1.1. (Uma barra (barra) geralmente buscará um arquivo /index.html, se houver um.)`

Resposta do Servidor

A resposta do servidor consiste na linha de status "HTTP/1.1 200 OK", que indica que a solicitação foi atendida com sucesso, seguida de campos de cabeçalho da resposta. A resposta termina com uma linha em branco e o corpo da resposta, que contém um documento HTML simples.

Observe que os campos de cabeçalho são insensíveis a maiúsculas e minúsculas e podem ser listados em qualquer ordem. Além disso, o servidor envia o cabeçalho "Connection: close" para indicar que a conexão será encerrada após esta resposta.

 

Conclusão

O HTTP é o protocolo subjacente que permite a comunicação na World Wide Web. Ele define como os clientes e servidores interagem para transferir informações e recursos pela Internet. O HTTP evoluiu ao longo do tempo, com versões mais recentes, como o HTTP/2 e o HTTP/3, trazendo melhorias significativas no desempenho e na eficiência. A segurança também é uma preocupação importante, e o uso do HTTPS (HTTP seguro) é agora amplamente adotado para proteger os dados transmitidos.

Além disso, conceitos como REST e WebSockets complementam o HTTP, permitindo que aplicativos web sejam mais interativos e eficientes. A compreensão dos princípios do HTTP e de suas várias versões é fundamental para qualquer pessoa que trabalhe com desenvolvimento web ou administração de servidores web. Esses conhecimentos são essenciais para criar sistemas web eficazes e seguros.