Protocolo de Transferência de Hipertexto - Hypertext Transfer Protocol

Protocolo de Transferência de Hipertexto
HTTP logo.svg
Padrão internacional RFC  1945 HTTP / 1.0 (1996)

RFC  2068 HTTP / 1.1 (1997)
RFC  2616 HTTP / 1.1 (1999)
RFC  7230 HTTP / 1.1: Message Syntax and Routing (2014)
RFC  7231 HTTP / 1.1: Semantics and Content (2014)
RFC  7232 HTTP / 1.1: Pedidos condicionais ( 2014)
RFC  7233 HTTP / 1.1: Solicitações de intervalo (2014)
RFC  7234 HTTP / 1.1: Cache (2014)
RFC  7235 HTTP / 1.1: Autenticação (2014)
RFC  7540 HTTP / 2 (2015)
RFC  7541 HTTP / 2: compactação de cabeçalho HPACK (2015)
RFC  8164 HTTP / 2: Opportunistic Security for HTTP / 2 (2017)
RFC  8336 HTTP / 2: The ORIGIN HTTP / 2 Frame (2018)
RFC  8441 HTTP / 2: Bootstrapping WebSockets com HTTP / 2 (2018)

RFC  8740 HTTP / 2: Usando TLS 1.3 com HTTP / 2 (2020)
Desenvolvido por inicialmente CERN ; IETF , W3C
Introduzido 1991 ; 30 anos atrás ( 1991 )

O Hypertext Transfer Protocol ( HTTP ) é um protocolo da camada de aplicação no modelo de suíte de protocolos da Internet para sistemas de informação hipermídia distribuídos e colaborativos . HTTP é a base da comunicação de dados para a World Wide Web , onde documentos de hipertexto incluem hiperlinks para outros recursos que o usuário pode acessar facilmente, por exemplo, por 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 que descreve o comportamento de um cliente e um servidor usando a primeira versão do protocolo HTTP que foi chamada de 0.9.

O desenvolvimento de solicitações HTTP iniciais para comentários (RFCs) começou alguns anos depois e foi um esforço coordenado pela Internet Engineering Task Force (IETF) e pelo World Wide Web Consortium (W3C), com o trabalho posteriormente sendo transferido para o IETF.

O HTTP / 1 foi documentado pela primeira vez (como versão 1.0) em 1996. Ele evoluiu (como versão 1.1) em 1997.

O HTTP / 2 é uma expressão mais eficiente da semântica do HTTP "on the wire", foi publicado em 2015 e é usado por 45% dos sites; agora é suportado por praticamente todos os navegadores da web e principais servidores da web em Transport Layer Security (TLS) usando uma extensão de Application-Layer Protocol Negotiation (ALPN) onde TLS 1.2 ou mais recente é necessário.

O HTTP / 3 é o sucessor proposto do HTTP / 2, e dois terços dos usuários de navegadores da web (tanto no desktop quanto no celular) já podem usar HTTP / 3, em 20% dos sites que já o suportam; ele usa QUIC em vez de TCP para o protocolo de transporte subjacente. Como o HTTP / 2, ele não torna obsoletas as principais versões anteriores do protocolo. Suporte para HTTP / 3 foi adicionado ao Cloudflare e Google Chrome primeiro, e também está habilitado no Firefox .

Visão geral técnica

URL começando com o esquema HTTP e o rótulo do nome de domínio WWW

O HTTP funciona como um protocolo de solicitação-resposta no modelo de computação cliente-servidor. Um navegador da web , por exemplo, pode ser o cliente e um aplicativo em execução em um computador que hospeda um site pode ser o servidor . O cliente envia uma mensagem de solicitação HTTP ao 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 ao cliente. A resposta contém informações de status de conclusão sobre a solicitação e também pode conter o conteúdo solicitado no corpo da mensagem.

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

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

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

HTTP é um protocolo de camada de aplicativo projetado dentro da estrutura do pacote de protocolos da Internet . Sua definição pressupõe um protocolo de camada de transporte confiável e subjacente , portanto, o protocolo de controle de transmissão (TCP) é comumente usado. No entanto, o HTTP pode ser adaptado para usar protocolos não confiáveis, como o User Datagram Protocol (UDP), por exemplo, em HTTPU e Simple Service Discovery Protocol (SSDP).

