Protocolo de Transferência de Hipertexto

Protocolo de Transferência de Hipertexto
Família	família de protocolos de internet
Função	transferência de hipertexto
Última versão	3.0 (2018)
portas	80/TCP
Localização na pilha de protocolos
Aplicativo HTTP Transporte TCP Internet IP
padrões
Original HTTP (HTTP/0.9, 1991 ) RFC 1945 (HTTP/1.0, 1996 ) RFC 2616 (HTTP/1.1, 1999 ) RFC 2774 ( HTTP/1.2 , 2000 ) RFC 7230 , RFC 7231 , RFC 7232 , RFC 7233 , RFC 7234 , RFC 7235 (revisão de HTTP/1.1, 2014 ) RFC 7540 ( HTTP/2 , 2015 ) Hypertext Transfer Protocol Versão 3 ( HTTP/3 , 2018 ) ( Internet Draft )

O Hypertext Transfer Protocol (em inglês , Hypertext Transfer Protocol , abreviado como HTTP ) é o protocolo de comunicação que permite a transferência de informações através de arquivos (XML, HTML ...) na World Wide Web . Foi desenvolvido pelo World Wide Web Consortium e pela Internet Engineering Task Force , uma colaboração que culminou na publicação de uma série de RFCs em 1999 , sendo a mais importante a RFC 2616 que especificava a versão 1.1. HTTP define a sintaxe e a semântica usada pelos elementos de software da arquitetura web (clientes, servidores, proxies ) para se comunicar.

O HTTP é um protocolo sem estado , portanto, não salva nenhuma informação sobre conexões anteriores. O desenvolvimento de aplicativos da Web frequentemente precisa manter o estado. Para isso são utilizados cookies , que são informações que um servidor pode armazenar no sistema cliente . Isso permite que os aplicativos da web instituam a noção de uma sessão e também permite que os usuários sejam rastreados, pois os cookies podem ser armazenados no cliente indefinidamente.

Descrição

É um protocolo orientado a transações e segue o esquema de solicitação-resposta entre um cliente e um servidor. O cliente (muitas vezes chamado de " user agent " ) faz uma solicitação enviando uma mensagem, em um determinado formato, ao servidor. O servidor (comumente chamado de servidor web) envia uma mensagem de resposta. Exemplos de clientes são navegadores da web e web spiders (também conhecidos pelo termo em inglês, webcrawlers ).

Mensagens

As mensagens HTTP estão em texto simples , o que as torna mais legíveis e fáceis de depurar. No entanto, isso tem a desvantagem de tornar as mensagens mais longas. As mensagens têm a seguinte estrutura:

• Linha inicial (termina com retorno de carro e avanço de linha) com
  • Para solicitações: a ação exigida pelo servidor ( método de solicitação ) seguida da URL do recurso e da versão HTTP suportada pelo cliente.
  • Para respostas: A versão do HTTP utilizada seguida do código de resposta (que indica o que aconteceu com o pedido seguido da URL do recurso) e a frase associada ao referido retorno.
• Cabeçalhos de mensagens que terminam com uma linha em branco. São metadados . Esses cabeçalhos dão ao protocolo grande flexibilidade.
• Corpo da mensagem. É opcional. Sua presença depende da linha anterior da mensagem e do tipo de recurso ao qual a URL se refere. Normalmente tem os dados que são trocados entre cliente e servidor. Por exemplo, para uma solicitação, ela pode conter determinados dados que você deseja enviar ao servidor para processamento. Para uma resposta, você pode incluir os dados que o cliente solicitou.

Métodos de solicitação

Uma solicitação HTTP usando telnet . A solicitação , os cabeçalhos de resposta e o corpo da resposta são destacados.

O HTTP define um conjunto predefinido de métodos de solicitação (às vezes chamados de "verbos") que podem ser usados. O protocolo tem a flexibilidade de adicionar novos métodos e assim adicionar novas funcionalidades. O número de métodos de solicitação foi aumentando à medida que as versões progrediam. Esta lista inclui os métodos adicionados pelo WebDAV .

Cada método indica a ação que você deseja que seja executada no recurso identificado. O que esse recurso representa depende do aplicativo do servidor. Por exemplo, o recurso pode corresponder a um arquivo que reside no servidor.

OBTER

O método GET solicita uma representação do recurso especificado. As solicitações que usam GET devem apenas recuperar dados e não devem ter nenhum outro efeito. (Isso também é verdade para alguns outros métodos HTTP.)

CABEÇA

RFC 2616 . Ele solicita uma resposta idêntica àquela que corresponderia a uma solicitação GET, mas o corpo não é retornado na resposta. Isso é útil para poder recuperar os metadados dos cabeçalhos de resposta, sem ter que carregar todo o conteúdo.

POSTAR

RFC 2616 . Envia dados para serem processados ​​pelo recurso identificado na URL da linha de requisição. Os dados serão incluídos no corpo da solicitação. No nível semântico, visa criar um novo recurso, cuja natureza será especificada pelo cabeçalho Content-Type . Exemplos:

