Protocolo de Transferência de Hipertexto - Hypertext Transfer Protocol


Da Wikipédia, a enciclopédia livre

Protocolo de Transferência de Hipertexto
Padrão internacional RFC  7230
Desenvolvido por inicialmente CERN ; IETF , W3C
introduzido 1991
Substituída por HTTP / 2

O Protocolo de Transferência de Hipertexto ( HTTP ) é um protocolo de aplicação para, de colaboração, distribuídos hipermidiáticos sistemas de informação. HTTP é a base de comunicação de dados para a World Wide Web , onde hipertexto documentos incluem hiperlinks para outros recursos que o usuário pode acessar facilmente, por exemplo, um rato clique ou tocando no ecrã. HTTP foi desenvolvido para facilitar hipertexto e da World Wide Web.

Desenvolvimento de HTTP foi iniciado por Tim Berners-Lee no CERN em 1989. desenvolvimento de padrões HTTP foi coordenada pela Internet Engineering Task Force (IETF) e da World Wide Web Consortium (W3C), que culminou com a publicação de uma série de pedidos de comentários (RFC). A primeira definição de HTTP / 1.1, a versão de HTTP em uso comum, ocorreu em RFC  2068 em 1997, embora esta tenha sido feita obsoleto por RFC  2616 em 1999 e, em seguida, novamente pelo RFC  7230 da família de RFC em 2014.

Uma versão posterior, o sucessor HTTP / 2 , foi padronizado em 2015 (e HTTP / 3 é o seu sucessor proposto ( Projecto Internet ), que se baseia em HTTP / 2), e agora é apoiado por grandes servidores web e navegadores mais de TLS usando ALPN extensão onde TLS 1.2 ou mais novo é necessária.

Visão geral técnica

URL início com o esquema de HTTP e do WWW rótulo de nome de domínio

Funções HTTP como um pedido de resposta protocolo no modelo de computação cliente-servidor. Um navegador web , por exemplo, pode ser o cliente e um aplicativo em execução em um computador que hospeda um website pode ser o servidor . O cliente envia um HTTP solicitação mensagem para o servidor. O servidor, que fornece recursos tais como HTML arquivos e outros conteúdos, ou exercer outras funções em nome do cliente, retorna uma resposta mensagem para o cliente. A resposta contém informações status de conclusão sobre o pedido e também podem conter conteúdo solicitado em seu corpo da mensagem.

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

HTTP é projetado para permitir que elementos de rede intermediários para melhorar ou permitem a comunicação entre clientes e servidores. Sites de alto tráfego, muitas vezes beneficiar de cache web servidores que fornecem conteúdo em nome dos servidores a montante para melhorar o tempo de resposta. Navegadores Web Cache acessado anteriormente recursos da web e reutilizá-los, quando possível, para reduzir o tráfego de rede. HTTP servidores proxy na rede privada fronteiras pode facilitar a comunicação para os clientes sem um endereço globalmente roteáveis, por retransmitir mensagens com servidores externos.

HTTP é uma camada de aplicação protocolo projetado no âmbito do conjunto de protocolos Internet . A sua definição presume um subjacente e fiável camada de transporte protocolo, e Transmission Control Protocol (TCP) é comumente usado. No entanto, 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).

Recursos HTTP são identificados e localizados na rede pelo Uniform Resource Locator (URL), usando os Uniform Resource Identificadores esquemas (URI) http e https . URIs e hiperlinks em HTML documentos fazem interligados hipertexto documentos.

HTTP / 1.1 é uma revisão do HTTP inicial (HTTP / 1.0). Em HTTP / 1.0 separado conexão com o mesmo servidor é feito para cada solicitação de recurso. HTTP / 1.1 pode reutilizar uma conexão várias vezes para baixar imagens, scripts de , folhas de estilo , etc após a página ter sido entregue. HTTP / 1.1 comunicações, portanto, têm menos latência como o estabelecimento de conexões TCP apresenta uma sobrecarga considerável.

História