Os recursos HTTP são identificados e localizados na rede por Uniform Resource Locators (URLs), usando os esquemas de Uniform Resource Identifiers (URIs) http e https . Conforme definido na RFC  3986 , os URIs são codificados como hiperlinks em documentos HTML , de modo a formar documentos de hipertexto interligados .

HTTP / 1.1 é uma revisão do HTTP original (HTTP / 1.0). Em HTTP / 1.0, uma conexão separada com o mesmo servidor é feita para cada solicitação de recurso. Em vez disso, o HTTP / 1.1 pode reutilizar uma conexão para fazer várias solicitações de recursos (ou seja, de páginas HTML, frames, imagens, scripts , folhas de estilo , etc.).

As comunicações HTTP / 1.1, portanto, sofrem menos latência, pois o estabelecimento de conexões TCP apresenta uma sobrecarga considerável, especialmente em condições de alto tráfego.

HTTP / 2 é uma revisão do HTTP / 1.1 anterior para manter o mesmo modelo cliente-servidor e os mesmos métodos de protocolo, mas com estas diferenças na ordem:

  • usar uma representação binária compactada de metadados (cabeçalhos HTTP) em vez de textual, de modo que os cabeçalhos exijam muito menos espaço;
  • usar uma única conexão TCP / IP (geralmente criptografada ) por domínio de servidor acessado em vez de 2..8 conexões TCP / IP;
  • para usar um ou mais fluxos bidirecionais por conexão TCP / IP em que as solicitações e respostas HTTP são divididas e transmitidas em pequenos pacotes para resolver o problema do HOLB ( bloqueio de cabeçalho de linha ; NOTA: na prática, esses fluxos são usados ​​como TCP múltiplo / Subconexões IP para multiplexar solicitações / respostas simultâneas, reduzindo assim enormemente o número de conexões TCP / IP reais no lado do servidor, de 2..8 por cliente para 1, e permitindo que muitos mais clientes sejam atendidos de uma vez);
  • para adicionar um recurso push para permitir que o aplicativo do servidor envie dados aos clientes sempre que novos dados estiverem disponíveis (sem forçar os clientes a solicitar periodicamente novos dados ao servidor usando métodos de pesquisa ).

Portanto, as comunicações HTTP / 2 apresentam muito menos latência e, na maioria dos casos, ainda mais velocidade do que as comunicações HTTP / 1.1.

HTTP / 3 é uma revisão do HTTP / 2 anterior a fim de usar protocolos de transporte UDP + QUIC em vez de conexões TCP / IP e assim superar o problema de congestionamento de conexão TCP / IP que pode bloquear ou retardar o fluxo de dados de todos os seus córregos.

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 do sistema " memex " de gerenciamento e recuperação de informação baseado em microfilme descrito em seu ensaio de 1945 " As We May Think " Tim Berners-Lee e sua equipe no CERN são creditados com a invenção do HTTP original, junto com HTML e a tecnologia associada para um servidor da web e um navegador da web baseado em texto. Berners-Lee propôs pela primeira vez o projeto "WorldWideWeb" em 1989 - agora conhecido como World Wide Web . O primeiro servidor web entrou no ar em 1990. O protocolo usado tinha apenas um método, o GET, que solicitava uma página de um servidor. A resposta do servidor sempre foi uma página HTML.

A primeira versão documentada do HTTP foi escrita em 1991. Dave Raggett liderou o HTTP Working Group (HTTP WG) em 1995 e queria expandir o protocolo com operações estendidas, negociação estendida, meta-informações mais ricas, vinculadas a um protocolo de segurança que se tornou mais eficiente, adicionando métodos adicionais e campos de cabeçalho . A RFC  1945 introduziu e reconheceu oficialmente o HTTP versão 1.0 em 1996.