• Para dados de formulário codificados como um URL (embora trafegue no corpo da solicitação, não no URL): application/x-www-form-urlencoded
• Para blocos para subir, por exemplo. arquivos: multipart/form-data
• Além do acima, não há padrão obrigatório e também podem ser outros como text/plain , application/json , application/octet-stream ,...

COLOCAR

( RFC 2616 ) Envia dados para o servidor, mas ao contrário do método POST, o URI da linha de requisição não se refere ao recurso que irá processá-lo, mas sim identifica os dados em si (veja explicação detalhada na RFC ). Outra diferença com POST é a semântica (veja REST ): enquanto POST é orientado para a criação de novo conteúdo, PUT é mais orientado para atualizá-lo (embora também possa criá-lo).

Exemplo:

PUT /path/filename.html HTTP/1.1

APAGAR

RFC 2616 . Exclui o recurso especificado.

TRAÇO

( RFC 2616 ) Este método solicita que o servidor insira na resposta todos os dados que receber na mensagem de solicitação. Ele é usado para fins de depuração e diagnóstico, pois o cliente pode ver o que chega ao servidor e, dessa forma, ver tudo o que os servidores intermediários adicionam à mensagem.

OPÇÕES

RFC 2616 . Retorna os métodos HTTP aos quais o servidor dá suporte para uma URL específica. Isso pode ser usado para verificar a funcionalidade de um servidor web por solicitação em vez de um recurso específico.

CONECTAR

RFC 2616 . É usado para saber se você tem acesso a um host, não necessariamente a solicitação chega ao servidor, esse método é usado principalmente para saber se um proxy nos dá acesso a um host em condições especiais, como "streams" bidirecionais de dados criptografados. (conforme exigido pelo SSL).

PATCH

( RFC 5789 ). Sua função é a mesma de PUT, que substitui completamente um recurso. É usado para atualizar parcialmente uma ou mais partes. Também é orientado para uso com proxy . ]

MOVER

RFC 2518

MKCOL

RFC 2518

PROPFIND

RFC 2518

PROPAGANDA

RFC 2518

MERGE

RFC 3253

ATUALIZAÇÃO

RFC 3253

ETIQUETA

RFC 3253

Códigos de resposta

A resposta ou código de retorno é um número que indica o que aconteceu com a solicitação. O restante do conteúdo da resposta dependerá do valor desse código. O sistema é flexível e de facto a lista de códigos tem vindo a aumentar para se adaptar às mudanças e identificar novas situações. Cada código tem um significado específico. No entanto, o número de códigos é escolhido de tal forma que, dependendo se pertence a uma centena ou a outra, o tipo de resposta dada pelo servidor pode ser identificado:

• Códigos de formato 1xx: respostas informativas. Indica que a solicitação foi recebida e está sendo processada.
• Códigos com formato 2xx: Respostas corretas. Indica que a solicitação foi processada corretamente.
• Códigos com formato 3xx: Redirecionar respostas. Indica que o cliente precisa tomar outras medidas para concluir a solicitação.
• Códigos com formato 4xx: Erros causados ​​pelo cliente. Indica que houve um erro ao processar a solicitação porque o cliente fez algo errado.
• Códigos de formato 5xx: Erros causados ​​pelo servidor. Indica que houve um erro ao processar a solicitação devido a uma falha do servidor.

Cabeçalhos

São os metadados que são enviados em solicitações ou respostas HTTP para fornecer informações essenciais sobre a transação atual. Cada cabeçalho é especificado por um nome de cabeçalho seguido por dois pontos, um espaço em branco e o valor desse cabeçalho seguido por um retorno de carro seguido por um avanço de linha. Uma linha em branco é usada para indicar o fim dos cabeçalhos. Se não houver cabeçalhos, a linha em branco deve permanecer.

Os cabeçalhos dão grande flexibilidade ao protocolo permitindo adicionar novas funcionalidades sem ter que mudar a base. É por isso que, à medida que as versões do HTTP foram acontecendo, mais e mais cabeçalhos permitidos foram adicionados.