O termo hipertexto foi cunhado por Ted Nelson em 1965 no Projeto Xanadu , que por sua vez foi inspirado por Vannevar Bush 1930 visão 's da recuperação de informação baseada em microfilme e gestão ' memex sistema' descreveu em seu 1945 ensaio " As We May Think ". Tim Berners-Lee e sua equipe no CERN são creditados com inventar o HTTP original, juntamente com HTML e a tecnologia associada para um servidor web e um navegador web baseado em texto. Berners-Lee primeiro propôs o projeto "WorldWideWeb" em 1989, agora conhecida como a World Wide Web . A primeira versão do protocolo teve apenas um método, ou seja, GET, que solicita uma página de um servidor. A resposta do servidor foi sempre uma página HTML.

A primeira versão documentada de HTTP foi V0.9 HTTP (1991). Dave Raggett levou o Grupo de Trabalho HTTP (HTTP WG) em 1995 e queria expandir o protocolo com operações estendidas, negociação estendida, mais rico meta-informação, amarrados com um protocolo de segurança que se tornou mais eficiente, adicionando métodos adicionais e campos de cabeçalho . RFC  1945 introduziu oficialmente e reconhecido V1.0 HTTP em 1996.

O GT HTTP planejava publicar novas normas em Dezembro de 1995 eo suporte para HTTP pré-standard / 1.1 baseado no então desenvolver RFC  2068 (chamado HTTP-NG) foi rapidamente adotado pelos principais desenvolvedores do navegador no início de 1996. Em março daquele ano , HTTP / 1.1 pré-padrão foi apoiado em Arena , Netscape 2.0 , o Netscape Navigator ouro 2,01, mosaico 2,7 , Lynx 2,5 , e no Internet Explorer 2.0 . Adoção do usuário final dos novos navegadores foi rápida. Em Março de 1996, uma empresa de hospedagem informou que mais de 40% dos navegadores em uso na Internet foram HTTP 1.1 compatível. Essa mesma empresa de hospedagem informou que até junho de 1996, 65% de todos os navegadores que acessam seus servidores foram HTTP / 1.1 compatível. O HTTP / 1.1 padrão conforme definido na RFC  2068 foi lançado oficialmente em janeiro de 1997. As melhorias e atualizações para o HTTP / 1.1 padrão foram lançados sob RFC  2616 em Junho de 1999.

Em 2007, o Grupo de Trabalho HTTPbis foi formado, em parte, a rever e clarificar a especificação HTTP / 1.1. Em junho de 2014, o GT lançou uma especificação de seis partes atualizadas obsoleting RFC  2616 :

  • RFC  7230 , HTTP / 1.1: Message Syntax e roteamento
  • RFC  7231 , HTTP / 1.1: Semântica e conteúdo
  • RFC  7232 , HTTP / 1.1: As solicitações condicionais
  • RFC  7233 , HTTP / 1.1: pedidos de intervalo
  • RFC  7234 , HTTP / 1.1: Caching
  • RFC  7235 , HTTP / 1.1: Autenticação

HTTP / 2 foi publicado como RFC  7540 maio 2015.

Ano Versão HTTP
1991 0,9
1996 1.0
1997 1.1
2015 2,0

sessão HTTP

Uma sessão HTTP é uma sequência de operações de solicitação-resposta rede. Um cliente HTTP inicia um pedido ao estabelecer um Transmission Control Protocol conexão (TCP) para um determinado porto em um servidor (normalmente a porta 80, ocasionalmente, a porta 8080; ver Lista de TCP e números de porta UDP ). Um servidor HTTP escutando nessa porta espera por mensagem de solicitação de um cliente. Ao receber o pedido, o servidor envia de volta uma linha de status, como "HTTP / 1.1 200 OK", e uma mensagem própria. O corpo da mensagem é tipicamente o recurso solicitado, embora uma mensagem de erro ou outras informações também podem ser devolvidos.

autenticação HTTP