O HTTP WG planejava publicar novos padrões em dezembro de 1995 e o suporte para HTTP / 1.1 pré-padrão baseado no então desenvolvimento RFC  2068 (chamado HTTP-NG) foi rapidamente adotado pelos principais desenvolvedores de navegadores no início de 1996. Adoção do usuário final dos novos navegadores foi rápido. Em março de 1996, uma empresa de hospedagem na web relatou que mais de 40% dos navegadores em uso na Internet eram compatíveis com HTTP 1.1. Essa mesma empresa de hospedagem na web relatou que, em junho de 1996, 65% de todos os navegadores que acessavam seus servidores eram compatíveis com HTTP / 1.1. O padrão HTTP / 1.1 conforme definido no RFC  2068 foi lançado oficialmente em janeiro de 1997. Melhorias e atualizações no padrão HTTP / 1.1 foram lançadas sob o RFC  2616 em junho de 1999.

Em 2007, o Grupo de Trabalho HTTP foi formado, em parte, para revisar e esclarecer a especificação HTTP / 1.1.

Em junho de 2014, o WG lançou uma especificação atualizada de seis partes, tornando obsoleta a RFC  2616 :

  • RFC  7230 , HTTP / 1.1: Sintaxe de mensagens e roteamento
  • RFC  7231 , HTTP / 1.1: Semântica e conteúdo
  • RFC  7232 , HTTP / 1.1: solicitações condicionais
  • RFC  7233 , HTTP / 1.1: Solicitações de intervalo
  • RFC  7234 , HTTP / 1.1: Cache
  • RFC  7235 , HTTP / 1.1: autenticação

Em maio de 2015, o HTTP / 2 foi publicado como RFC  7540 .

Desde 2016, muitos gerentes de produto e desenvolvedores de agentes de usuário (navegadores, etc.) e servidores da web começaram a planejar a descontinuação gradual e dispensar o suporte para protocolo HTTP / 0.9 , principalmente pelos seguintes motivos:

  • é claramente obsoleto porque é tão simples que ninguém se preocupou em escrever um documento RFC (existe apenas o documento original);
  • não tem cabeçalhos HTTP e também carece de muitos outros recursos que hoje em dia são realmente necessários por razões mínimas de segurança;
  • não tem sido realmente usado desde 1999..2000 (por causa do HTTP / 1.0 e HTTP / 1.1);
  • parece que ele é usado aleatoriamente apenas por alguns hardwares de rede muito antigos, ou seja , roteadores , etc.

Em 2021, o suporte HTTP / 0.9 ainda está presente em muitos servidores web e navegadores (apenas para respostas do servidor), então não está claro quanto tempo levará essa desativação, talvez ela seja primeiro concluída em agentes de usuário (navegadores, etc.) e, em seguida, em servidores da web.

Ano Versão
1991 HTTP / 0.9
1996 HTTP / 1.0
1997 HTTP / 1.1
2015 HTTP / 2
2020 (rascunho) HTTP / 3

Sessão HTTP

Uma sessão HTTP é uma sequência de transações de solicitação-resposta de rede. Um cliente HTTP inicia uma solicitação estabelecendo uma conexão de Protocolo de Controle de Transmissão (TCP) a uma porta específica em um servidor (normalmente porta 80, ocasionalmente porta 8080; consulte Lista de números de porta TCP e UDP ). Um servidor HTTP escutando nessa porta espera por uma mensagem de solicitação do cliente. Ao receber a solicitação, o servidor envia de volta uma linha de status, como " HTTP / 1.1 200 OK ", e uma mensagem própria. O corpo desta mensagem é normalmente o recurso solicitado, embora uma mensagem de erro ou outras informações também possam ser retornadas.

Conexões persistentes

Em HTTP / 0.9 do TCP / IP conexão está sempre fechada após resposta do servidor foi enviado.

Em HTTP / 1.0, como indicado na RFC 1945, o TCP / IP de conexão deve ser sempre fechada pelo servidor depois de uma resposta foi enviada. NOTA: desde o final de 1996, alguns desenvolvedores de navegadores e servidores HTTP / 1.0 populares (especialmente aqueles que planejaram suporte para HTTP / 1.1 também), começaram a implantar (como uma extensão não oficial) uma espécie de mecanismo keep-alive (usando novos cabeçalhos HTTP) para manter a conexão TCP / IP aberta para mais do que um par de solicitação / resposta e, assim, acelerar a troca de várias solicitações / respostas.