Os cabeçalhos podem conter metadados que devem ser processados ​​pelo cliente (p. intermediários (por exemplo, como gerenciar o cache por proxies )

Dependendo do tipo de mensagem em que um cabeçalho pode ir, podemos classificá-los em cabeçalhos de solicitação, cabeçalhos de resposta e cabeçalhos que podem ir tanto em uma solicitação quanto em uma resposta.

Podemos classificar os cabeçalhos de acordo com sua função. Por exemplo:

• Cabeçalhos que indicam as capacidades aceitas pelo remetente da mensagem: Accept (indica o MIME aceito ), Accept-Charset (indica o código de caractere aceito), Accept-Encoding (indica o método de compactação aceito), Accept-Language (indica o idioma), User-Agent (para descrever o cliente), Server (indica o tipo de servidor), Allow (métodos permitidos para o recurso)
• Cabeçalhos que descrevem o conteúdo: Content-Type (indica o MIME do conteúdo), Content-Length (comprimento da mensagem), Content-Range , Content-Encoding , Content-Language , Content-Location .
• Cabeçalhos que fazem referência a URIs: Localização (indica onde está o conteúdo), Referer (indica a origem da solicitação).
• Cabeçalhos de salvamento de fluxo : Data (data de criação), If-Modified-Since , If-Unmodified-Since , If-Match , If-None-Match , If-Range , Expires , Last-Modified , Cache-Control , Via , Pragma , Etag , Idade , Retry-After .
• Cabeçalhos de controle de cookies: Set-Cookie , Cookie
• Cabeçalhos para autenticação: Authorization , WW-Authenticate
• Cabeçalhos para descrever a comunicação: Host (indica a máquina de destino da mensagem), Connection (indica como estabelecer a conexão)
• Outros: Range (para baixar apenas partes do recurso), Max-Forward (limite de cabeçalhos adicionados no TRACE).

Exemplo de diálogo HTTP

Para obter um recurso com o URL http://www.example.com/index.html

1. Uma conexão é aberta na porta 80 do host www.example.com . A porta 80 é a porta padrão para HTTP. Se você quisesse usar a porta XXXX, teria que codificá-la no URL no formato http://www.example.com:XXXX/index.html
2. Uma mensagem é enviada no seguinte estilo:

GET /index.html HTTP/1.1
 Anfitrião: www.example.com
 Referenciador: www.google.com
 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
 Conexão: manter vivo
 [linha em branco]

A resposta do servidor é composta por cabeçalhos seguidos do recurso solicitado, no caso de uma página web:

HTTP/1.1 200 OK
Data: Sex, 31 de dezembro de 2003 23:59:59 GMT
Tipo de conteúdo: texto/html
Comprimento do conteúdo: 1221

<html lang="eo">
<cabeça>
<meta charset="utf-8">
<title>Título do site</title>
</head>
<corpo>
<h1>Página inicial do YourHost</h1>
(Conteúdo)
  .
  .
  .
</body>
</html>

Versões

O HTTP passou por várias versões do protocolo, muitas das quais são compatíveis com versões anteriores. RFC 2145 descreve o uso de números de versão HTTP. O cliente informa ao servidor no início da solicitação qual versão ele usa e o servidor usa a mesma versão ou uma versão anterior em sua resposta.

0,9 (lançado em 1991)

obsoleto. Ele suporta apenas um comando, GET, e também não especifica o número da versão HTTP. Não suporta cabeçalhos. Como esta versão não suporta POST, o cliente não pode enviar muitas informações ao servidor.

HTTP/1.0 (maio de 1996)

Esta é a primeira revisão do protocolo a especificar sua versão nas comunicações, e ainda é amplamente utilizado, principalmente em servidores proxy. Permite os métodos de solicitação GET, HEAD e POST.

HTTP/1.1 (junho de 1999) ]

Versão mais utilizada atualmente; ^{[ citação necessária ]} Conexões persistentes são habilitadas por padrão e funcionam bem com proxies . Também permite que o cliente envie várias solicitações ao mesmo tempo pela mesma conexão ( pipelining ), o que possibilita eliminar o tempo de atraso de ida e volta para cada solicitação.

HTTP/1.2 (fevereiro de 2000)

Os primeiros rascunhos de 1995 do PEP — um mecanismo de extensão para documento HTTP (que propõe o Protocolo de Extensão de Protocolo , abreviado como PEP) foram feitos pelo World Wide Web Consortium e submetidos à Força-Tarefa de Engenharia da Internet . O PEP foi inicialmente planejado para se tornar um intervalo distinto do HTTP/1.2. Em rascunhos posteriores, no entanto, a referência ao HTTP/1.2 foi removida. RFC 2774 ( experimental), HTTP Extension Framework , inclui fortemente o PEP. Foi publicado em fevereiro de 2000.

HTTP/2 (maio de 2015)

Em 2012 aparecem os primeiros rascunhos da nova versão do HTTP ( HTTP/2 ). Esta nova versão não altera a semântica do aplicativo http (todos os conceitos básicos permanecem inalterados). Suas melhorias se concentram em como os dados são empacotados e no transporte. Por exemplo, adicione o uso de uma única conexão, compressão de cabeçalho ou o serviço 'server push'. Os principais navegadores suportam apenas HTTP 2.0 sobre TLS usando a extensão ALPN que requer TLSv1.2 ou superior. ]

HTTP/3 (outubro de 2018)

HTTP/3 é o sucessor proposto para HTTP/2, ​ que já está em uso na web, usando UDP em vez de TCP para o protocolo de transporte subjacente. Assim como o HTTP/2, ele não está obsoleto nas versões principais anteriores do protocolo. O suporte para HTTP/3 foi adicionado à Cloudflare e Google Chrome em setembro de 2019, ​ e pode ser ativado em versões estáveis ​​do Chrome e Firefox . ]

Veja também

• Segurança da Camada de Transporte
• HTTPS
• Segurança de transporte HTTP estrita
• HTTP (P2P)
• HTTP/2
• .har

Links externos

• RFC-2616
• HTTP - Protocolo de Transferência de Hipertexto. W3C
• HTTP feito muito fácil. por James Marshall, 1997
• Validação de cabeçalhos HTTP Verificação de URL online
• Teste de compatibilidade HTTP/2