HTTP fornece vários esquemas de autenticação, como a autenticação de acesso básico e digerir autenticação de acesso que operam através de um mecanismo de desafio-resposta em que o servidor identifica e emite um desafio antes de servir o conteúdo solicitado.

HTTP fornece um quadro geral de controle de acesso e autenticação, através de um conjunto extensível de esquemas de autenticação desafio-resposta, que pode ser usado por um servidor para desafiar um pedido de cliente e por um cliente para fornecer informações de autenticação.

reinos de autenticação

A especificação de HTTP autenticação proporciona também uma construção arbitrária, de aplicação específica para dividir mais recursos comuns para uma determinada raiz URI. A cadeia de valor reino, se presente, é combinado com o URI raiz canónica para formar o componente de protecção espaço do desafio. Este efeito permite que o servidor para definir escopos de autenticação separados sob uma raiz URI.

métodos de solicitação

Um HTTP 1.1 pedido feito usando telnet. O pedido mensagem, resposta seção de cabeçalho e corpo da resposta são realçados.

HTTP define métodos (por vezes referido como verbos , mas em nenhum lugar na especificação que faz menção verbo , nem é OPÇÕES ou cabeça de um verbo) para indicar a ação desejada para ser executada no recurso identificado. O que este recurso representa, se os dados pré-existentes ou dados que são gerados dinamicamente, depende da implementação do servidor. Muitas vezes, o recurso corresponde a um arquivo ou a saída de um executável que reside no servidor. A especificação de HTTP / 1.0 definido o GET, POST e HEAD métodos e a especificação HTTP / 1.1 adicionados cinco novos métodos: OPÇÕES, PUT, DELETE, TRACE e CONNECT. Por ser especificado nesses documentos, sua semântica são bem conhecidos e podem ser dependia. Qualquer cliente pode utilizar qualquer método e o servidor pode ser configurado para suportar qualquer combinação de métodos. Se um método é desconhecido para um intermediário, que vai ser tratado como um inseguro e não-idempotente método. Não há limite para o número de métodos que podem ser definidos e isto permite a métodos futuros de ser especificado sem quebrar infra-estrutura existente. Por exemplo, WebDAV definido 7 novos métodos e RFC  5789 especificado o REMENDO método.

PEGUE
O método GET solicita uma representação do recurso especificado. Solicitações usando GET só deve recuperar dados e não deve ter nenhum outro efeito. (Isto também é verdade de alguns outros métodos HTTP). O W3C publicou princípios de orientação sobre esta distinção, dizendo: " aplicativo Web design deve ser informado pelos princípios acima referidos, mas também pelas limitações relevantes." Ver métodos seguros abaixo.
CABEÇA
O método HEAD pede uma resposta idêntica à de um pedido GET, mas sem o corpo da resposta. Isto é útil para a recuperação de meta-informação escrita em cabeçalhos de resposta, sem ter que transportar todo o conteúdo.
POSTAR
O método POST solicita que o servidor aceitar a entidade fechada no pedido como um novo subordinado do recurso web identificado pelo URI. Os dados postados pode ser, por exemplo, uma anotação para recursos existentes; uma mensagem para uma lista de discussão, newsgroup, lista de discussão, ou segmento comentário; um bloco de dados que é o resultado de se submeter um formulário da web para um processo de tratamento de dados; ou um item para adicionar a um banco de dados.
COLOCAR
O método PUT solicita que a entidade fechada ser armazenado sob o fornecido URI . Se o URI refere-se a um recurso já existente, ele é modificado; se o URI não aponta para um recurso existente, em seguida, o servidor pode criar o recurso com esse URI.
EXCLUIR
O método de exclusão elimina o recurso especificado.
VESTÍGIO
O método TRACE ecoa o pedido recebido de modo que um cliente pode ver o que (se houver) mudanças ou adições foram feitas por servidores intermediários.
OPÇÕES
O método OPÇÕES retorna os métodos HTTP que o servidor suporta para o especificado URL . Isso pode ser usado para verificar a funcionalidade de um servidor web, solicitando '*' em vez de um recurso específico.
CONECTAR
O método CONNECT converte a conexão solicitação para um transparente túnel TCP / IP , geralmente para facilitar SSL comunicação criptografada (HTTPS) através de um sem criptografia proxy HTTP . Veja método HTTP CONNECT .
PATCH
O método aplica-se REMENDO modificações parciais para um recurso.

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