No HTTP / 1.1, um mecanismo keep-alive foi introduzido oficialmente para que uma conexão pudesse ser reutilizada para mais de uma solicitação / resposta. Essas conexões persistentes reduzem a latência da solicitação de forma perceptível, porque o cliente não precisa renegociar a conexão TCP 3-Way-Handshake depois que a primeira solicitação foi 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 .

O HTTP / 1.1 também adicionou o pipelining HTTP para reduzir ainda mais o tempo de atraso ao usar conexões persistentes, permitindo que os clientes enviem várias solicitações antes de aguardar 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 corretamente (eles atendiam apenas a primeira solicitação descartando as outras ou fechavam a conexão porque eles viram mais dados após a primeira solicitação, etc.). Além disso, apenas as solicitações GET e HEAD podem ser canalizadas de modo seguro e idempotente. Depois de muitos anos lutando com os problemas introduzidos pela ativação do pipelining, esse recurso foi primeiro desativado e, em seguida, removido da maioria dos navegadores também devido à adoção anunciada do HTTP / 2.

O HTTP / 2 estendeu o uso de conexões persistentes ao multiplexar muitas solicitações / respostas simultâneas por meio de uma única conexão TCP / IP.

HTTP / 3 não usa conexões TCP / IP, mas UDP + QUIC para evitar o problema de congestionamento TCP / IP de uma conexão.

Otimizações de recuperação de conteúdo

Em HTTP / 0.9, um recurso solicitado sempre foi enviado por completo.

HTTP / 1.0 adicionou cabeçalhos para gerenciar recursos armazenados em cache pelo cliente a fim de permitir solicitações GET condicionais ; na prática, um servidor deve retornar todo o conteúdo do recurso solicitado apenas se a hora da última modificação não for conhecida pelo cliente ou se ele mudou desde a última resposta completa à solicitação GET.

HTTP / 1.0 adicionou o cabeçalho "Content-Encoding" para especificar se o conteúdo retornado de um recurso foi ou não compactado .

Em HTTP / 1.0, se o comprimento total do conteúdo de um recurso não era conhecido com antecedência (ou seja, porque foi gerado dinamicamente, etc.), o cabeçalho "Content-Length: number"não estava presente nos cabeçalhos HTTP e o cliente presumiu que, quando o servidor fechou a conexão , o conteúdo foi enviado na íntegra. Este mecanismo não conseguiu distinguir entre uma transferência de recurso concluída com êxito e uma interrompida (devido a um erro de servidor / rede ou outra coisa).

HTTP / 1.1 adicionou novos cabeçalhos para gerenciar melhor a recuperação condicional de recursos armazenados em cache.

O HTTP / 1.1 introduziu a codificação de transferência em partes para permitir que o conteúdo seja transmitido em partes para enviá-lo de forma confiável, mesmo quando o servidor não sabe com antecedência seu comprimento (ou seja, porque é gerado dinamicamente, etc.).

HTTP / 1.1 também adicionou o serviço de intervalo de bytes , em que um cliente pode solicitar apenas uma ou mais partes (intervalos de bytes) de um recurso (ou seja, a primeira parte, uma parte no meio ou no final de todo o conteúdo, etc.) e o servidor geralmente envia apenas a (s) parte (s) solicitada (s). Isso é útil para retomar um download interrompido (quando um arquivo é realmente grande), quando apenas uma parte de um conteúdo precisa ser mostrada ou adicionada dinamicamente à parte já visível por um navegador (ou seja, apenas o primeiro ou os n comentários seguintes de uma página da web) para poupar tempo, largura de banda e recursos do sistema, etc.

HTTP / 2 e HTTP / 3 mantiveram os recursos mencionados acima do HTTP / 1.1.

Estado da sessão HTTP

HTTP é um protocolo sem estado . Um protocolo sem estado não requer que o servidor HTTP retenha informações ou status sobre cada usuário durante várias solicitações. No entanto, alguns aplicativos da web implementam estados ou sessões do lado do servidor usando, por exemplo, cookies HTTP ou variáveis ocultas em formulários da web .

Autenticação HTTP

O HTTP fornece vários esquemas de autenticação, como autenticação de acesso básico e autenticação de acesso condensado, que operam por meio de um mecanismo de desafio-resposta, por meio do qual o servidor identifica e emite um desafio antes de servir o conteúdo solicitado.

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

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 a um determinado URI raiz . A string de valor de domínio, se presente, é combinada com o URI raiz canônico para formar o componente do espaço de proteção do desafio. Na verdade, isso permite que o servidor defina escopos de autenticação separados em um URI raiz.

Solicitar mensagens

Solicitar sintaxe

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

  • uma linha de solicitação, consistindo no método de solicitação que diferencia maiúsculas de minúsculas, um espaço , o destino da solicitação, outro espaço, a versão do protocolo, um retorno de carro e uma alimentação de linha , por exemplo:
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 de HTTP / 1.1), cada um consistindo no nome do campo que não diferencia maiúsculas de minúsculas, dois pontos, espaço em branco opcional , o valor do campo, um espaço em branco final opcional e terminando com um retorno de carro e alimentação de linha, por exemplo:
Host: www.example.com
Accept-Language: en
  • uma linha vazia, consistindo em 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: hostnamesã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

Uma solicitação HTTP / 1.1 feita usando telnet. O pedido mensagem, resposta seção de cabeçalho e corpo da resposta são realçados.

HTTP define métodos (às vezes chamados de verbos , mas em nenhum lugar da especificação menciona verbo , nem OPTIONS ou HEAD é um verbo) para indicar a ação desejada a ser executada no recurso identificado. O que esse recurso representa, sejam dados pré-existentes ou dados gerados dinamicamente, depende da implementação do servidor. Freqüentemente, o recurso corresponde a um arquivo ou a saída de um executável residente no 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. Por ser especificada nesses documentos, sua semântica é bem conhecida e pode ser confiável. Qualquer cliente pode usar qualquer método e o servidor pode ser configurado para suportar qualquer combinação de métodos. Se um método for desconhecido para um intermediário, ele será tratado como um método inseguro e não idempotente . Não há limite para o número de métodos que podem ser definidos e isso permite que métodos futuros sejam especificados sem quebrar a infraestrutura existente. Por exemplo, o WebDAV definiu sete novos métodos e a RFC  5789 especificou o método PATCH .

Os nomes dos métodos diferenciam maiúsculas de minúsculas. Isso contrasta com os nomes dos campos de cabeçalho HTTP, que não diferenciam maiúsculas de minúsculas.

PEGUE
O método GET solicita que o recurso de destino transfira uma representação de seu estado. As solicitações GET devem apenas recuperar dados e não devem ter nenhum outro efeito. (Isso também é verdadeiro para alguns outros métodos HTTP.) O W3C publicou princípios de orientação sobre essa distinção, dizendo: " O design de aplicativos da Web deve ser informado pelos princípios acima, mas também pelas limitações relevantes." Veja os métodos de segurança abaixo.
CABEÇA
O método HEAD solicita que o recurso de destino transfira uma representação de seu estado, como para uma solicitação GET, mas sem os dados de representação incluídos no corpo da resposta. Isso é útil para recuperar os metadados de representação no cabeçalho da resposta, sem ter que transferir toda a representação.
PUBLICAR
O método POST solicita que o recurso de destino processe a representação incluída na solicitação de acordo com a semântica do recurso de destino. Por exemplo, é usado para postar uma mensagem em um fórum da Internet , inscrever-se em uma lista de mala direta ou concluir uma transação de compra online .
POR
O método PUT solicita que o recurso de destino crie ou atualize seu estado com o estado definido pela representação incluída na solicitação.
EXCLUIR
O método DELETE solicita que o recurso de destino exclua seu estado.
CONECTAR
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. Geralmente é usado para proteger conexões por meio de um ou mais proxies HTTP com TLS . Consulte o método HTTP CONNECT .
OPÇÕES
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.
VESTÍGIO
O método TRACE solicita que o recurso de destino transfira a solicitação recebida no corpo da resposta. Dessa forma, o cliente pode ver quais alterações ou acréscimos foram feitos (se houver) pelos intermediários.
CORREÇÃO
O método PATCH solicita que o recurso de destino modifique seu estado de acordo com a atualização parcial definida na representação incluída na solicitação.

Todos os servidores HTTP de uso geral são necessários para implementar pelo menos os métodos GET e HEAD, e todos os outros métodos são considerados opcionais pela especificação.