métodos seguros

Alguns dos métodos (por exemplo, HEAD, GET, opções e TRACE) são, por convenção, definida como segura , o que significa que eles são destinados apenas para a recuperação de informações e não deve alterar o estado do servidor. Em outras palavras, eles não devem ter efeitos colaterais , além de efeitos relativamente inofensivos, como logging , caching web, o serviço de anúncios em banners ou incrementar um contador de web . Fazendo solicitações GET arbitrárias sem levar em conta o contexto do estado do aplicativo deve, portanto, ser considerado seguro. No entanto, este não é obrigatória pela norma, e é explicitamente reconheceu que não pode ser garantida.

Por outro lado, métodos, como POST, PUT, DELETE e PATCH destinam-se a ações que podem causar efeitos colaterais, quer no servidor ou efeitos colaterais externos, tais como transações financeiras ou transmissão de e-mail . Tais métodos são, portanto, geralmente não é usada, conformando robôs web ou rastreadores da web; alguns que não estão em conformidade tendem a fazer pedidos sem levar em conta contexto ou consequências.

Apesar da segurança prescrita de GET pedidos, na prática, a sua manipulação por parte do servidor não é tecnicamente limitado de qualquer forma. Portanto, a programação descuidada ou intencional pode causar alterações não triviais no servidor. Esta é desencorajado, pois pode causar problemas para caching web , motores de busca e outros agentes automatizados, o que pode fazer alterações indesejadas no servidor. Por exemplo, um site pode permitir a exclusão de um recurso através de uma URL, como http://example.com/article/1234/delete , que, se arbitrariamente forçado, mesmo usando GET , seria simplesmente eliminar o artigo.

Um exemplo disto ocorre na prática foi durante a curta duração Google Web Accelerator beta , que prefetched URLs arbitrários na página de um usuário estava vendo, fazendo com que os registros sejam automaticamente alterados em massa . O beta foi suspenso apenas algumas semanas após a sua primeira versão, a seguir críticas generalizadas.

Idempotente métodos e aplicações web

Métodos PUT e DELETE são definidos a ser idempotentes , o que significa que várias solicitações idênticas devem ter o mesmo efeito que um único pedido ( note que idempotência refere-se ao estado do sistema após a solicitação foi concluída, por isso, enquanto a ação que o servidor leva (por exemplo, exclusão de um registro) ou o código de resposta que retorna pode ser diferente em solicitações subsequentes, o estado do sistema será o mesmo cada vez ). Métodos GET, HEAD, opções e TRACE, sendo prescritos como seguro, também devem ser idempotentes, como HTTP é um protocolo sem estado .

Em contraste, o método POST não é necessariamente idempotentes, e portanto o envio de um pedido POST idêntica várias vezes podem afectar ainda mais estado ou provocar outros efeitos secundários (tais como transacções financeiras ). Em alguns casos isso pode ser desejável, mas em outros casos, isso pode ser devido a um acidente, como quando um usuário não percebe que sua ação vai resultar no envio de outro pedido, ou não receberam feedback adequado que seu primeiro pedido foi bem sucedido. Enquanto navegadores podem mostrar caixas de diálogo de alerta para advertir os usuários em alguns casos em que recarregar uma página pode voltar a apresentar um pedido POST, é geralmente até a aplicação web para lidar com casos em que um pedido POST não devem ser submetidas mais do que uma vez.

Note-se que se um método é idempotente não é imposta pelo servidor protocolo ou web. É perfeitamente possível escrever um aplicativo web em que (por exemplo) uma inserção de banco de dados ou outra ação não-idempotent é desencadeada por um GET ou outro pedido. Ignorar esta recomendação, no entanto, pode resultar em consequências indesejáveis, se um agente de usuário assume que repetir o mesmo pedido é seguro quando não é.

Segurança

O método de rastreio pode ser utilizado como parte de uma classe de ataques conhecidos como cross-site rastreio ; por essa razão, o conselho de segurança comum é para ser desativado na configuração do servidor. Microsoft IIS suporta um método proprietário "TRACK", que se comporta de forma semelhante, e que também está recomendado para ser desativado.

Tabela de resumo

método HTTP RFC Pedido tem corpo Response tem corpo Seguro idempotente cacheable
PEGUE RFC  7231 Opcional sim sim sim sim
CABEÇA RFC  7231 Não Não sim sim sim
POSTAR RFC  7231 sim sim Não Não sim
COLOCAR RFC  7231 sim sim Não sim Não
EXCLUIR RFC  7231 Não sim Não sim Não
CONECTAR RFC  7231 sim 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
PATCH RFC  5789 sim sim Não Não Não

Os códigos de status

Em HTTP / 1.0 e desde então, a primeira linha da resposta HTTP é chamado de linha de status e inclui uma numérico código de status (como " 404 ") e uma textual frase razão (como 'Not Found'). A forma como o agente do usuário lida com a resposta depende principalmente do código, e, secundariamente, nos outros campos de cabeçalho de resposta . Códigos de status personalizado pode ser usado, pois se o agente usuário encontra um código que não reconhece, ele pode usar o primeiro dígito do código para determinar a classe geral da resposta.

Os padrão frases razão são apenas recomendações, e pode ser substituído por "equivalentes locais" no desenvolvedor web critério da. Se o código de status indicado um problema, o agente do usuário pode exibir a frase razão ao utilizador a prestação de informações sobre a natureza do problema. A norma também permite que o agente de usuário para tentar interpretar a frase razão , embora isso possa ser imprudente uma vez que a norma especifica explicitamente que os códigos de status são legível por máquina e frases razão é legível. Código de status HTTP é basicamente dividida em cinco grupos para uma melhor explicação do pedido e respostas entre cliente e servidor como o nome:

  • informativa 1XX
  • Bem sucedido 2XX
  • redirecionamento 3XX
  • Erro de cliente 4XX
  • erro de servidor 5XX

conexões persistentes

Em HTTP / 0.9 e 1.0, a ligação é fechada depois de um único par de pedido / resposta. Em HTTP / 1.1 um mecanismo keep-alive foi introduzido, onde uma conexão pode ser reutilizado para mais de uma solicitação. Tais conexões persistentes reduzir pedido latência perceptível, porque o cliente não precisa renegociar a conexão TCP 3-Way-Aperto de mão após a primeira solicitação foi enviada. Outro efeito colateral positivo é que, em geral, a conexão se torna mais rápido com o tempo devido a do TCP slow-start -mechanism.

Versão 1.1 do protocolo também feitas melhorias de otimização de largura de banda para HTTP / 1.0. Por exemplo, o HTTP / 1.1 introduziu codificação de transferência fragmentada para permitir que o conteúdo em ligações persistentes para ser transmitidos em vez de tamponada. HTTP pipelining reduz ainda mais o tempo de atraso, permitindo que os clientes para enviar vários pedidos antes de aguardar cada resposta. Outra adição ao protocolo foi porção byte , onde um servidor transmite apenas a parte de um recurso explicitamente solicitado por um cliente.

o estado da sessão HTTP

O HTTP é um protocolo sem estado . Um protocolo sem estado não exige que o servidor HTTP para reter informações ou de estado sobre cada usuário para a duração de várias solicitações. No entanto, algumas aplicações web implementar estados ou sessões do lado do servidor , utilizando, por exemplo, cookies HTTP ou ocultos variáveis dentro de formulários web .

conexões criptografadas

A forma mais popular de estabelecer uma conexão HTTP encriptado é HTTPS. Também existem dois outros métodos para estabelecer uma conexão HTTP encriptado: seguro Hypertext Transfer Protocol , e usar o HTTP / 1.1 Upgrade cabeçalho para especificar um upgrade para TLS. Suporte ao navegador para estes dois é, no entanto, quase inexistente.