Propriedades dos métodos de solicitação
Método de solicitação RFC A solicitação tem corpo de carga útil A resposta tem corpo de carga útil Seguro Idempotente Cacheable
PEGUE RFC  7231 Opcional sim sim sim sim
CABEÇA RFC  7231 Opcional Não sim sim sim
PUBLICAR RFC  7231 sim sim Não Não sim
POR RFC  7231 sim sim Não sim Não
EXCLUIR RFC  7231 Opcional sim Não sim Não
CONECTAR RFC  7231 Opcional sim Não Não Não
OPÇÕES RFC  7231 Opcional sim sim sim Não
VESTÍGIO RFC  7231 Não sim sim sim Não
CORREÇÃO RFC  5789 sim sim Não Não Não

Métodos seguros

Um método de solicitação é seguro se uma solicitação com esse método não tiver efeito pretendido no servidor. Os métodos GET, HEAD, OPTIONS e TRACE são definidos como seguros. Em outras palavras, os métodos seguros devem ser somente leitura . Eles não excluem efeitos colaterais , como anexar informações de solicitação a um arquivo de log ou cobrar uma conta de publicidade , 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 e - mail . Portanto, esses métodos geralmente não são usados ​​por robôs da web ou rastreadores da web em conformidade ; alguns que não estão em conformidade tendem a fazer solicitações sem levar em conta o contexto ou as consequências.

Apesar da segurança prescrita das solicitações GET , na prática, seu tratamento pelo servidor não é tecnicamente limitado de forma alguma. Portanto, a programação descuidada ou deliberada pode causar alterações não triviais no servidor. Isso é desencorajado, porque pode causar problemas para o cache da web , mecanismos de pesquisa e outros agentes automatizados, que podem fazer 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 buscada arbitrariamente, mesmo usando GET , simplesmente excluiria o artigo.

Um exemplo disso ocorrendo na prática foi durante o breve Google Web Accelerator beta , que pré-buscou URLs arbitrários na página que um usuário estava visualizando, fazendo com que os registros fossem automaticamente alterados ou excluídos em massa . O beta foi suspenso apenas algumas semanas após seu primeiro lançamento, após críticas generalizadas.

Métodos idempotentes

Um método de solicitação é idempotente se várias solicitações idênticas àquele método têm o mesmo efeito pretendido de uma única solicitação. Os métodos PUT e DELETE e os métodos seguros são definidos como idempotentes.

Em contraste, os métodos POST, CONNECT e PATCH não são necessariamente idempotentes e, portanto, enviar uma solicitação POST idêntica várias vezes pode modificar ainda mais o estado do servidor ou ter outros efeitos, como enviar um e - mail . Em alguns casos, isso pode ser desejável, mas em outros casos, pode ser devido a um acidente, como quando um usuário não percebe que sua ação resultará no envio de outra solicitação ou não recebeu um feedback adequado de que sua primeira solicitação foi bem-sucedido. Embora os navegadores da web possam mostrar 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 ao aplicativo da web lidar com os casos em que uma solicitação POST não deve ser enviada mais de uma vez.

Observe que o fato de um método ser idempotente não é imposto pelo protocolo ou servidor da web. É perfeitamente possível escrever uma aplicação web na qual (por exemplo) uma inserção de banco de dados ou outra ação não idempotente é disparada por um GET ou outra solicitação. Ignorar essa recomendação, no entanto, pode resultar em consequências indesejáveis, se um agente do usuário assumir que repetir a mesma solicitação é seguro, quando não é.

Métodos armazenáveis ​​em cache

Um método de solicitação pode ser armazenado em cache se as respostas às solicitações com esse método puderem ser armazenadas para reutilização futura. Os métodos GET, HEAD e POST são definidos como armazenáveis ​​em cache.

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

Solicitar campos de cabeçalho