formato de mensagem

O cliente eo servidor se comunicam enviando de texto simples ( ASCII mensagens). O cliente envia solicitações para o servidor e o servidor envia respostas .

mensagem de solicitação

A mensagem de pedido consiste no seguinte:

  • uma linha de pedido (por exemplo, GET /images/logo.png HTTP / 1.1 , que solicita um recurso chamado /images/logo.png do servidor.)
  • campos pedido de cabeçalho (por exemplo, Accept-Language: en ).
  • uma linha vazia
  • um opcional corpo da mensagem

A linha de pedido e outros campos do cabeçalho deverá cada extremidade com <CR> <LF> (isto é, um transporte de retorno caracteres, seguido de uma alimentação de linha de caracteres). A linha vazia deve consistir de apenas <CR> <LF> e nenhum outro espaço em branco . No protocolo HTTP / 1.1, todos os campos de cabeçalho excepto anfitrião são opcionais.

A linha de solicitação contendo apenas o nome do caminho é aceito pelos servidores para manter a compatibilidade com clientes HTTP antes da especificação HTTP / 1.0 no RFC  1945 .

mensagem de resposta

A mensagem de resposta consiste no seguinte:

A linha de status e outros campos de cabeçalho devem todos final com <CR> <LF>. A linha vazia deve consistir de apenas <CR> <LF> e nenhum outro espaço em branco . Esta exigência estrita para <CR> <LF> é relaxou um pouco dentro de corpos de mensagens para uso consistente de outras quebras de linha do sistema, tais como <CR> ou <LF> sozinho.

sessão de exemplo

Abaixo está uma conversa amostra entre um cliente HTTP e um servidor HTTP em execução no www.example.com , porta 80. Como mencionado nas seções anteriores, todos os dados são enviados em um texto simples ( ASCII ) de codificação, usando um de dois byte CR LF ( '\ r \ n') de fim de linha no fim de cada linha.

solicitação do cliente

GET /index.html HTTP/1.1
Host: www.example.com

Um pedido de cliente (que consiste, neste caso, a linha de pedido e apenas um campo de cabeçalho) é seguido por uma linha em branco, de modo que o pedido termina com uma nova linha dupla, cada um na forma de um retorno do carro seguido por uma linha de alimentação . O campo "Host" distingue entre vários DNS nomes compartilhando um único endereço IP , permitindo à base de nome de hospedagem virtual . Enquanto opcional no HTTP / 1.0, é obrigatório em HTTP / 1.1.

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: 138
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>
  Hello World, this is a very simple HTML document.
</body>
</html>

O ETag campo de cabeçalho (tag entidade) é usado para determinar se uma versão em cache do recurso solicitado é idêntico à versão atual do recurso no servidor. Content-Type especifica o tipo de suporte de Internet dos dados transmitidos pela mensagem HTTP, enquanto que o conteúdo de Comprimento indica o seu comprimento em bytes. O HTTP / 1.1 webserver publica a sua capacidade para responder às solicitações para determinados 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, que é chamado byte servindo . Quando Connection: close é enviada, isso significa que o servidor web irá fechar o TCP conexão imediatamente após a transferência desta resposta.

A maior parte das linhas de cabeçalho são opcionais. Quando Content-Length está faltando o comprimento é determinado de outras maneiras. Transferência fragmentada codificação utiliza um tamanho de bloco de 0 a assinalar o fim do conteúdo. Identidade codificação sem Content-Length lê o conteúdo até o socket está fechado.

Um Content-Encoding como gzip pode ser usado para comprimir os dados transmitidos.

protocolos similares

O protocolo Gopher foi um protocolo de entrega de conteúdo que foi deslocado pelo HTTP no início de 1990. O SPDY protocolo é uma alternativa para HTTP desenvolvido pelo Google , é substituído pelo novo protocolo HTTP, HTTP / 2 .

Veja também

Notas

Referências

links externos