Os campos de cabeçalho de solicitação permitem que o cliente passe informações adicionais além da linha de solicitação, agindo como modificadores de solicitação (de forma semelhante 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

Sintaxe de resposta

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

HTTP/1.1 200 OK
  • zero ou mais campos de cabeçalho de resposta , cada um consistindo no nome do campo que não diferencia maiúsculas de minúsculas, dois pontos, espaço em branco inicial opcional , o valor do campo, um espaço em branco opcional final e terminando com um retorno de carro e uma alimentação de linha, por exemplo:
Content-Type: text/html
  • uma linha vazia, consistindo em um retorno de carro e uma alimentação de linha;
  • um corpo de mensagem opcional .

Códigos de status de resposta

Em HTTP / 1.0 e desde então, 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 razão textual (como "Não encontrado"). O código de status de resposta é um código inteiro de três dígitos que representa o resultado da tentativa do servidor de entender e satisfazer a solicitação correspondente do cliente. A maneira como o cliente lida com a resposta depende principalmente do código de status e, secundariamente, dos outros campos de cabeçalho de resposta. Os clientes podem não compreender todos os códigos de status registrados, mas devem compreender 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 razão padrão são apenas recomendações e podem ser substituídas por "equivalentes locais" a critério do desenvolvedor da web . Se o código de status indicou um problema, o agente do usuário pode exibir a frase de razão 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 razão , 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 razão 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, compreendida e aceita com sucesso.
3XX (redirecionamento)
É necessário realizar outras ações para concluir a solicitação.
4XX (erro do cliente)
A solicitação contém sintaxe incorreta ou não pode ser atendida.
5XX (erro de servidor)
O servidor falhou em atender a uma solicitação aparentemente válida.

Campos de cabeçalho de resposta

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

Cada campo de cabeçalho de resposta tem um significado definido que pode ser posteriormente refinado pela semântica do método de solicitação ou código de status de resposta.

Conexões criptografadas

A forma mais popular de estabelecer uma conexão HTTP criptografada é HTTPS . Também existem dois outros métodos para estabelecer uma conexão HTTP criptografada: Secure Hypertext Transfer Protocol e usar o cabeçalho HTTP / 1.1 Upgrade para especificar uma atualização para TLS. O suporte do navegador para esses dois, no entanto, é quase inexistente.

Sessão de exemplo

Abaixo está um exemplo de conversa entre um cliente HTTP e um servidor HTTP em execução em www.example.com , porta 80.

Pedido do cliente

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

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

Resposta do servidor

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

O campo de cabeçalho ETag (tag de entidade) é usado para determinar se uma versão em cache do recurso solicitado é idêntica à versão atual do recurso no servidor. "Content-Type"especifica o tipo de mídia da Internet dos dados transmitidos pela mensagem HTTP, enquanto "Content-Length"indica seu comprimento em bytes. O servidor da web HTTP / 1.1 publica sua capacidade de responder às solicitações de certos intervalos de bytes do documento, definindo o campo "Accept-Ranges: bytes". Isso é útil se o cliente precisa ter apenas certas partes de um recurso enviado pelo servidor, o que é chamado de serviço de bytes . Quando "Connection: close"for enviado, significa que o servidor web fechará a conexão TCP imediatamente após o término da transferência desta resposta.

A maioria das linhas de cabeçalho é opcional, mas algumas são obrigatórias. Quando o cabeçalho "Content-Length: number"está faltando em uma resposta com um corpo de entidade, isso deve ser considerado um erro em HTTP / 1.0, mas pode não ser um erro em HTTP / 1.1 se o cabeçalho "Transfer-Encoding: chunked"estiver presente. A codificação de transferência em partes usa um tamanho de bloco de 0 para marcar o final do conteúdo. Algumas implementações antigas de HTTP / 1.0 omitiam o cabeçalho "Content-Length"quando o comprimento da entidade do corpo não era conhecido no início da resposta e, portanto, a transferência de dados para o cliente continuou até que o servidor fechasse o soquete.

Um pode ser usado para informar ao cliente que a parte da entidade do corpo dos dados transmitidos está compactada pelo algoritmo gzip. "Content-Encoding: gzip"

Protocolos semelhantes

  • O protocolo Gopher é um protocolo de entrega de conteúdo que foi substituído pelo HTTP no início dos anos 1990.
  • O protocolo SPDY é uma alternativa ao HTTP desenvolvido no Google , substituído pelo HTTP / 2 .
  • O protocolo Gemini é um protocolo inspirado no Gopher que exige recursos relacionados à privacidade.

Veja também

Referências


links externos